[Openswan Users] MTU again (netkey fragmentation)

[Harald Scharf]

OK. It´s me again.

Now here comes my point of view.

KLIPS:
1) The (small) Packet enters LAN Interface 
2) The Kernel makes encryption and routes it to
3) the ipsec0 interface whitch has a (much) higher MTU than ethX
4) ipsec0 sends the (now bigger) packet to the WAN interface
5) if fragmentation is needed here, the ESP PACKETS ARE FRAGMENTED
	
The 5th point is good to watch with iptraf or tcpdump.
On the ethX (WAN) Interface, you can watch ESP fragmented Packets.

NETKEY:
1) The small packet enters LAN Interface
2) The Kernel makes encryption and routes it to an
3) Interface with the SAME MTU as it is in the LAN
4) Kernel says : Packet to big (what is true) and says : fragmentation needed.
5) Difference to KLIPS : the LAN Communication needs fragmentation, not the IPSEC Traffic
6) packet Sender has to agree to the fragmentation, or connection dies.

In the case of KLIPS, fragmentation was the job of the ipsec0 interface.
In the case of netkey, the packets need fragmentation, where on cleartext packets, it
is not needed.

If something is wrong in my descrition, please let me know.
I am happy on any suggestion.

Problem: Servers, with services where fragmentation is not allowed (DF).
In my case: 
Client sends a query to a server (https) -> Server answers with https (DF).
Packet arrives openswan box -> Box sends (fragment) -> Server says NO,
and that is the end of the communication.

Paul: It can not be the solution to lower the MTU, and slow down LAN.
And this will not work on services, which set DF in their packets.


Bye the way : 
Benny >> Go read the RFC's. 
I tought this in a discussion list? There is no reason to flout me.


Regards 

Harald
 


-----Ursprüngliche Nachricht-----
Von: Paul Wouters [mailto:paul at xelerance.com] 
Gesendet: Mittwoch, 28. Februar 2007 19:14
An: Harald Scharf
Cc: Benny Amorsen; users at lists.openswan.org
Betreff: Re: [Openswan Users] MTU again (netkey fragmentation)

On Wed, 28 Feb 2007, Harald Scharf wrote:

> The ICMP messages work well.
> The Problem is: the not-fragmented packets are too big for the ipsec 
> tunnel.
> In the routing environment, without ipsec, the packets can get (in 
> this example) 1420 bytes long.
> When I send the same packet over the tunnel, netkey answers with 
> "fragmentation needed".

IPsec adds another header, making the packet bigger. Lower your mtu, pref on both ends.

Paul