• CONFIG_PPP

• CONFIG_FIREWALL

• CONFIG_IP_FORWARD

• CONFIG_IP_FIREWALL

• CONFIG_IP_ROUTER

• CONFIG_IP_MASQUERADE

• CONFIG_IP_MASQUERADE_ICMP

For 2.2 kernels:

• CONFIG_PPP

• CONFIG_FIREWALL

• CONFIG_IP_ADVANCED_ROUTER

• CONFIG_IP_FIREWALL

• CONFIG_IP_ROUTER

• CONFIG_IP_MASQUERADE

• CONFIG_IP_MASQUERADE_ICMP

Configure Networking

Now we should setup the networking on our client box. Let's assume that we've configured the external network and that it works. Now we will configure the internal interface of the client to service our intranet.

Interface

We need to first bring up the internal network interface. To do this, add the following to your /etc/rc.d/rc.inet1 (or equivalent) file:

For 2.0 Kernels:

/sbin/ifconfig eth1 192.168.10.253 broadcast 192.168.10.255 netmask 255.255.255.0
/sbin/route add -net 192.168.10.0 netmask 255.255.255.0 dev eth1

For 2.2 Kernels:

/sbin/ifconfig eth1 192.168.10.253 broadcast 192.168.10.255 netmask 255.255.255.0

Filter rules

To set up the remote office, we will want to set up our filter rules that allow traffic to go both directions through the tunnel. Add the following lines to your /etc/rc.d/rc.inet1 (or equivalent) file:

For 2.0 kernels:

/sbin/ipfwadm -F -f
/sbin/ipfwadm -F -p deny
/sbin/ipfwadm -F -a accept -b -S 192.168.10.0/24 -D 192.168.0.0/16

For 2.2 kernels:

/sbin/ipchains -F forward
/sbin/ipchains -P forward DENY
/sbin/ipchains -A forward -j ACCEPT -b -s 192.168.10.0/24 -d 192.168.0.0/16

You may have noticed that these lines look like what we have on the server. That's because they are the same. These rules just say where traffic is allowed to go between these two networks.

Routing

The only extra routes that are needed are created by the script that bring the tunnel up.

Configure pppd

You may not need to edit the client's /etc/ppp/options file at all. You will if the "auth" option is present, or some of the other priveledged options. Try it, and if it fails, a black /etc/ppp/options will work. just keep adding the options from the old file to figure out which one broke it (if it's not obvious) and see if you can get around that. Maybe you don't need them at all. You probably don't if you don't use pppd for anything else.

Configure ssh

As root on the client, run the following lines:

# mkdir /root/.ssh
# ssh-keygen -f /root/.ssh/identity.vpn -P ""

This will create two files, identity.vpn and identity.vpn.pub in the .ssh directory. The first is your private key, and should be kept such. Never send this over the net unless it is via an encrypted session. The second file is your public key, and you can send this anywhere you want, it only serves to allow you access to other systems, and cannot be used to get into your own. It is a text file with one line in it that is your actual key. At the end of the line is the comment field which you may change without fear of breaking the key. an example key looks something like this:

1024 35 1430723736674162619588314275167.......250872101150654839 root@vpn-client.mycompany.com

It's actually a lot longer than that, but it wouldn't fit on the page if I showed the whole thing. Copy your key into the /home/vpn-users/.ssh/authorized_keys file on the server. Make sure that there is only one key per line, and that each key is not broken onto multiple lines. You may alter the comment field all that you like in order to help you remember which line goes with which user. I highly recommend doing so.

Bring up the connection

Now we'll try to actually make the connection to the VPN server. First we'll need to make a single connection to set up the ssh known_hosts file. Run this:

# ssh vpn.mycompany.com

Answer "yes" when it asks you if you want to continue connecting. The server will tell you "permission denied", but that's okay. It's important that you use the same name for the server that you are using in your connection scripts. Now run the following lines. You will obviously need to change the options to suit your setup.

# /usr/sbin/pty-redir /usr/bin/ssh -t -e none / 
	-o 'Batchmode yes' -c blowfish -i /root/.ssh/identity.vpn / 
	-l vpn-user vpn.mycompany.com > /tmp/vpn-device

	(now wait about 10 seconds)

# /usr/sbin/pppd `cat /tmp/vpn-device` 192.168.10.254:192.168.40.254

Note the IP addresses specified on the pppd line. The first is the address of the client end of the tunnel. The second is the address of the server end of the tunnel, which is set to the server's internal address. If all of that seemed to work, move on. If not, check that you have all of the options, and that they are spelled right. If something is still going wrong, check VPN Pitfalls.

Set the routes

Now set the route to send traffic through the tunnel. Just run this:

# /sbin/route add -net 192.168.0.0 gw vpn-internal.mycompany.com netmask 255.255.0.0

You should now be able to communicate with machines on the other side of the tunnel. Give it a try. If it doesn't work, try using ping and traceroute to figure out where your problem might be. If in fact it does work, move on to setting up scripts to do the work for you.

Scripting

Use the vpnd script. Only you may need to modify it a little. Make the following changes:

• Change the variables at the top to match your setup. Most should be just fine as they are, but you can change them should you need to.

• Line 27: add the local and remote IP addresses before $PPP_OPTIONS

• Line 31: Change this line, and the two after it to set routes for your internal nets.

Keeping it running

While bash scripts are generally stable, they have been known to fail. In order to make sure that the vpnd script keeps running, add an entry to the client's crontab that runs the check-vpnd script. I run mine every 5 minutes or so. If vpnd is indeed running, check-vpnd doesn't use much CPU.