[Openswan Users] MTU again (netkey fragmentation)

[Cameron Davidson]

Harald Scharf wrote:
> Hi, Paul and List,
> 
> now i am some stepps nearer to the solution.
> I can reproduce the problem with the following setup:
> 
> RDP-Server--NAT BOX--VPN-BOX---------VPN-BOX-----RDP Client
> 
> The NAT Box is for hiding the real RDP Server to the VPN Network.
> If I try to connect to the RDP Server, I only get the blue desktop,
> but no login.

I had not understood this arrangement before.
The large packets will first come from the RDP server. Therefore the 
routing code on the openswan box at the server end is responsible for 
sending icmp frag meeded messages back to the server. The RDP server is 
then responsible for sending smaller packets.
Did you set the path-specific MTU at both ends? If you only set it at 
the rdp client end then it would not work.

What is the NAT box? does it pass the icmp packets back to the server 
properly?  In situations like these, packet sniffing on all machines is 
very useful.

Can you try something first without the extra NAT complication?
Put a temperary server (or just an XP pro machine) on the left vpn subnet.

> If I lower the MTU in the Tunnel (how suggested) to 1300, I still
> DOES NOT WORK, BUT
> if I set a tcp-mss filter with
> 
> iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1300
> 
> then the connections goes well and fast.
> 
> The Filter
> iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS ----clamp-mss to-pmtu
> does not work, too.
> 
> Now my question:
> How is responsible for lower the MTU because of the ICMP Message?
> The NAT Box or the Originator (RDP Server)?
> 
> Kind regards
> 
> Harald
> 
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Paul Wouters [mailto:paul at xelerance.com] 
> Gesendet: Donnerstag, 1. März 2007 17:35
> An: Harald Scharf
> Cc: users at lists.openswan.org
> Betreff: Re: AW: [Openswan Users] MTU again (netkey fragmentation)
> 
> On Wed, 28 Feb 2007, Harald Scharf wrote:
> 
>> 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.
> 
> ip route change remotesubnet/24 via yourgw dev eth0 mtu 1300
> 
> That ONLY affects the mtu of packets that have to travel through the tunnel
> 
>> And this will not work on services, which set DF in their packets.
> 
> Did you try disabling PMTU like I suggested yesterday? AFAIK, that causes
> Linux to not set the DF flag.
> 
> Paul