To: gn...@openbsd.org
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: p.wiel...@iem.pw.edu.pl
Cc: bugs@openbsd.org
Reply-To: p.wiel...@iem.pw.edu.pl
>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
dera...@i386.openbsd.org:/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
