darkness

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).