LARTC - Jun 2003 - [jik@kamens.brookline.ma.us: MSS clamping doesn''t work with masquerading through VPN?]

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/

On Monday 02 June 2003 18:57, Jonathan Kamens wrote:
> 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?
I think it''s the correct list (I don''t know of any other list
you can try),
but it seems that no list member has an answer on your questions.
> 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_fr
>eeze>. 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/
Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

On 2 Jun 2003 at 19:10, Stef Coene wrote:
> On Monday 02 June 2003 18:57, Jonathan Kamens wrote:
> > 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?
> I think it''s the correct list (I don''t know of any other
list you can
> try), but it seems that no list member has an answer on your
> questions.
  In that case I''ll take a wild stab.  I''d guess that the
traffic
passing through the clamper is not TCP at that point -- it''s either 
UDP or ESP, and therefore unaffected by TCP MSS clamping.  Use 
IPTables to log the packets passing to your remote, and see what they 
are.  I''m too lazy to reread your setup, but I suspect you''d
need to
originate the tunnel from Linux and not from XP in order to capture 
TCP.
  Can you drop the MTU in DUN somehow...?

Peter E. Fry

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

>  From: "Peter E. Fry" <pfry-lists@redsword.com>
>  Date: Tue, 03 Jun 2003 22:33:08 -0500
>  
>    In that case I''ll take a wild stab.  I''d guess that
the traffic
>  passing through the clamper is not TCP at that point -- it''s
either
>  UDP or ESP, and therefore unaffected by TCP MSS clamping.  Use 
>  IPTables to log the packets passing to your remote, and see what they 
>  are.
Your guess about the cause of the problem was wrong, but your
suggestion for debugging it helped me find the solution!

I was specifying the MSS clamping with "-A FORWARD", but apparently
the packets in question were never going through the FORWARD chain
because they were being NATed.  So I added a rule to my nat table, and
now the MTU clamping works.  In other words, in addition to this:

  iptables -t filter -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS
--clamp-mss-to-pmtu

I now have this as well:

  iptables -t nat -A POSTROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS
--clamp-mss-to-pmtu

I guess the problem I had is what comes from trying to apply a
cookbook without fully understanding it.

Question: Is it worth mentioning this in the LARTC guide in the
section that talks about MSS clamping, so that other naifs like me can
avoid this problem?

Thanks,

  Jonathan Kamens
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/