All of lore.kernel.org
 help / color / mirror / Atom feed
* [jik@kamens.brookline.ma.us: [LARTC] MSS clamping doesn't work with masquerading through VPN?]
@ 2003-06-02 16:57 Jonathan Kamens
  2003-06-02 17:10 ` Stef Coene
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Jonathan Kamens @ 2003-06-02 16:57 UTC (permalink / raw)
  To: lartc

I sent the message below to this list over a week ago, and I haven't
seen any response.

If this is not the correct forum for my question, can anyone suggest a
better person or place to which I should direct it?

Thank you,

  Jonathan Kamens

------- Start of forwarded message -------
From: Jonathan Kamens <jik@kamens.brookline.ma.us>
To: lartc@mailman.ds9a.nl
Subject: [LARTC] MSS clamping doesn't work with masquerading through VPN?
Date: Fri, 23 May 2003 12:42:10 -0400

My employer uses a Microsoft VPN concentrator.  I followed the
instructions at pptpclient.sourceforge.net to add support for that
concentrator to my Linux machine; after doing so, I was able to
successfully connect to the VPN and access machines on the other side
of it from my Linux box.

However,, I found that I couldn't use rdesktop to connect to a
Terminal Services server at work.  I tracked down the problem to my
MTU being too high, as documented here:
<URL:http://pptpclient.sourceforge.net/howto-diagnosis.phtml#connections_freeze>.
After setting the MTU and MRU for the VPN connection to 1000 as
documented there, I was able to use rdesktop from my Linux machine.

I have VMware installed on my Linux machine, and I run Windows XP
Professional inside of it.  I wanted to be able to also access the VPN
from my VMware virtual machine, so I followed the instructions found
here: <URL:http://pptpclient.sourceforge.net/routing.phtml#lan-to-lan>
to set up the routing, including doing "iptables --append FORWARD
- --protocol tcp --tcp-flags SYN,RST SYN --jump TCPMSS
- --clamp-mss-to-pmtu" to ensure that the MTU would be reduced for the
traffic from my XP machine as well as the traffic from my Linux box.

Note that I have only one public IP address, the Linux box -- the
VMware virtual machine is on a private subnet and the Linux box does
routing and masquerading for it through the VPN (and SNAT through my
static IP connection).

Even with the MSS clamping in place, the Remote Desktop client on XP
doesn't work -- it fails in essentially the same way that rdesktop on
Linux was failing before I reduced the MTU.  However, I was able to
get the XP client to work by editing the Windows registry to
explicitly set the MTU to 1000 there.

I thought that the MSS clamping was intended to achieve the same
thing.  I'm at a loss to explain what I did wrong to prevent it from
working as intended :-).

I'd rather not leave the MTU set to 1000 for all packets leaving my XP
machine, because that'll reduce my throughput.  I'd really rather have
things work as intended, i.e., have only traffic going through the VPN
be clamped.

Any suggestions for what I might be doing wrong and/or how to debug
the problem further?

Thank you,

  Jonathan Kamens
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
------- End of forwarded message -------
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2003-06-04 10:36 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-06-02 16:57 [jik@kamens.brookline.ma.us: [LARTC] MSS clamping doesn't work with masquerading through VPN?] Jonathan Kamens
2003-06-02 17:10 ` Stef Coene
2003-06-04  3:33 ` Peter E. Fry
2003-06-04 10:36 ` Jonathan Kamens

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.