All OpenBSD versions should have this problem as it's due to the way how IPsec-flows are encoded in the routing table and I could not find and easy fix.
On Tue, Jul 19, 2011 at 2:28 PM, Pawel Wieleba <[email protected]> wrote: > To: [email protected] > Subject: [ipsec routing] IP frame is sent to the wrong IPSEC peer when using srcnat, but it should be routed to the network with the most narrow netmask. > From: [email protected] > Cc: [email protected] > Reply-To: [email protected] > >>Synopsis: [ipsec routing] IP frame is sent to the wrong IPSEC peer when using srcnat, but it should be routed to the network with the most narrow netmask. >>Category: system kernel >>Environment: > System : OpenBSD 4.9 > Details : OpenBSD 4.9 (GENERIC) #671: Wed Mar 2 07:09:00 MST 2011 > [email protected]:/usr/src/sys/arch/i386/compile/GENERIC > > Architecture: OpenBSD.i386 > Machine : i386 >>Description: > > Hello, > > The IP frame is sent to the wrong IPSEC peer when using srcnat. It should be routed > to the network with the most narrow netmask, but it does not. The below example with > configuration attached precisely describes the problem. > > The test configuration consists of three VPN peers, which are running OpenBSD 4.9 release. > - obsd49 > - obsd49b > - obsd49c > > There are two tunnels set between the following peers: > - obsd49c - obsd49 ( 192.168.81.0/24 - 192.168.181.0/24 ) > - obsd49c - obsd49b ( 192.168.81.128/27 (with srcnat) - 192.168.181.64/27 ) > > The problem exists and was tested on OpenBSD 4.8 and OpenBSD 4.9. Further tests are being run > on three OpenBSD 4.9 peers: > > *** IPSEC configuration *** > obsd49:~# cat /etc/ipsec.conf > ike esp from { 192.168.181.0/24 } to { 192.168.81.0/24 } local 192.168.10.184 peer 192.168.10.186 main auth hmac-sha1 enc aes group modp1024 quick auth hmac-sha1 enc aes group modp1024 psk "<shared_key>" > > obsd49b:~# cat /etc/ipsec.conf > ike esp from { 192.168.181.64/27 } to { 192.168.81.128/27 } local 192.168.10.185 peer 192.168.10.186 main auth hmac-sha1 enc aes group modp1024 quick auth hmac-sha1 enc aes group modp1024 psk "<shared_key>" > > obsd49c:~# cat /etc/ipsec.conf > ike esp from { 192.168.81.0/24 } to { 192.168.181.0/24 } local 192.168.10.186 peer 192.168.10.184 main auth hmac-sha1 enc aes group modp1024 quick auth hmac-sha1 enc aes group modp1024 psk "<shared_key>" > ike esp from { 192.168.81.128/27 (0.0.0.0/0) } to { 192.168.181.64/27 } local 192.168.10.186 peer 192.168.10.185 main auth hmac-sha1 enc aes group modp1024 quick auth hmac-sha1 enc aes group modp1024 psk "<shared_key>" > > Daemon isakmpd run as: > # isakmpd -K -vv -4 -L > > *** PF rules *** > obsd49:~# cat /etc/pf.conf > pass quick > > obsd49b:~# cat /etc/pf.conf > pass quick > > obsd49c:~# cat /etc/pf.conf > match out quick on enc0 from 192.168.81.0/24 to 192.168.181.64/27 nat-to 192.168.81.129 > pass quick > > *** IP addresses *** > obsd49:~# ifconfig pcn0|grep 'inet ' > inet 192.168.10.184 netmask 0xffffff00 broadcast 192.168.10.255 > obsd49b:~# ifconfig pcn0|grep 'inet ' > inet 192.168.10.185 netmask 0xffffff00 broadcast 192.168.10.255 > obsd49c:~# ifconfig pcn0|grep 'inet ' > inet 192.168.10.186 netmask 0xffffff00 broadcast 192.168.10.255 > > obsd49:~# ifconfig lo0|grep 'inet ' > inet 127.0.0.1 netmask 0xff000000 > inet 192.168.181.1 netmask 0xffffff00 > obsd49b:~# ifconfig lo0|grep 'inet ' > inet 127.0.0.1 netmask 0xff000000 > inet 192.168.181.64 netmask 0xffffffe0 > obsd49c:~# ifconfig lo0|grep 'inet ' > inet 127.0.0.1 netmask 0xff000000 > inet 192.168.81.1 netmask 0xffffff00 > > > ************** > *** Test 1 *** > ** Ping 1 (problem) - IP frame is sent to the wrong IPSEC peer. It is routed > to the network 192.168.181/24 (peer 192.168.10.184) but it should be routed > to the network 192.168.181.64/27 (peer 192.168.10.185) which has the most narrow netmask. > > obsd49c:~# ping -I 192.168.81.1 192.168.181.64 > PING 192.168.181.64 (192.168.181.64): 56 data bytes > --- 192.168.181.64 ping statistics --- > 1 packets transmitted, 0 packets received, 100.0% packet loss > > obsd49c:~# tcpdump -i enc0 -nvveel > tcpdump: listening on enc0, link-type ENC > 12:55:45.589173 (authentic,confidential): SPI 0x517533ee: 192.168.10.186 > 192.168.10.184: 192.168.81.129 > 192.168.181.64: icmp: echo request (id:f19f seq:0) (ttl 255, id 53970, len 84) (ttl 64, id 58828, len 104, bad cksum 0! differs by fe02) > > ** Ping 2 - Correctly routed packet to the network with wider netmask. > obsd49c:~# ping -I 192.168.81.1 192.168.181.1 > PING 192.168.181.1 (192.168.181.1): 56 data bytes > 64 bytes from 192.168.181.1: icmp_seq=0 ttl=255 time=0.644 ms > --- 192.168.181.1 ping statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 0.644/0.644/0.644/0.000 ms > > obsd49c:~# tcpdump -i enc0 -nvveel > tcpdump: listening on enc0, link-type ENC > 12:55:51.134387 (authentic,confidential): SPI 0x517533ee: 192.168.10.186 > 192.168.10.184: 192.168.81.1 > 192.168.181.1: icmp: echo request (id:e722 seq:0) (ttl 255, id 60725, len 84) (ttl 64, id 25999, len 104, bad cksum 0! differs by 7e40) > 12:55:51.134900 (authentic,confidential): SPI 0xe9806465: 192.168.10.184 > 192.168.10.186: 192.168.181.1 > 192.168.81.1: icmp: echo reply (id:e722 seq:0) (ttl 255, id 26192, len 84) (ttl 64, id 46350, len 104) > > > ** Ping 3 - OK > obsd49:~# ping -I 192.168.181.1 192.168.81.1 > PING 192.168.81.1 (192.168.81.1): 56 data bytes > 64 bytes from 192.168.81.1: icmp_seq=0 ttl=255 time=0.936 ms > > > **** Associated VPNS > obsd49:~# netstat -rn -f encap > Routing tables > > Encap: > Source Port Destination Port Proto SA(Address/Proto/Type/Direction) > 192.168.81/24 0 192.168.181/24 0 0 192.168.10.186/esp/use/in > 192.168.181/24 0 192.168.81/24 0 0 192.168.10.186/esp/require/out > > obsd49b:~# netstat -rn -f encap > Routing tables > > Encap: > Source Port Destination Port Proto SA(Address/Proto/Type/Direction) > 192.168.81.128/27 0 192.168.181.64/27 0 0 192.168.10.186/esp/use/in > 192.168.181.64/27 0 192.168.81.128/27 0 0 192.168.10.186/esp/require/out > > obsd49c:~# netstat -rn -f encap > Routing tables > > Encap: > Source Port Destination Port Proto SA(Address/Proto/Type/Direction) > 192.168.181.64/27 0 default 0 0 192.168.10.185/esp/use/in > default 0 192.168.181.64/27 0 0 192.168.10.185/esp/require/out > 192.168.181/24 0 192.168.81/24 0 0 192.168.10.184/esp/use/in > 192.168.81/24 0 192.168.181/24 0 0 192.168.10.184/esp/require/out > > > obsd49:~# ipsecctl -s flow > flow esp in from 192.168.81.0/24 to 192.168.181.0/24 peer 192.168.10.186 srcid 192.168.10.184/32 dstid 192.168.10.186/32 type use > flow esp out from 192.168.181.0/24 to 192.168.81.0/24 peer 192.168.10.186 srcid 192.168.10.184/32 dstid 192.168.10.186/32 type require > > obsd49b:~# ipsecctl -s flow > flow esp in from 192.168.81.128/27 to 192.168.181.64/27 peer 192.168.10.186 srcid 192.168.10.185/32 dstid 192.168.10.186/32 type use > flow esp out from 192.168.181.64/27 to 192.168.81.128/27 peer 192.168.10.186 srcid 192.168.10.185/32 dstid 192.168.10.186/32 type require > > obsd49c:~# ipsecctl -s flow > flow esp in from 192.168.181.64/27 to 0.0.0.0/0 peer 192.168.10.185 srcid 192.168.10.186/32 dstid 192.168.10.185/32 type use > flow esp out from 0.0.0.0/0 to 192.168.181.64/27 peer 192.168.10.185 srcid 192.168.10.186/32 dstid 192.168.10.185/32 type require > flow esp in from 192.168.181.0/24 to 192.168.81.0/24 peer 192.168.10.184 srcid 192.168.10.186/32 dstid 192.168.10.184/32 type use > flow esp out from 192.168.81.0/24 to 192.168.181.0/24 peer 192.168.10.184 srcid 192.168.10.186/32 dstid 192.168.10.184/32 type require > > > ************** > *** Test 2 *** > When the host obsd49 is turned off (or 'pkill isakmpd' and 'ipsecctl -F' has been run), the following ping works fine: > > obsd49c:~# ping -I 192.168.81.1 192.168.181.64 > PING 192.168.181.64 (192.168.181.64): 56 data bytes > 64 bytes from 192.168.181.64: icmp_seq=0 ttl=255 time=1.206 ms > > bsd49c:~# tcpdump -i enc0 -nvveel > tcpdump: listening on enc0, link-type ENC > 13:24:50.541279 (authentic,confidential): SPI 0xbbbd74f3: 192.168.10.186 > 192.168.10.185: 192.168.81.129 > 192.168.181.64: icmp: echo request (id:3ab8 seq:0) (ttl 255, id 2470, len 84) (ttl 64, id 27836, len 104, bad cksum 0! differs by 7712) > 13:24:50.542472 (authentic,confidential): SPI 0xfeec5be8: 192.168.10.185 > 192.168.10.186: 192.168.181.64 > 192.168.81.129: icmp: echo reply (id:3ab8 seq:0) (ttl 255, id 53089, len 84) (ttl 64, id 19004, len 104) > > >>How-To-Repeat: > The above configuration describes the problem. Just attempt to ping through VPN > to the remote IP which belongs to the more narrow netmask (when srcnat is used). >>Fix: > I have no fix. The workaround is to use not overlaping networks, but it is not always possible > and makes the configuration very complex, as many SA's would be negotiated and flows created. > > I'm looking to hearing from you. > Pawel Wieleba
