I have two isolated home networks. One connected to the internet, and a second one for disconnected IOT devices.

I connected an Ubuntu server to both of these networks using separated network cards.

I verified that I can access data from devices in both networks from this server (using the good old curl to fetch http requests). An I can also access the internet from it.

I then installed OpenVPN, and set it up using the instructions from serverspace.

Next step I configured a client and was able to connect to this vpn server from the internet.

When the client is connected it can access the internet and one of the internal networks, but not the other.

from the vpn server, executing route -n I get:         UG    100    0        0 eno1         UG    200    0        0 eno2   U     0      0        0 tun0   U     100    0        0 eno1 UH    100    0        0 eno1   U     200    0        0 eno2 UH    200    0        0 eno2

The vpn client connects to the network and it is assigned the ip address

The connected vpn client:

  • can access the network
  • can access the internet.
  • cannot access any ipaddress from

What is missing on my configurations to allow the vpn clients to access this second network?


I tried adding the NAT commands from the script for eno2 (13.x), but it still did not work... I modified the created file /etc/iptables/add-openvpn-rules.sh with the following content (the part before the space was automatically created by the script):

iptables -t nat -I POSTROUTING 1 -s -o eno1 -j MASQUERADE
iptables -I INPUT 1 -i tun0 -j ACCEPT
iptables -I FORWARD 1 -i eno1 -o tun0 -j ACCEPT
iptables -I FORWARD 1 -i tun0 -o eno1 -j ACCEPT
iptables -I INPUT 1 -i eno1 -p udp --dport 1194 -j ACCEPT

iptables -t nat -I POSTROUTING 1 -s -o eno2 -j MASQUERADE
iptables -I FORWARD 1 -i eno2 -o tun0 -j ACCEPT
iptables -I FORWARD 1 -i tun0 -o eno2 -j ACCEPT
iptables -I INPUT 1 -i eno2 -p udp --dport 1194 -j ACCEPT

running iptables -S I got the following after a reboot:

-A INPUT -i eno2 -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -i eno1 -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A FORWARD -i tun0 -o eno2 -j ACCEPT
-A FORWARD -i eno2 -o tun0 -j ACCEPT
-A FORWARD -i tun0 -o eno1 -j ACCEPT
-A FORWARD -i eno1 -o tun0 -j ACCEPT
New contributor
The Fabio is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • 1
    Is the VPN server also the default gateway for all devices, or is it separate? If it's separate, do the devices in question (or their gateways) have a route to your VPN network?
    – user1686
    2 days ago
  • no, each of the 12.x and 13.x networks have their own gateways (they are isolated from each other). The devices from 12.x and 13.x don't need to access my vpn clients, but the reverse would be true, as I would like to access them when I am out of the house
    – The Fabio
    2 days ago
  • It's not a matter of who needs to access what, though. For bidirectional communications, there need to be routes in both directions regardless of which side initiates the communication – your devices still need a route to the VPN so that they could reply to a VPN client. (Rules/policies can be enforced using the firewall.) Do you have admin access to those gateways, and could you create static routes on them? (If not, the alternative is NAT.)
    – user1686
    2 days ago
  • my understanding of routes is very limited. And I have not intentionally configured routes for the devices on 12.x (which is working for the vpn clients). I have full admin rights everywhere in these networks
    – The Fabio
    2 days ago
  • Right, then check whether the gateways have that possibility. (Some don't...) They need a static route to the VPN network ( via your server as the "gateway"
    – user1686
    2 days ago

1 Answer 1


First, the firewall on the VPN server (i.e. the iptables "FORWARD" chain) must allow the packets being sent and received.

Second, all your devices need to have routes back to the VPN network, otherwise they only receive packets from the VPN clients but have no way of responding to them.

For example, the devices on the 12.12.* network (or more commonly, not the devices themselves but that network's gateway) would need a route " via".

If that's not possible to do, your alternative is to make the VPN server perform SNAT (that is, source address "masquerading") between the two networks. With SNAT, all packets from VPN clients will look like they actually come from the VPN server itself (i.e. from – which in your case is on the same network as your devices and therefore is something that the devices already know how to reach.

It seems that the VPN install script you were using (which does a lot of things) actually adds iptables SNAT rules for one interface; you can find them in /etc/iptables/add-openvpn-rules.sh (lines 963-977 in the script). The relevant rules look like this – using iptables MASQUERADE action:

iptables -t nat -I POSTROUTING 1 -s -o $NIC -j MASQUERADE

along with, of course, rules to allow the forwarded packets to go through in general:

iptables -I FORWARD 1 -i $NIC -o tun0 -j ACCEPT
iptables -I FORWARD 1 -i tun0 -o $NIC -j ACCEPT

Since you have two networks on two interfaces, you need to duplicate those rules (or rewrite them in a different way).

  • There is much more to it then only adding the forward rules in order to allow the vpn clients to talk with the two networks... I will vote up, as you have helped me find this is the case with your answer. the solution was to 1. not use the script as i discovered, it is pretty sh**, 2. reinstall the vpn server with ubuntu 18.04 (was 20.04), and the vanila openVpn works on it out of the box.
    – The Fabio
    2 hours ago

Your Answer

The Fabio is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.