PMTUDiscovery vs ClampMSS

Rob Townley rob.townley at gmail.com
Mon Dec 13 21:06:43 CET 2010


On Mon, Dec 13, 2010 at 2:33 AM, Guus Sliepen <guus at tinc-vpn.org> wrote:
> On Sun, Dec 12, 2010 at 07:11:30PM -0600, Rob Townley wrote:
>
>> Currently, i have nodes with PMTUDiscovery =yes and ClampMSS = yes.
>> When the server does not receive a PMTU request back from one of the
>> clients even when the packet size is very small (say 164), then it
>> reverts to TCP.
>
> That means that communication with the client via UDP is not possible.

The log files from the clients indicate the MTU sizes are being sent
back.  i need ethereal or tcpdump or something.
These same machines in the same network going through a different tinc
"server" will often get sub millisecond response times, but sometimes
get as slow as 1 second of latency for each and every ping.  So i have
a cron job on that tinc server that restarts tinc daemon every hour.
i noticed one difference is that the broadcast address is not set on
the tcp only non-working tinc ip server.

>
>> Should i turn off PMTUDiscovery or should it be ok to leave on?
>
> You should leave it on. The PMTUDiscovery packets are just regular UDP packets,
> if they fail other UDP packets will not be received either. If you would
> disable PMTUDiscovery, tinc would not fall back to TCP and no communication
> with the client would be possible.
>
>> It takes a very long time to do simple pings (1 second or so), so i
>> wonder what else i can do?
>
> Can you check whether non-VPN traffic from the client to the server is slow as
> well, or maybe if there is a high level of packet loss?

i have 3 public internet IP addresses sitting behind a single cable
modem.  Cable Modem goes to a switch and from the switch to 3 NAT
devices.  One firewall is dedicated to wireless laptops.  The wireless
laptops can ping google.com in 20ms, but will often require 1000ms -
4000ms to ping the tinc server hosted on the vyatta box.  i wonder if
by the time the laptop responds with an acceptable MTU, the server has
already lowered the MTU that it does not read the entire packet.

Need debugging level specifically for MTU / MSS size.  i was too tired
and cold to figure out how to grep for either MSS or MTU or TCP.

One thing i have to say is be careful with netsh command in windows.
On both WinXPSP3 and Win2008R2, the firewall can be turned off as a
matter of domain policy, but firewall deny entries still show in the
c:\windows\pfirewall.log.    When windows systems boot up, they
determine if the machine is part of a trusted or untrusted (aka
public) network.  The firewall can be on and off depending on which
trust level it gives to the network.

>
> --
> Met vriendelijke groet / with kind regards,
>     Guus Sliepen <guus at tinc-vpn.org>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk0F2mAACgkQAxLow12M2nvTPACfdi/peZjMPIXKWugBub7kXcUt
> dhAAnjKALHNgUlNLFvBzUUtlBMdhSqNW
> =kqcv
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
>


More information about the tinc mailing list