Topic: IPSec - Problems with packet fragmentation.

[nsh]

Does anybody have experience dealing with MTU size or packet fragmentation issues with FreeS/WAN? Specifically information and/or a howto on using the overridemtu=x statement in ipsec.conf. - The pros, cons, when to use it, etc.
 
My situation is as follows:
 
I have a central office connected by VPN to two branch offices using SME 5.5 with updates, and FreeS/WAN.  All three LAN’s use Win2k Pro clients and we run a Pervasive SQL client/server application.  The central office has a 2-megabits-per-second symmetric connection to the Internet and the branch offices each have fractional T-1 lines (768Kbps) from a tier-1 (well positioned) ISP.  In addition to getting lockups and dropped connections the SQL client program ran so slow it was unusable and we have since implemented a Win2k Terminal Server at the central office.  This works “okay”, but I consider it to be a very “clunky” solution and we still get lots of dropped sessions.
 
I believe this is because of ICMP blocking along the way???
 
The fact that bugs me is:
 
When I do “tracert” from a Windows box in the DMZ at the central office I get only a few hops past our gateway before I hit stars (request timed out.).  Also, when I do the reverse trace route, that is, from a windows box at the ‘branch’ office back to the central office, I get the other half of the route and it stops at the same spot.  However, when I do a traceroute from a Linux box in the DMZ at the central office – Bam! – a zippy 13 hop route comes up every time!
 
Is there an issue with the Windows trace route packets and the offending router?  Is this a clue as to why the Windows applications have problems?
 
Thanks in advance for any help on this.
Sorry this is a multipart question and a long-winded post, but this is how we learn...

[nsh]

Since nobody has replied to this post I decided to update my information and findings in the hopes that someone will find this material useful.
 
The default MTU size of FreeS/WAN IPSEC is very large (16260) and relies on “path MTU discovery” to fall back to an appropriate size (a size that works).  It seems this system may not be workable anymore due to a growing number of black hole routers blocking the ICMP traffic that path MTU discovery relies on.  The solution is to override the default MTU size in the ipsec.conf file.  An optimum size is 1360 (follow the links below for documentation).  To set the MTU size edit the ipsec.conf file and add the line to the “config setup” section as follows:
 
overridemtu=1360

Of course this should be done with templates (the e-smith way).  Restart ipsec.
 
# service ipsec restart
 
This should be done on the server and client.

It turns out that the lockups and dropped connections were due to very poor service from the ISP that serves our central office.  However, Windows based SQL client/server application still runs too slow even with a perfect route and still requires a Terminal Server for remote users. – “Clunky”
 
Windows trace route uses ping so the ICMP blocking router at the edge of our ISPs network prevented me from seeing a full route - ping on Linux mo better!
 

I found the following documents helpful in this process.

http://harlech.math.ucla.edu/services/ipsec-server.html

http://www.freeswan.org/freeswan_trees/freeswan-2.01/doc/background.html