OK, so I think I figured out the “best” way to VPN a Windows 2K/XP machine (and maybe older versions of Windows with the MSL2TP client; I haven’t tested that). Use SafeNet SoftRemote (or other capable IPsec client) to do IPsec, ESP, tunnel mode to your Linux box where FreeS/WAN (or derivative) with NAT-T/X.509 patches is running. Disable the automatic IPsec policy for L2TP on the Windows client; SafeNet might do this by default. Now make an L2TP connection more or less as you normally would, skipping any steps that interact with Windows’ built-in IPsec stack. Voila: L2TP over IPsec. As long as you don’t check “only connect manually” (I think that’s what it’s called) in the parameters for your VPN connection in SoftRemote, it will automatically bring up the SA when you try to establish the L2TP connection.
A few gotchas in L2TP, at least with rp-l2tp. Make sure the
n_hdlc
module is loaded. Also, you might need to turn your MTU
down. I had to turn mine down to 1300 (with options to pppd) to make
things work reliably. Please note this value wasn’t scientifically
determined; all trial and error. Symptoms of not working were weird
ICMP fragmentation reassembly time exceeded messages outside of the
IPsec tunnel and general freezing when I went to browse some shares or
load an event log from the remote machine in Windows. Don’t forget to
poke holes in your firewall rules to let ppp+
interfaces get where
they need to go (like eth0
in my case).
I’m using the pppd DHCP
plug-in to
assign addresses to L2TP clients. I did not write this, but I’m not
sure where you can download it from these days, so I went ahead and
tared up the sources I built my plug-in from. If you’re the author
and you want me to stop distributing it — or even better, you have
some newer version you want me to point to, drop me a
line. This plug-in worked surprisingly
easily. To build it you’ll need the sources for your pppd, methinks.
In Red Hat this was easy: I went and found the SRPM for my pppd, rpm
-ivh pppd*.src.rpm
, rpmbuild -bp ppp*.spec
, pppd sources now in
your BUILD subdirectory within your RPM build tree. Untar the plug-in
linked above into the pppd/plugins
directory, cd into
pppd/plugins/dhcp
, read its README file, hopefully followed by
you typing make
. (Actually, I didn’t check this first, but you
might want to make clean
before you make
.) Then copy
dhcpc.so
somewhere (mine’s in /etc/ppp/plugins
) and tell pppd
about it with the plugin /etc/ppp/plugins/dhcpc.so
option. Make
sure your iptables rules will let the DHCP responses back in; that
stumped me for a second. Also, I think you need your chap-secrets
file to specify *
for the IP address for whatever user the client
is authenticating as. It seems that once you have the DHCP plug-in
loaded, all clients will probably be using DHCP, and if what you have
in chap-secrets
for the user’s IP doesn’t match what the DHCP
plug-in assigns, you’ll get a Peer is not authorized to use remote
address
kind of message in your logs.
One more SoftRemote tip. In my copy (SoftRemote 10? I don’t know) after I install it in XP, I have to have ZoneAlarm running for SoftRemote to make any VPN connections. You can go into the policy editor, options->firewall settings, and you’ll (hopefully, otherwise I’m crazy) that the “VPN connections require the firewall to be enabled” box is unchecked. Yet you are required to start the firewall. So I went ahead and checked this, hit OK, saved my security policy, exited out of the policy editor, then went back in and unchecked it, saved all over again, and then I didn’t need ZoneAlarm anymore. I note that in Win2K, I didn’t need ZoneAlarm out of the box, so I’m guessing this is an XP bug. (I’ve recreated it on at least one other XP machine.)
While I’m at it, I’ll note that SoftRemote has its own certificate manager, but it appears to just use the system certificate store (unlike SSH Sentinel, which had its own store I believe). If you import certificates with the SoftRemote tool, they end up in your user’s certificate store. If you do it with the certificates MMC snap-in, you can put them in the local machine store and they still work. If you go from the user’s store to the system store, I recommend the following set of events: delete the certificates from the user’s store if they exist (like if you’ve used SoftRemote’s certificate manager to add the certificates in the past), re-import the certificates from the MMC snap-in into the local machine store, then go into the SoftRemote policy editor and check the “My Identity” section for each VPN connection and make sure your certificate is still selected. Finally, I think you do have to tell the certificate manager to trust all root CA keys by going to the (I think) second tab probably called something like “trusted CAs” and selecting the appropriate radio button, which is probably something like “all CA keys.” (I’d love to be more specific, but I’m updating this several days after I found it and a week or so after this entry, and I don’t have the software running on any PC I’m connected to currently.) SoftRemote has displayed some problems with finding the certificate once I move it around, but as long as the MMC snap-in shows that it can verify your personal certificate, and that there’s a private key attached, you should just be able to go to into the SoftRemote policy editor and select the proper key. Also, SoftRemote will fail connecting with an unhelpful error message if your certificate has a problem, so make sure to check the SoftRemote log (right click on the system tray icon, should be an option for “activity log” or some other kind of log in there). It usually has a more verbose and more helpful indication of what went wrong.
I had this other problem where I logged in as local admin on my client PC, joined it to the remote domain successfully over the IPsec+L2TP connection, but then wanted to log in as a user in the domain. Problem is that SoftRemote is apparently incapable of starting any SAs before a user is logged in. So you have this nice option in the XP login screen that says “log in over a dial-up connection,” which includes your L2TP connection… but it won’t go anywhere because the IPsec SA doesn’t exist to the L2TP server, and the L2TP server only allows L2TP connections over IPsec. (You have firewalled port 1701 so it’s only accessible over ipsec0, right?) To get around this I had to use the Windows built-in IPsec as a one time solution.
First tip for using Windows IPsec: uninstall SoftRemote if you have it installed. You can export your policy in the policy manager first if you’d like, but don’t try this with SoftRemote disabled or its services stopped or whatever. I tried this and couldn’t get it to work, messed around with it for the longest time, and couldn’t get Windows’ built-in IPsec to work. I finally uninstalled SoftRemote, and it more or less started working immediately.
There are plenty of resources on the Internet for connecting to
FreeS/WAN with Windows’ built-in IPsec.
http://www.jmgarcia.com.mx/articulos/fswxp.pdf has plenty of screen
shots.
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_ipsec_tools.mspx
has some tips for troubleshooting Windows’ built-in IPsec; I recommend
auditing and enabling the oakley.log
file. I’ve done this plenty
so I mostly figure it out myself rather than following a guide step by
step. Just remember that the tunnel endpoint IP should be the same as
the destination IP for the filter list used, and that you need two
filter lists (one for each direction, mirroring turned off on both).