Masquerade NAT OpenVPN

| September 23rd, 2010

Not a full tutorial, but pointers to how I set up Masquerade NAT OpenVPN.

Primary Reading: http://www.secure-computing.net/wiki/index.php/OpenVPN/Routing

OpenVPN Host: has a network that needs to NAT into OpenVPN client network. Internal IP: 192.168.1.5; VPN IP: 10.0.10.1/24
OpenVPN Client: NAT to internal network(s). VPN IP: 10.0.10.6; Internal network: 192.168.2.0/24

You HAVE to use client/server – no static or bridging! So you have to use TUN (makes sense since you’re doing routing here).

Start simple – Try to get the host talking with the client’s internal network before attempting, then add the rest of the network. Remember to diagnose the small pieces before trying to make sure the whole thing works.

Ok, finally commands needed:

You definitely need to set ccd and iroute. In the example, set in the server.conf:

push “route 192.168.1.0 255.255.255.0″
route 192.168.2.0 255.255.255.0

In ccd/client, place:

iroute 192.168.2.0 255.255.255.0 # let’s openvpn know to route packets to this client

That’s all you should have to do on openvpn. The rest is routing… Let’s start on the client…

enable net.ipv4.ip_forward=1 in /etc/sysctl.conf (and if you don’t want to restart, echo 1 > /proc/sys/net/ipv4/ip_forward)

Add the masquerading rule to the iptables:

iptables –table nat –append POSTROUTING –out-interface eth0 -j MASQUERADE
iptables –append FORWARD –in-interface eth1 -j ACCEPT

Ping a client internal IP address from the openvpn host such as 192.168.2.1. troubleshoot troubleshoot troubleshoot…

After you get that going, let’s allow the whole openvpn host network to communicate to the client network. Enable IP forwarding on the openvpn host computer¬† with the same enable net.ipv4.ip_forward=1 in /etc/sysctl.conf (and if you don’t want to restart, echo 1 > /proc/sys/net/ipv4/ip_forward).

On your router (in 192.168.1.0/24 network), add a routing table such as:

network: 192.168.2.0 netmask: 255.255.255.0 gateway: 192.168.1.5

Test from another computer and that should conclude the setup…. It annoying took me several hours to come to these very simple commands.

Of course, don’t use 192.168.x.x – it’s just too crowded and you risk having overlaps unless you know for sure no one will ever connect remotely from a public network that is using one of these IPs. You are better off with a seldom used private block such as 172.16.0.0.

Leave a Reply