[Openswan Users] MTU again (netkey fragmentation)

Harald Scharf h.scharf at nestec.at
Wed Mar 14 05:07:40 EDT 2007

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.
If I lower the MTU in the Tunnel (how suggested) to 1300, I still
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


-----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.

Building and integrating Virtual Private Networks with Openswan:

More information about the Users mailing list