[Users] WinXP-FreeS/WAN interop success, howto, and unresolved issues

[Jim Carter <[EMAIL PROTECTED]>]

I have finally gotten WinXP -> FreeS/WAN (super, v1.99, with X.509 and Nat-T
and kernel patch for ESP-in-UDP) working in this configuration:

WinXP -- NATbox-> -- Internet --+-- Target-hosts
                                |
                                + <-NAT FreeS/WAN

In other words, the FreeS/WAN terminus has one interface, and packets
coming out of the tunnel get NATted, so they will come back to the server.
In our operational environment it makes sense for the client to send its
default route down the tunnel.

I've written up a user support document telling how to set up FreeS/WAN
on Linux and WinXP, plus some notes for setting up the server.  I would
appreciate any comments people might have about technical choices that
we've made.  It's here (if addresses change I'll try to maintain a redirect
page):

    http://ipsec.math.ucla.edu/services/ipsec.html

The following issues were particularly troublesome.  Thanks to all who
replied to my messages, particularly Sam Sgro, and others who discussed
related issues at other sites.

1.  To use ESP-in-UDP (port 4500) for Nat-T, you need to patch your kernel.
Due to technical doubts, SuSE and others do not include this patch in the
standard kernel.

2.  WinXP has a bug in the Internet Connection Firewall, causing it to
trash TCP packets exiting the tunnel.  They appear to be from the target
machine's port 17664 to WinXP's port 48 (others have also seen 40 and 44),
and are dropped.  Turn off ICF.  Others report that 3rd party firewall
products are compatible with IPSec.

3.  WinXP does not use ESP-in-UDP; it sends ESP directly.  Modern
purchased residential gateways know about ESP, but older ones might need
special configuration.

4.  KLIPS on the server cannot distinguish two clients with the same
NATted address such as 192.168.1.100 (the default for Linksys
residential gateways).  They steal the connection from each other.  I
actually set this up and tested it.  This is an important problem in the
home user scenario, since the sysadmin does not want to have to assign
everyone a unique IP address in the 192.168.0.0/16 (etc.) range.

5.  MTU issues abound.  For Linux to use ESP-in-UDP, the server needs a
netfilter rule similar to this:

    iptables -t filter -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
        -j TCPMSS --set-mss 1320

(The number was determined empirically and could be conservative by a
few bytes.)  Otherwise, TCP connections hang the first time a large
packet has to be sent.  --clamp-mss-to-ptmu had no effect whatsoever.
If a particular client has a link MTU smaller than 1500, e.g. PPP
connection, that will not be taken into account.  The reason that ICMP
Frag Needed packets are ineffecive seems to be that they are sent to the
target host with the internal address (e.g. 192.168.1.100) of the client
rather than the post-NAT address of the FreeS/WAN server, so the target
host can't identify which connection needs its MSS reduced.  If anyone
can figure out how to deal with this, *please* let me know.


James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: [EMAIL PROTECTED]  http://www.math.ucla.edu/~jimc (q.v. for PGP key)
_______________________________________________
FreeS/WAN Users mailing list
[EMAIL PROTECTED]
https://mj2.freeswan.org/cgi-bin/mj_wwwusr