Accessing LAN resources when OpenVPN is not LAN's GW
Posted: Sun Dec 25, 2011 4:49 pm
The scope of this tutorial is to give some hints on accessing OpenVPN's LAN resources when OpenVPN software is not the default gateway of the local network, ie OpenVPN is installed on some computer/server and not on the router.
The concept
Every computer when sending a packet to some address need to know where to send. In modern systems this is done by having a routing table, in which every line indicates where to send the specific packet. The routing line consist of a destination network, a netmask to delimit the network bits, the gateway, ie remote ip which will handle the packet, and the interface name (or IP) thru which the packet will be send. There are default routes in the routing table, which indicates where to send packets destined for the self interface, for the loopback desination, for the local lan computers and a default route which does not meet the other criteria. The default route is defined with zeroes, ie network 0.0.0.0 and netmask 0.0.0.0, and as the gateway IP it has some local router's IP, or the ISP's gateway's IP. This rule is named as a general or default route. If computer needs to send a packet that is not specified by a more specific rule, it is send to the default GW as is specified in the default rule.
It's often when new OpenVPN users starting to join remote sites succesfully install OpenVPN and configure firewall and iptable rules, but still have problem accessing remote resources.
Suppose we set up a OpenVPN on some other computer in the LAN. The VPN's IP and remote site's LAN's IPs are not known to the LAN hosts, ie, there is no entry in the routing table, which will specify where to send the packets for those networks. So the hosts will send the packets to the default gateway of the LAN, which (by default in networking) will drop this packets as the gateway also does not know what to do with such destinations packets. For this tutorial we will use this kind of configuration:
Site A
Local network is 192.168.0.0/255.255.255.0.
Default gateway have IP 192.168.0.1 (the common configuration).
Ip of the host running OpenVPN is 192.168.0.A, where A may be any from 2 to 254.
The hosts have IPs like 192.168.0.x, where x is 2 to 254 and different from A (the OpenVPN's host's IP).
Site B
Local network is 192.168.1.0/255.255.255.0.
Default gateway have IP 192.168.1.1 (the common configuration).
Ip of the host running OpenVPN is 192.168.1.B, where B may be any from 2 to 254.
The hosts have IPs like 192.168.1.x, where x is 2 to 254 and different from B (the OpenVPN's host's IP).
The VPN IP's are from 10.8.0.0/255.255.255.0.
In discussing this mater it is not important which site is server or client, and what IPs get the TAP interfaces. To resolve this routing issue there are 4 methods:
Method 1
As obvious it is, move the OpenVPN software to the LAN's default gateway. As there are situation where this is not possible (a simple router which can't run OpenVPN), this method is the best for future expandings, as adding more remote sites will not involve on return to the routing issues.
Method 2
Adding a static route for remote network to the every host's routing table. On every hosts we have to add a route like this:
For example, on every host from site A we have to add two routes:
The route for VPN network 10.8.0.0 can be ommited, but it is not recommended.
The same way we add routes on the Site B, to show the hosts where to route the packets for remote site:
If there will be a 3rd site, we must add another route for the new remote network in the same way.
The routes have to be added on default LAN's gateways too. Althought, it seems that many routers are able to return responces back without adding routers for the remote networks.
Method 3
This method implies adding same routes as in method 2 only on the LAN's default gateway. So the redirecting will be held by the router and we don't need to add routes on every host. Of course, this is possible if the router permits modifying routing table and iptable.
As in method 2, on the default router we add routes to remote sites:
For example, on default gateway of the site A with IP 192.168.0.1 we have to add two routes:
But this will only show the gateway where to send packets originating from itself. We also need to show how to route packets for remote site from local hosts. For this we have to add a rule to the routers iptable which will tell that all packets incoming from LAN interface and have the destination to the remote site network must be redirected to the OpenVPN host. Most routers which handle wider customization have the ability to use unix like command "iptables". So, we use the iptables rule like this:
For example, on default router from site A we will add:
The same way we add rules on the default router from site B.
If we add a 3rd site, then we will have to add to the other sites a route to the 3rd site network in the same way.
Method 4
We will do masquerading. This way we will masquerade all packets from remote network and tunnel itself to the OpenVPN host local IP, so every host on the LAN will believe that the packets are comming from the OpenVPN host, so them will return packets to that IP.
If OpenVPN host is set up on unix system, then we just use "iptables". For windows systems we will have to search and install a simple (and free if we are lucky) forward and nat software. So, the iptables rule will be very simple:
That's it. Add on every OpenVPN host on every site.
But remember, all this methods will work if we enable forwarding on the computer wich will run OpenVPN software. To check forwarding on unix systems see the output of
If responce is "0" then forwarding is not enabled, if responce is "1" then forwarding is enabled. To enable forwarding execute or add to /etc/sysctl.conf the line
By default, in windows systems forwarding is disabled, even in server's versions. To enable forwarding in windows XP/2003 we need on the "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" registry key add an entry with name "IPEnableRouter" type "REG_DWORD" and value of "1". All without quotes. For windows 2008/7 from an elevated command prompt send command where "name of the NIC" is local LAN interface name, and OpenVPN interface name.
The next thing we must check is iptables rules to allow incoming and forwarding packets. In windows disable firewall on TUN interface, also in Windows Vista and more recently ones set the TUN interface to Work or Home type. In linux add a rule to accept incoming packets from TUN adapter: and allow forwarding:
And don't forget about OpenVPN's internal routing. In server's config file we push the route to server's LAN to the client's with
Also the same way we will push the route for every remote site LAN to other clients
This is needed when connectin more sites.
We have to tell OpenVPN server where to route packets for client's lan with the
And ofcourse create a ccd file with name like common name of client's certificate and write in it
In our examle, the OpenVPN server config (if it is on site A) will contain:
The site B's ccd file will contain
This covers most of the configuration to able hosts and devices from one site to reach hosts and devices on other site, considering that target hosts has their firewalls disabled or are configured to accept incoming packets.
Related reading: topic98.html
The concept
Every computer when sending a packet to some address need to know where to send. In modern systems this is done by having a routing table, in which every line indicates where to send the specific packet. The routing line consist of a destination network, a netmask to delimit the network bits, the gateway, ie remote ip which will handle the packet, and the interface name (or IP) thru which the packet will be send. There are default routes in the routing table, which indicates where to send packets destined for the self interface, for the loopback desination, for the local lan computers and a default route which does not meet the other criteria. The default route is defined with zeroes, ie network 0.0.0.0 and netmask 0.0.0.0, and as the gateway IP it has some local router's IP, or the ISP's gateway's IP. This rule is named as a general or default route. If computer needs to send a packet that is not specified by a more specific rule, it is send to the default GW as is specified in the default rule.
It's often when new OpenVPN users starting to join remote sites succesfully install OpenVPN and configure firewall and iptable rules, but still have problem accessing remote resources.
Suppose we set up a OpenVPN on some other computer in the LAN. The VPN's IP and remote site's LAN's IPs are not known to the LAN hosts, ie, there is no entry in the routing table, which will specify where to send the packets for those networks. So the hosts will send the packets to the default gateway of the LAN, which (by default in networking) will drop this packets as the gateway also does not know what to do with such destinations packets. For this tutorial we will use this kind of configuration:
Site A
Local network is 192.168.0.0/255.255.255.0.
Default gateway have IP 192.168.0.1 (the common configuration).
Ip of the host running OpenVPN is 192.168.0.A, where A may be any from 2 to 254.
The hosts have IPs like 192.168.0.x, where x is 2 to 254 and different from A (the OpenVPN's host's IP).
Site B
Local network is 192.168.1.0/255.255.255.0.
Default gateway have IP 192.168.1.1 (the common configuration).
Ip of the host running OpenVPN is 192.168.1.B, where B may be any from 2 to 254.
The hosts have IPs like 192.168.1.x, where x is 2 to 254 and different from B (the OpenVPN's host's IP).
The VPN IP's are from 10.8.0.0/255.255.255.0.
In discussing this mater it is not important which site is server or client, and what IPs get the TAP interfaces. To resolve this routing issue there are 4 methods:
Method 1
As obvious it is, move the OpenVPN software to the LAN's default gateway. As there are situation where this is not possible (a simple router which can't run OpenVPN), this method is the best for future expandings, as adding more remote sites will not involve on return to the routing issues.
Method 2
Adding a static route for remote network to the every host's routing table. On every hosts we have to add a route like this:
Code: Select all
route add <remote_network> mask <remote_netmask> gw <openvpn_host_ip>
Code: Select all
route add 192.168.1.0 mask 255.255.255.0 gw 192.168.0.A
route add 10.8.0.0 mask 255.255.255.0 gw 192.168.0.A
The same way we add routes on the Site B, to show the hosts where to route the packets for remote site:
Code: Select all
route add 192.168.0.0 mask 255.255.255.0 gw 192.168.1.B
route add 10.8.0.0 mask 255.255.255.0 gw 192.168.1.B
The routes have to be added on default LAN's gateways too. Althought, it seems that many routers are able to return responces back without adding routers for the remote networks.
Method 3
This method implies adding same routes as in method 2 only on the LAN's default gateway. So the redirecting will be held by the router and we don't need to add routes on every host. Of course, this is possible if the router permits modifying routing table and iptable.
As in method 2, on the default router we add routes to remote sites:
Code: Select all
route add <remote_network> mask <remote_netmask> gw <openvpn_host_ip>
Code: Select all
route add 192.168.1.0 mask 255.255.255.0 gw 192.168.0.A
route add 10.8.0.0 mask 255.255.255.0 gw 192.168.0.A
Code: Select all
iptables -A PREROUTING -t mangle -i <LAN_interface> -d <remote_network>/<remote_netmask> -j ROUTE --gw <openvpn_host_ip>
Code: Select all
iptables -A PREROUTING -t mangle -i <LAN_interface> -d 192.168.1.0/255.255.255.0 -j ROUTE --gw 192.168.0.A
iptables -A PREROUTING -t mangle -i <LAN_interface> -d 10.8.0.0/255.255.255.0 -j ROUTE --gw 192.168.0.A
If we add a 3rd site, then we will have to add to the other sites a route to the 3rd site network in the same way.
Method 4
We will do masquerading. This way we will masquerade all packets from remote network and tunnel itself to the OpenVPN host local IP, so every host on the LAN will believe that the packets are comming from the OpenVPN host, so them will return packets to that IP.
If OpenVPN host is set up on unix system, then we just use "iptables". For windows systems we will have to search and install a simple (and free if we are lucky) forward and nat software. So, the iptables rule will be very simple:
Code: Select all
iptables -t nat -A POSTROUTING -o <local_lan_interface_name> -j MASQUERADE
But remember, all this methods will work if we enable forwarding on the computer wich will run OpenVPN software. To check forwarding on unix systems see the output of
Code: Select all
cat /proc/sys/net/ipv4/ip_forward
Code: Select all
echo 1 > /proc/sys/net/ipv4/ip_forward
Code: Select all
net.ipv4.ip_forward = 1
Code: Select all
netsh interface ipv4 set int "[name of the NIC]" forwarding=enabled
The next thing we must check is iptables rules to allow incoming and forwarding packets. In windows disable firewall on TUN interface, also in Windows Vista and more recently ones set the TUN interface to Work or Home type. In linux add a rule to accept incoming packets from TUN adapter:
Code: Select all
iptables -A INPUT -i tun+ -j ACCEPT
Code: Select all
iptables -A FORWARD -i tun+ -o <local_lan_interface_name> -J ACCEPT
iptables -A FORWARD -i <local_lan_interface_name> -o tun+ -j ACCEPT
Code: Select all
push "route <local_lan_network> <local_lan_netmask>"
Code: Select all
push "route <remote_lan_network> <remote_lan_netmask>"
We have to tell OpenVPN server where to route packets for client's lan with the
Code: Select all
route <remote_lan_network> <remote_lan_netmask>
Code: Select all
iroute <remote_lan_network> <remote_lan_netmask>
Code: Select all
push "route 192.168.0.0 255.255.255.0"
route 192.168.1.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0" # This line will be pushed only to other clients, not to the site B client.
Code: Select all
iroute 192.168.1.0 255.255.255.0
This covers most of the configuration to able hosts and devices from one site to reach hosts and devices on other site, considering that target hosts has their firewalls disabled or are configured to accept incoming packets.
Related reading: topic98.html