[Vpn-help] MTU packet problems on Linux ...

Matthew Grooms mgrooms at shrew.net
Wed Dec 12 16:39:42 CST 2007


Rodrigo Ferroni wrote:
> 
> Matthew:
> 
> You are right, the problem was related whit the mtu and fragmentation 
> packet.
> 
> First i tried to use ike_frag option (client and server) whit "force", 
> but i had the same result.
> 

IKE Fragmentation only relates to IKE packets and does not influence the 
way IPsec transport packets are handled. This essentially provides 
application layer fragmentation so that IP fragmentation is never used.

Just for clarification: When racoon is compiled with IKE fragmentation 
support, it will always accept packets that include IKE fragments. The 
ike_frag option only influence the way racoon creates packets before 
sending them to a peer. I added the force option to racoon and the Shrew 
soft client so that fragmentation will be used for an initiator first 
packet which is obviously before the feature can be negotiated. This is 
useful for aggressive mode exchanges between peers that have MTU related 
issues.

> Then i look in racoon.conf we have the esp_frag, like said the man, this 
> option is for nat-t in tunnel mode,
> fragmenting the ip packet before the esp encapsulation. this help to 
> work with adsl routers
> that reject UDP fragments. Well didn't work nether because racoon log 
> send me a warning:
> "552" Your kernel does not support esp_frag. I didn't find what is the 
> kernel module is related
> whit this.
> 

This kernel feature is only available on NetBSD. I think we have some 
text in the racoon.conf man page that states this somewhere. In any 
case, TCP packets negotiate a MSS ( maximum segment size ) and set the 
DO-NOT-FRAGMENT bit in the IP header which prevents the option from 
being useful for your situation. It usually only helps for UDP or ICMP 
packets that rely on IP fragmentation.

> Using iptables couldn't understand well the chain in the mangle table 
> tcpmss (maximun segment size)
> (-j TCPMSS --clamp-mss-to-pmtu or --set-mss). this is other thing to 
> keep trying.
> 

Sorry for not being able to provide more concrete examples. I will be 
sure to include more information on this topic when I rewrite that 
section of the client documentation.

> So for now i solve the problem whit another solution, more simple,
> i decrease the mtu size of the interface that is waiting for the vpn 
> connections.
> (eth2 mtu: 1300, the default is 1500)
> 

I have been toying with the idea of making the virtual private network 
adapter use an MTU of 1480 bytes. This could potentially make most of 
these problems go away for the average user. Let me do some testing here 
locally and if things look good, I will post a build. Would you be able 
to test this for me with your adapter reset to the full 1500 byte MTU?

> Thanks again mathew for all your help.
>  

Thank you for testing, providing feedback and your patience :)

-Matthew



More information about the vpn-help mailing list