[Openswan Users] Problems when using subnet 0.0.0.0/0

[Michael Smith]

Hi Milen,

I've only rarely seen MTU problems with Openswan 2.4.x and NETKEY. As far 
as I can tell, the only common factors were either:
1) the tunnel had a subnet 0.0.0.0/0;
2) or, some other tunnel on the gateway had subnet 0.0.0.0/0.

I think I last saw this with Openswan 2.4.7 on kernel 2.6.18.3. It was 
also present in 2.4.4 + 2.6.11.11.

Sometimes only Windows boxes would be affected -- they would receive ICMP 
fragmentation needed messages but for some reason ignore them. Other times 
both Windows and Linux would fail to reduce packet size because 
the ICMP messages were dropped by one of the IPsec gateways (sorry, I 
forget which).

I think reducing the MTU on the public interface wouldn't help - it'll 
only increase the need for fragmentation. Try the iptables MSS trick, it 
might work.

If you control the servers and clients on both ends, you can try adding 
static routes with smaller MTU on each of them:

ip route add 192.168.7.0/24 via 192.168.168.1 mtu 1300

You could look for an iptables mangle target that could strip the "don't 
fragment" bit on packets.

Maybe you could try KLIPS, it might work differently. (With Openswan 1.0.6 
at least it ignored the DF bit on packets, so they would always be 
fragmented at the IPsec gateway if required.)

Mike

On Fri, 29 Jun 2007, Милен Панков wrote:

> Ruben Laban написа:

> On Friday 29 June 2007, Милен Панков wrote:
> 
> This sounds like a MTU issue. Depending on the ipsec stack you are using 
> (NETKEY or KLIPS), there are various ways to get around this issue. Using 
> overridemtu in the config is one (for KLIPS only) or use iptables to alter 
> the MSS for those packets (for both KLIPS and NETKEY).
> 
> Regards,

I'm using NETKEY, so I changed the MTU directly on the public interface
of the gateway in office 3 - I tried values from 1440 to 500, but this
did not help.