[Openswan Users] Openswan to Cisco 800 series droppping some traffic

Wed Jul 30 17:41:32 EDT 2008

Hi All,

I have finally managed to configure an almost stable site to site VPN between a
cisco router and openswan:

openswan 172.24.99.0/24===202.89.xxx.xxx...203.97.xxx.xxx===192.168.2.0/24 cisco
871

500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 732s;
newest IPSEC; eroute owner
esp.41aebcec at 203.97.xxx.xxx [mailto:esp.41aebcec at 203.97.xxx.xxx]
esp.8d7c9d77 at 202.89.xxx.xxx [mailto:esp.8d7c9d77 at 202.89.xxx.xxx]
tun.0 at 203.97.xxx.xxx [mailto:tun.0 at 203.97.xxx.xxx] tun.0 at 202.89.xxx.xxx
[mailto:tun.0 at 202.89.xxx.xxx]
500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 33551s; newest
ISAKMP; lastdpd=18s(seq in:10973 out:0)

Relevant configs attached...

The problem is that some packets which are set to not fragment but which when
encrypted are bigger than the MTU get dropped. ie:

from host in the cisco protected lan 192.168.2.254 (PROBLEM!):

# ping -M do 172.24.99.253 -c 2 -s 1415  <------------------ Packet smaller than
1443 MTU OK
PING 172.24.99.253 (172.24.99.253) 1415(1443) bytes of data.
1423 bytes from 172.24.99.253: icmp_seq=1 ttl=62 time=55.8 ms
1423 bytes from 172.24.99.253: icmp_seq=2 ttl=62 time=44.6 ms

--- 172.24.99.253 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1003ms
rtt min/avg/max/mdev = 44.615/50.251/55.887/5.636 ms

# ping -M do 172.24.99.253 -c 2 -s 1416  <------------------ Packet larger than
1443 MTU but smaller than interface 1500 MTU Dropped no error
PING 172.24.99.253 (172.24.99.253) 1416(1444) bytes of data.

--- 172.24.99.253 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1001ms

# ping -M do 172.24.99.253 -c 2 -s 1472  <------------------ Packet larger than
1443 MTU but smaller than interface 1500 MTU Dropped no error
PING 172.24.99.253 (172.24.99.253) 1472(1500) bytes of data.

--- 172.24.99.253 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1009ms

# ping -M do 172.24.99.253 -c 2 -s 1473  <------------------ Packet larger than
interface 1500 MTU error reported correctly (sort of)
PING 172.24.99.253 (172.24.99.253) 1473(1501) bytes of data.
>From 192.168.2.254 icmp_seq=1 Frag needed and DF set (mtu = 1500)
>From 192.168.2.254 icmp_seq=1 Frag needed and DF set (mtu = 1500)

--- 172.24.99.253 ping statistics ---
0 packets transmitted, 0 received, +2 errors

As you can see, the middle two should have failed and reported Frag needed and
DF set (mtu = 1443), and the last one shows why, (mtu=1500).

By changing the VPN route MTU on the openswan box all other pings are ok (this
was set before the test above):

ip route change 192.168.2.0/24 dev eth0 scope link src 172.24.99.1 mtu 1443

from openswan box (correct):

# ping -c 2 -I 172.24.99.1 -M do 192.168.2.1 -s 1415 
PING 192.168.2.1 (192.168.2.1) from 172.24.99.1 : 1415(1443) bytes of data.
1423 bytes from 192.168.2.1: icmp_seq=1 ttl=255 time=74.0 ms
1423 bytes from 192.168.2.1: icmp_seq=2 ttl=255 time=65.1 ms

# ping -c 2 -I 172.24.99.1 -M do 192.168.2.1 -s 1416 
PING 192.168.2.1 (192.168.2.1) from 172.24.99.1 : 1416(1444) bytes of data.
>From 172.24.99.1 icmp_seq=1 Frag needed and DF set (mtu = 1443)
>From 172.24.99.1 icmp_seq=1 Frag needed and DF set (mtu = 1443)

from a host in the openswan protected lan 172.24.99.253 (correct):

# ping -c 2 -M do 192.168.2.1 -s 1415
PING 192.168.2.1 (192.168.2.1) 1415(1443) bytes of data.
1423 bytes from 192.168.2.1: icmp_seq=1 ttl=254 time=43.9 ms
1423 bytes from 192.168.2.1: icmp_seq=2 ttl=254 time=30.1 ms

# ping -c 2 -M do 192.168.2.1 -s 1416
PING 192.168.2.1 (192.168.2.1) 1416(1444) bytes of data.
>From 172.24.99.253 icmp_seq=1 Frag needed and DF set (mtu = 1443)
>From 172.24.99.253 icmp_seq=1 Frag needed and DF set (mtu = 1443)

from cisco router (correct):

#ping 172.24.99.253 source 192.168.2.1 df-bit repeat 2 size 1443

Sending 2, 1443-byte ICMP Echos to 172.24.99.253, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.1
Packet sent with the DF bit set
!!
015032: .Jul 31 09:11:24.564 Napier: ICMP: echo reply rcvd, src 172.24.99.253,
dst 192.168.2.1
015033: .Jul 31 09:11:24.592 Napier: ICMP: echo reply rcvd, src 172.24.99.253,
dst 192.168.2.1
Success rate is 100 percent (2/2), round-trip min/avg/max = 28/30/32 ms

#ping 172.24.99.253 source 192.168.2.1 df-bit repeat 2 size 1444

Sending 2, 1444-byte ICMP Echos to 172.24.99.253, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.1
Packet sent with the DF bit set
..
015035: .Jul 31 09:11:27.495 Napier: CRYPTO_ENGINE: locally-sourced pkt w/DF bit
set is too big,ip->tl=1444, mtu=1443
015037: .Jul 31 09:11:29.495 Napier: CRYPTO_ENGINE: locally-sourced pkt w/DF bit
set is too big,ip->tl=1444, mtu=1443
Success rate is 0 percent (0/2)

ping 172.24.99.253 source 192.168.2.1 df-bit repeat 2 size 1500

Sending 2, 1500-byte ICMP Echos to 172.24.99.253, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.1
Packet sent with the DF bit set
..
015362: .Jul 31 09:39:05.306 Napier: CRYPTO_ENGINE: locally-sourced pkt w/DF bit
set is too big,ip->tl=1502, mtu=1443
015363: .Jul 31 09:39:07.306 Napier: CRYPTO_ENGINE: locally-sourced pkt w/DF bit
set is too big,ip->tl=1502, mtu=1443
Success rate is 0 percent (0/2)

I don't seem to be able to change the MTU on the VPN route on the cisco, and the
documentation suggests it determines it automatically. certainly when I ping
from the cisco, it behaves correctly.

I could reduce the MTU on the interface of the host in the cisco lan, and this
does resolve the problem, but I don't want to do this on all the protected
systems, especially when it would apply to their unencrypted traffic too.

I am not sure where to look next, and any help would be greatly appreciated.

Many thanks,

Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20080731/2e62b680/attachment.html 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: config bits.txt
Url: http://lists.openswan.org/pipermail/users/attachments/20080731/2e62b680/attachment.txt 