Todd Pearsall wrote:
WARNING: While I don't run IPTables, my understanding of how the CLAMPMSS setting in IPTables (and thereby shorewall) works is by modifying the MSS field in TCP headers as they traverse the router. This works fine for a connection based protocol like TCP, but will do nothing for "stateless" protocols like UDP (or AH/ESP used by IPSec).Charles Steinkuehler wroteUsing overridemtu may not be the best solution, but I think it should work properly. While it doesn't look like it's possible to set overridemtu on a per-connection basis, clamping *ALL* VPN traffic to an MTU that fits through the PPPoE links wouldn't be too bad. If you can get IPTables MSS clamping to work equally well, you should be able to clamp the MTU on only those packets traveling to the troublesome PPPoE endpoint.
For the archives: In the end I was able to get rid of the ipsec.conf overridemtu option on the remote end and instead set the remote ends CLAMPMSS=Yes in shorewall.conf and traffic successful passes. I *think* this a better way to do it since all vpn packets won't be forced to that size.Thanks again Charles for pushing me to see it through, it turned into quite an educational experience. I would have never thought that the solution would be modifcations on the remote end since that end is happily using 4 vpn connections for ages now. I also just realized why the old rsa keys I as using would establish a connection, but the new ones I'm moving all vpns do wouldn't. The old keys were 1024bit, the new ones are 2048bit, so they are still getting dropped somewhere along the way. But I now have time to work that out since everything is up and running.
If you are having Path MTU discovery problems, I think using *ONLY* the clampmss will probably get most things working, but leave strange, nearly unexplainable problems cropping up periodically.
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).
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...
--
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
