5.4. Server: Configure Networking

If you are building a server that has only one network card, I suggest that you think about buying another, and rewiring your network. The best way to keep your network private is to keep it on it's own wires. So if you do have two network cards, you'll need to know how to configure both of them. We'll use eth0 for the external interface, and eth1 for the internal interface.

5.4.1. Configuring the interfaces

We first should configure the external interface of the server. You should already know how to do this, and probably already have it done. If you don't, then do so now. If you don't know how, go back and read the Networking HOWTO

Now we bring up the internal interface. According to the numbers that we've chosen, the internal interface of the server is so we have to configure that interface.

For 2.0 kernels, use the following:

# /sbin/ifconfig eth1 netmask broadcast
# /sbin/route add -net netmask dev eth1

For 2.2 kernels, use the following:

# /sbin/ifconfig eth1 netmask broadcast

That gets our basic interfaces up. You can now talk to machines on both local networks that are attached to the server.

5.4.2. Setting routes

We can now talk to machines on our local nets, but we can't get to the rest of our internal network. That requires a few more lines of code. In order to reach the other machines on other subnets, we need have a route that tells traffic to go to the Cisco router. Here's that line:

# /sbin/route add -net gw netmask dev eth1

That line tells the kernel that any traffic destined for the network should go out eth1, and that it should be handed off to the Cisco. Traffic for our local net still gets where it is supposed to because the routing tables are ordered by the size of the netmask. If we were to have other internal nets in our network, we would have a line like the above for each net.

5.4.3. Making filter rules

Now that we can reach every machine that we could need to, we need to write the firewall filtering rules that allow or deny access through the VPN server.

To set the rules with ipfwadm, run it like so:

# /sbin/ipfwadm -F -f
# /sbin/ipfwadm -F -p deny
# /sbin/ipfwadm -F -a accept -S -D
# /sbin/ipfwadm -F -a accept -b -S -D
# /sbin/ipfwadm -F -a accept -b -S -D

To set the rules with ipchains, run it like so:

# /sbin/ipchains -F forward
# /sbin/ipchains -P forward DENY
# /sbin/ipchains -A forward -j ACCEPT -s -d
# /sbin/ipchains -A forward -j ACCEPT -b -s -d
# /sbin/ipchains -A forward -j ACCEPT -b -s -d

This tells the kernel to deny all traffic except for the traffic that is coming from the network and destined for the network. It also tells the kernel that traffic going between the and nets is allowed, and the same for the net. These last two are bidirectional rules, this is important for getting the routing to work going both ways.

5.4.4. Routing

For home users, everything will work fine to here. However for the remote offices, we need to do some routing. First of all, we need to tell the main router, or Cisco, that the remote offices are behind the VPN server. So specify routes on the Cisco that tell it to send traffic destined for the remote offices to the VPN server. Now that that is taken care of, we must tell the VPN server what to do with the traffic destined for the remote offices. To do this, we run the route command on the server. The only problem is that in order for the route command to work, the link must be up, and if it goes down, the route will be lost. The solution is to add the routes when the clients connects, or more simply, to run the route command frequently as it's not a problem to run it more than is necessary. So, create a script and add it to your crontab to be run every few minutes, in the script, put the following:

/sbin/route add -net gw netmask
/sbin/route add -net gw netmask