[Openswan Users] MTU problems - Openswan to freeswan

Cameron Davidson cam73 at aanet.com.au
Sun May 28 04:53:10 CEST 2006


I don't understand how MTU issues within openswan are supposed to be 
resolved, and the problem for me is that they are not.
A vpn over mtu=1500 connections reports a tunnel mtu of 1428 (via icmp 
reply to big ping packet),
while a link between an mtu=1500 site and one with mtu=1492 reports the 
tunnel mtu is 1444.

For a long time I have had a 3-way vpn setup running between two adsl 
gateway boxes (call them A and B, which started as RH7.3) running 
various versions of superfreeswan and openswan v1, on various 2.4 
kernels. The third gateway (C) on cable is a Snapgear Lite+ v1.7.12.
Initially they all ran on links that were mtu=1500, and everything was 
fine.
These are all subnet-subnet tunnels.
Recently I upgraded A and B to Centos 4.3, and openswan to 2.4.5 (using 
the netkey kernel IPSEC code).
I upgraded A first and it was able to establish a good vpn link to B, 
after a bit of tinkering with the config files. This link uses X509 
certificates.
Then I upgraded B and got that link working again.

Now, the snapgear link has been unreliable because the cable operators 
have been changing IP address, even the nexthop address, at increasing 
frequencies, and the owner decided to go to adsl with a static IP, but 
is required to use PPPoE, using the client inside the snapgear. So the 
snapgear knows its wan port has mtu=1492, but the vpn mtu is set to 1444.
Any ping packet I send  from A to C (or B to C), with raw packet size 
between 1439 and 1444 gets encrypted as an ESP packet between 1493 and 
1500 bytes.  These cause an icmp fragmentation-needed reply from C's 
nexthop router, which seems to be ignored by  everything at end A.

I suppose I could use the overridemtu option, without actually losing 
any capacity, but I don't understand why it is getting it wrong.

One complicating factor was that I had to rebuild kernels on both Centos 
systems - A did not have my ethernet card, and B paniced in SMP mode.
System A now has a standard 2.6.16.18 kernel, and B has a rebuilt, 
stripped down rebuild of the Centos kernel 2.6.9-34.  There is always a 
chance I've left out something vital, but I can't see anything obvious.

Cheers,
Cameron.


More information about the Users mailing list