This post assumes you have a working vpn connection as outlined in my last post and you are using a TUN device. A properly set TAP VPN automatically has access to whatever network the host VPN server has access to.

Site to Client (Road Warrior) Setup:

First thing to do is make sure ip_forwarding is enabled on the server.

grep ip_forward /etc/sysctl.conf # ubuntu (maybe debian specific?), it’s somewhere else on redhat and other distros
net.ipv4.ip_forward=1

If it is not enabled, enable it and do a

echo 1 > /proc/sys/net/ipv4/ip_forward

If not, you’ll have to restart your system for the /etc/sysctl.conf settings to take effect.

Next, add push “route MYNETWORK MYSUBMASK” on the server.conf, for example push “route 192.168.50.0 255.255.255.0″ if you are using PKI.

This will NOT work if you’re using a static key because static key clients do not honor push commands. If you’re using static, you have to add route MYNETWORK ¬†MYSUBMASK to the client.conf.

You’re done if the vpn server happens to also be your default gateway/router for your network such as a DD-WRT, IPCop, or PFSense. If you’re like me, and your VPN server is different from your router, go into your router and add a route so that traffic can go back to your client. The interfaces are different, but you effectively have to add:

route add -net VPNNETWORK netmask VPNSUBMASK gw VPNSERVERIP dev lan0

Ping an internal lan ip address from a vpn client and it should work… If not, double check your routes and make sure you established a path to the internal network and back to the client. Remember, even if a connection starts from a client, it still is a 2 way connection! There needs to exist a path for packets to be sent back to the client (usually… =P unless you want to only send ping requests and get no replies!).

Leave a Reply