Building an OpenVPN Gateway on a VPS

A VPN server can do more than provide encrypted internet access. With the correct routing configuration, it can also act as a gateway between remote networks.

This is particularly useful in home labs, remote administration environments, and situations where direct inbound connectivity is difficult.

The Basic VPN

A typical OpenVPN deployment contains:

Client
   ↓ encrypted tunnel
VPS
   ↓
Internet

The OpenVPN server assigns the client an address from a private VPN subnet, for example:

10.8.0.0/24

A client might receive:

10.8.0.2

while the server uses:

10.8.0.1

Enabling Routing

Linux does not necessarily forward traffic between interfaces by default.

Check:

sysctl net.ipv4.ip_forward

If the output is:

net.ipv4.ip_forward = 0

enable it:

sudo sysctl -w net.ipv4.ip_forward=1

For permanence, add:

net.ipv4.ip_forward=1

to the appropriate sysctl configuration.

NAT for Internet Access

If VPN clients should access the internet through the VPS, NAT is normally required.

Conceptually:

10.8.0.2
   ↓
VPS
   ↓ NAT
Public Internet

An iptables MASQUERADE rule might resemble:

iptables -t nat -A POSTROUTING \
  -s 10.8.0.0/24 \
  -o eth0 \
  -j MASQUERADE

The interface name should match the actual public interface.

Modern distributions may use names such as:

ens3
enp1s0
eth0

Use:

ip addr

to verify.

Pushing Routes to Clients

OpenVPN can tell clients how to reach remote networks.

For example:

push "route 192.168.1.0 255.255.255.0"

This tells connecting clients:

Traffic destined for 192.168.1.0/24 should go through the VPN.

But this alone does not magically make that network reachable.

Some device must actually provide a path from the OpenVPN server to 192.168.1.0/24.

The Reverse-Gateway Scenario

A more interesting arrangement looks like this:

Remote laptop
      |
      | VPN
      v
     VPS
      |
      | VPN
      v
Home gateway client
      |
      v
192.168.1.0/24

A machine inside the home network connects outward to the VPS.

Because outbound connections usually work through NAT, no inbound port forwarding at home is required.

The VPS can then route traffic for:

192.168.1.0/24

through that VPN client.

This essentially turns the home client into a router.

Required Components

Several things must be correct simultaneously:

• the VPN client remains connected;
• the OpenVPN server knows which client owns the LAN route;
• IP forwarding is enabled on the home gateway;
• firewall rules allow forwarding;
• the LAN knows how to return traffic;
• NAT may be needed if a return route cannot be installed.

This is why routing problems often appear one-directional.

A packet may successfully reach the destination but the reply does not know how to return.

Troubleshooting

The most useful tool is often:

tcpdump

For example:

tcpdump -i tun0

or:

tcpdump -i eth0

Watch where the traffic disappears.

Also inspect:

ip route

and:

iptables -L -n -v

A VPN connection being "up" only proves the tunnel exists.

It does not prove that routing through the tunnel works.

The Main Lesson

VPN troubleshooting becomes much easier when divided into layers:

• Tunnel
• Routing
• Forwarding
• Firewall
• NAT
• Return path

Verify each independently.

A working VPN tunnel is only the beginning.

← Back to Articles