ClearOS PPTP Multi-Subnet Magic

ClearOS is the latest incarnation of ClarkConnect, a linux-based router/network appliance distribution produced by the similarly re-branded Clear Foundation.

This post will show you how to gently abuse Gateway Mode to set up a single PPTP tunnel for use with multiple private subnets if you need to use a standalone VPN server. This does not apply if your VPN server is the gateway for your private subnets.

If you run a large network chances are you don't want to bugger up your clients' ability to pptp out. That means, for all practical "supported" purposes, you can't use your ClearOS/CC gateway(s) as PPTP servers. The answer of course is to set up a "standalone" VPN server. If you're working with a $0 budget or you pay for your rack space this might not be an attractive solution. You can always turn an existing physical server into a VPN gateway but for the purposes of this guide we're going to assume you have a dedicated server or virtual machine.

In both cases the machine needs to have no less than two ethernet interfaces. If you're using a VM I find that Clear fits nicely into 96 megs of ram with 20 megs room to breathe once you've trimmed off all the crap you don't need (hald, messagebus, iscsid, etc - anything you won't use on a VM unless you're an X nut). Use


chkconfig --list



chkconfig --level 12345 <service name> off

for every excess service that loads in runlevel3. If you use physical hardware you will need to ensure both NICs are plugged into a switch otherwise they won't come up on boot (or, naturally, you can alter the networking init script).

For this example, you have three private networks at headquarters:

And your client will be on a local NATted subnet of say

Log into the webconfig of your new VPN server. Make sure Gateway Mode is selected. Set eth0 to external mode and assign a routed public address and gateway to it, this is the IP you're going to come in on. Now for each of the private networks add an IP to a virtual interface ON ETH0. Add an IP somewhere that will never be used to eth1 thus:


eth0 - netmask gw (this is our public ip) eth0:1 - netmask eth0:2 - netmask eth0:3 - netmask --- eth1 - netmask (put it on a subnet you don't use)

By now you're wondering why we have this dummy eth1 that does nothing. It's very simple - we're tricking CC into routing these subnets over the vpn by using the built in Gateway Mode. I can't stress this enough: what we're doing is not ideologically correct. It is, however, clean and simple.

Enable the PPTP server if you have not already done so and set the IP pools to some unobstructed address space on one of your private subnets. Make sure the ClearOS firewall is happy passing GRE (it will tell you if it's not on the PPTP webconfig page).

Now on the client end you're going to create a PPTP connection just like you always would except for one twist: once the connection is established add the private subnets to the client's routing table on the ppp interface thus:


# pon clearvpn # route add -net dev ppp0 # route add -net dev ppp0 # route add -net dev ppp0

And presto! You can talk to any host on any of those networks with one IP and one tunnel thanks to a gentle abuse of Gateway Mode. I like to speed this up by adding those lines to a short shell script.

If you're a windows user, leaving Use Remote Gateway checked in the connection preferences will get you the same effect with one small hitch - all of your traffic (web browsing, chat etc) will be routed through your VPN and any time you connect or disconnect whatever open connections you have will be reset.

Without getting too much into details you want to (at a CLI) type:

route print

remember the hex number for your PPP connection. Type:

route add mask metric 2 if (hex number)

You probably don't need the metric bit but some of the people connecting to my particular vpn server will sometimes be connecting to their own subnets and that's bad for routing. Substitute with the private IP your VPN server sits on in the same subnet as the PPTP IP pool.

Naturally, replace with whatever private subnet you're trying to add (you don't need to do the subnet you're actually put on by the PPTPd, that's automagic). For additional subnets: Lather. Rinse. Repeat.

Everything I've read so far says windows will automagically detect what interface to use based on the gateway you specified but that hasn't worked for me. If it works for you, great! Use the -p flag to save the routes to your registry. You will find however that there is nothing static about windows interface numbers particularly when dealing with on-again-off-again VPN connections.

Gentoo TFTPd

TFTP is most commonly used these days to remote boot small images, move firmware and configuration details. Despite its name it shares little in common with FTP other than it's primary purpose: moving files. This post will leave you with a configured and running TFTP daemon on Gentoo.

There are a number of TFTP servers in portage, for the sake of expedience we'll only look at atftpd.

# emerge atftp

Now create a root directory to serve files from and change its permissions:

# mkdir /var/tftp
# chown nobody: /var/tftp

Edit atftp's configuration file to look like this:

# nano /etc/conf.d/atftp

# Config file for tftp server

TFTPD_OPTS="--daemon --user nobody --group nobody"

Now drop the image or whatever you plan on transferring into /var/tftp. Start the server:

# /etc/init.d/atftp start

Run this to make is start on boot:

# rc-update add atftp default

And away you go!

It looks sort of like this...

When talking about the hosting platform I use to deliver the BKN sites it's hard to get across the makeup of the network to someone who's not familiar with virtual machines and vlans. This diagram illustrates how the network is logically divided and connected:

One managed switch is divided into an external vlan and an internal vlan.  This prevents traffic from the private network from crossing over onto the upstream network which is also patched into the external side of the switch. There are currently four physical servers and each one has a physical (cat6) connection both to the external vlan and the internal vlan ports on the switch. It's safe to think of the virtual machines as tiny servers stuffed in a physical server's package. Inside of the physical server there are virtual network connections that function like real world cables and switches.

Any number of virtual machines may route for the internal vlan and since every physical server is connected to both the external and internal sides of the switch the physical location of the router VM can quickly move to or be replaced at any other server. This opens up not only the option to live-migrate the virtual machine without dropping connections but also run a standby router (or small army) with IP failover that can automatically cut in if the active physical server fails. Not yet implemented yet at this location but I'm working on it.