Re: IPsec peers allowed to inject any network to existing tunnels
On 2019-03-13, Fedor Piecka wrote: > I understood that ipsecctl and ipsec.conf are supposed to free the user > from configuring keynotes manually. That's not correct. ipsec.conf can take the place of isakmpd.conf in some limited cases. It doesn't replace keynote in any way. > Doesn't the parameter "-K" of > isakmpd mean it won't read keynote policy at all? That is correct. As the manual puts it, -K When this option is given, isakmpd does not read the policy configuration file and no keynote(4) policy check is accomplished. ^^ > Could you please clarify a bit further on how do keynote policies and > ipsec.conf automatic keying work together? I understand an option of not > using ipsec.conf at all, but I don't understand how to use both > ipsec.conf and isakmpd configuration for a single ESP tunnel. keynote interacts exactly the same with ipsec.conf as it does with isakmpd.conf. ipsecctl -f isn't particularly clever, it's a basic config generator. It reads ipsec.conf, generates isakmpd.conf sections based on the config, and feeds these to isakmpd over a fifo. It is missing quite a lot of configurability that isakmpd.conf allows (for example allowing multiple encryption suites in the same "default peer" config). Run "ipsecctl -vf /etc/ipsec.conf" to see what it's sending, the output from that can be reformatted slightly and written to isakmpd.conf. Yes keynote is a pain but it's the only available method to get this done. > Iked doesn't have the same problem. No SAs/flows will be created if the > networks aren't configured in iked.conf. However isakmpd->iked migration > is painful in OpenBSD as their use at the same time isn't straightforward. Still unsure about that, "from 0.0.0.0/0 to 0.0.0.0/0" is not that uncommon a setup with iked when you have roaming clients needing to access "the internet" via vpn, in which case the networks do match ..
Re: IPsec peers allowed to inject any network to existing tunnels
I understood that ipsecctl and ipsec.conf are supposed to free the user from configuring keynotes manually. Doesn't the parameter "-K" of isakmpd mean it won't read keynote policy at all? man ipsec.conf: The keying daemon, isakmpd(8), can be enabled to run at boot time via the isakmpd_flags variable in rc.conf.local(8). Note that it will probably need to be run with at least the -K option, to avoid keynote(4) policy checking. man isakmpd: -K When this option is given, isakmpd does not read the policy configuration file and no keynote(4) policy check is accomplished. This option can be used when policies for flows and SA establishment are arranged by other programs like ipsecctl(8) or bgpd(8). Could you please clarify a bit further on how do keynote policies and ipsec.conf automatic keying work together? I understand an option of not using ipsec.conf at all, but I don't understand how to use both ipsec.conf and isakmpd configuration for a single ESP tunnel. Iked doesn't have the same problem. No SAs/flows will be created if the networks aren't configured in iked.conf. However isakmpd->iked migration is painful in OpenBSD as their use at the same time isn't straightforward. Dňa 13. 3. 2019 o 10:20 Stuart Henderson napísal(a): isakmpd: it is a misconfiguration (but an incredibly common one), you should use a keynote policy to prevent this.
Re: IPsec peers allowed to inject any network to existing tunnels
On 2019-03-13, Fedor Piecka wrote: > Does anybody see any misconfiguration or misunderstanding on our side? Or > is this a bug (IMHO a security bug) in OpenBSD IPsec implementation? isakmpd: it is a misconfiguration (but an incredibly common one), you should use a keynote policy to prevent this. If the same applies to iked (I haven't tested but suspect it's the case) then there it's more of a bug because there's no way to change iked config to avoid it.
IPsec peers allowed to inject any network to existing tunnels
Hello
We've discovered a very weird behavior in OpenBSD IPsec.
We run isakmpd -K and use ipsecctl with ipsec.conf to set up our IPsec
tunnels. When our peer adds a new network to an existing configuration on
his router, our OpenBSD box accepts the network without our intervention,
SAs and flows are created and started automatically.
I've tested this with fresh installations of OpenBSD 6.4 amd64. The test
VMs are called obsd1 and obsd2. They are directly connected to each other
on network 172.16.50.0/24.
After basic installation, I configured IP addresses, ipsec.conf and I
started isakmpd like this:
obsd1# ifconfig em0 | grep inet
inet 172.16.50.51 netmask 0xffe0 broadcast 172.16.50.63
obsd1# ifconfig lo0 | grep "inet "
inet 127.0.0.1 netmask 0xff00
inet 192.168.10.1 netmask 0xff00
inet 192.168.100.1 netmask 0xff00
obsd1# isakmpd -Kv -f /var/run/isakmpd.fifo
obsd1# cat /etc/ipsec.conf
ike esp from { 192.168.10.0/24 } \
to { 192.168.20.0/24 } \
local 172.16.50.51 peer 172.16.50.48 \
psk "secret_pass"
obsd1# ipsecctl -f /etc/ipsec.conf
obsd2# ifconfig em0 | grep inet
inet 172.16.50.48 netmask 0xffe0 broadcast 172.16.50.63
obsd2# ifconfig lo0 | grep "inet "
inet 127.0.0.1 netmask 0xff00
inet 192.168.20.1 netmask 0xff00
obsd2# isakmpd -Kv -f /var/run/isakmpd.fifo
obsd2# cat /etc/ipsec.conf
ike esp from { 192.168.20.0/24 } \
to { 192.168.10.0/24 } \
local 172.16.50.48 peer 172.16.50.51 \
psk "secret_pass"
obsd2# ipsecctl -f /etc/ipsec.conf
The above works as expected. I can do:
obsd2# ping -I 192.168.20.1 -c 1 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 data bytes
64 bytes from 192.168.10.1: icmp_seq=0 ttl=255 time=1.102 ms
--- 192.168.10.1 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 1.102/1.102/1.102/0.000 ms
Now to the point. I modified obsd1 (and I've NOT modified obsd2). I added
the network 192.168.100.0/24 to ipsec.conf:
obsd1# cat /etc/ipsec.conf
ike esp from { 192.168.10.0/24 192.168.100.0/24 } \
to { 192.168.20.0/24 } \
local 172.16.50.51 peer 172.16.50.48 \
psk "secret_pass"
obsd1# ipsecctl -f /etc/ipsec.conf
And it works (as not expected by me):
obsd2# ipsecctl -sf
flow esp in from 192.168.10.0/24 to 192.168.20.0/24 peer 172.16.50.51 srcid
172.16.50.48/32 dstid 172.16.50.51/32 type use
flow esp in from 192.168.100.0/24 to 192.168.20.0/24 peer 172.16.50.51
srcid 172.16.50.48/32 dstid 172.16.50.51/32 type use
flow esp out from 192.168.20.0/24 to 192.168.10.0/24 peer 172.16.50.51
srcid 172.16.50.48/32 dstid 172.16.50.51/32 type require
flow esp out from 192.168.20.0/24 to 192.168.100.0/24 peer 172.16.50.51
srcid 172.16.50.48/32 dstid 172.16.50.51/32 type require
obsd2# ping -I 192.168.20.1 -c 1 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
64 bytes from 192.168.100.1: icmp_seq=0 ttl=255 time=1.013 ms
--- 192.168.100.1 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 1.013/1.013/1.013/0.000 ms
We do protect our network with firewalls so our peers cannot use this to
introduce new networks, but a different thing happened today.
We'd already had the network 192.168.100.32/27 in our ipsec.conf with peer
A and the tunnel to peer A was up and running.
Peer B added the network 192.168.100.0/24 to IPsec configuration on their
side and SAs and flows were automatically created for the new network on
our router. This would be a bigger issue if it happened the opposite way
(peer B using a larger netmask).
Our PF configuration doesn't help to mitigate the problem as it doesn't
know from/to which peer does the traffic on enc0 flow.
The problem showed itself up on OpenBSD 5.5. The demo described above was
done on OpenBSD 6.4, as I've already mentioned.
Does anybody see any misconfiguration or misunderstanding on our side? Or
is this a bug (IMHO a security bug) in OpenBSD IPsec implementation?
