[Openswan Users] MTU again (netkey fragmentation)
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
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.
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)?
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