Split tunnelling

Here is published work I have done getting linux VPN clients to autoconfigure in split-tunnelled L2TP/PPTP environments. There is no standard for this, but there are very widely supported proprietary solutions:

The default behavior

Without any autoconfiguration almost all clients that do not default route will install a route to the network derived by subjecting the near-end PPP interface address to classful interpretation.

Microsoft

Microsoft Windows 2000 and Windows XP (but not Vista) clients will use a DHCP-based transaction on any VPN link they bring up, so long as they have been configured without the "Use default gateway on remote network" option. Microsoft describes the altered DHCP protocol here.

On the server side, in addition to Microsoft, Cisco explicitly supports this feature.

Apple

Darwin Leopard PPP builds contain a proprietary plugin "ACSP" which does essentially the exact same thing as Microsoft's solution, with the exception that it doesn't actually work. At least it has not for me -- perhaps with an Apple VPN server. See the caveats below for why and a solution I plan to publish code for.

Linux

A shell script I have written will allow Linux clients, whether based on racoon or on pluto, to follow the same de-facto standard. It is self contained including instructions. I offer it for distribution with mainstream PPP sources or distro patchsets. Any licensing issues, let me know.

Darwin and BSD

Darwin, and I am assuming by extension at least some flavors of BSD, absolutely will not allow a userspace process to pass packets sourced from 255.255.255.255 onto PPP interface's wire, at a kernel level. As such, the above script will not work on those operating systems (and besides, it uses linux-specific commands.) I have started a PPP plugin to deal with that issue, which forces the transmitted DHCP INFORM packets out the PPP link "by hand."

On Darwin, it is not necessary to actually process the returned packets -- simply sending out the packets by hand will cause the BOOTREPLY packets to queue up and the ACSP module seems to have no problem using them, at least the ones I have tested with a Cisco ASA are correctly installing my routes with this technique. ACSP interoperability seems only broken in the transmit direction. As soon as I bludgeon XCode into submission enough to wrest my work from its ugly maw, I will be publishing that.

UPDATE: sometime I'll dig out the source and work on it again but it is looking like that may be a while. In the meantime, here's a binary that does the trick on Leopard. Tested on i386, may also work on PPC but not tested there. To use: cd /etc/ppp; sudo tar -xvzf dist0.1-splitp.ppp.tgz

Older Darwin OSX builds have even more issues, such as the mere presence of an ip-up script preventing L2TP tunnels from passing traffic, but not, oddly, PPTP tunnels, and the general overall brokenness of VPN behind NATs on anything older than a year or two.

As my day job really ends with Darwin and Linux support about as far as I will be able to take the plugin for BSD is to provide a working linux plugin that will go so far as to read the reply packets, but not actually install routes. I'm looking for someone that wants to complete the BSD stuff based on that, or if nobody steps up I can offer the incomplete code for attic storage in a branch of the PPP distro until somebody needs it to work.