Todd Pearsall wrote:
Sounds like Path MTU discovery is working for your other locations, but the BellSouth folks are probably dropping ICMP traffic.Thinking about this, I think the only way to reliably fix the problem is to use the overridemtu setting in FreeS/WAN (so path mtu discovery works properly from the internal network's perspective), or to manually force the maximum MTU to a value smaller than 1500 on all affected internal systems (an administrative nightmare)...of course, an exact determination of why path mtu discovery is failing might reveal an alternate solution, but if the problem is being caused by your ISP on one (or both) end(s) of the link, it may not be fixable by you (I can just imagine calling up your ISP's tech support, asking them to change their router settings because they're breaking Path MTU discovery and violating RFC's).
You are correct about the overridemtu as the only option. I thought the CLAMPMSS had also fixed the problem, but it hadn't. It appears that when I set a overridemtu and later removed it or set it to a higher value that the old value was still in effect somehow (even after an ipsec restart).When I set overridemtu to 1200 (very low) it worked, then I tried removing the overridemtu setting CLAMPMSS=Yes and restarting shorewall then ipsec and it still worked. Unfortunately after a reboot it didn't, so I realized CLAMPMSS=Yes didn't actually help, but the overridemtu must have still been in effect. Thinking I had it nail now I started increasing the overridemtu value and restarting ipsec, but it never stopped working. Then I tried the other way and set the overridemtu=1500 and rebooted. As expected the vpn traffic didn't pass so I startred lowing the overridemtu until it did to work to find the max working value (which was 1438 and number I had actually determined as the max value in the initial message, doh!) Anyway it seems that lowing the overridemtu and restarting ipsec did change the setting, but starting low and raising it required a reboot (or probably restarting a different service would have worked.) Also, I'm pretty sure it is on the BellSouth, because all the other locations can talk over the vpn without prolem, but no one can pass traffic to the Atlantis (BellSouth) location without the overridemtu set.
At least with the overridemtu setting, only the VPN traffic gets "squeezed"...everything else can use the full packet size.
Glad to help, and thanks for the final report! Lots of folks never let us know how they finally got everything working.At least it's working now, and you can start "tweaking".
Oh...and I believe you would have had this problem with the commercial router as well, although it would have been a good test for their tech support staff...
I was thinking the same thing. It looks like I will be knocking down the mtu setting on my roadwarrior laptops after all, since they seem to be running into same thing. They couldn't establish connections until I knocked them down to small enough keys that the resulting key file was less then 1438. Now they connect, but I don't they are passing traffic (need to run tcpdump to see what's going on, now that I'm an expert!) Charles, thanks again for the education.
--
Charles Steinkuehler
[EMAIL PROTECTED]
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
