OpenVPN Support Forum

Hello all,
I'm trying to configure my OpenVPN server to provide access to the LAN behind it and I'm having a problem. I'm sure its very simple but my routing knowledge is very limited. Here is my setup.

Server subnet: 10.0.0.0/16
OpenVPN server IP: 10.0.0.4
VPN subnet: 10.8.0.0

Client subnet: 192.168.100.0/24

I can successfully connect to my VPN server and ping its local IP (10.0.0.4) from the client. I cannot reach any other servers on the server's subnet however (e.g. 10.0.0.2).

I am attempting to follow the guide at https://openvpn.net/community-resources ... er-subnet/

I have the following push directive in server.conf



The directions in the link above also state:

Next, you must set up a route on the server-side LAN gateway to route the VPN client subnet (10.8.0.0/24) to the OpenVPN server (this is only necessary if the OpenVPN server and the LAN gateway are different machines).

I think this is what I'm missing. Unfortunately I have no clue as to how to set up this route. I suspect its another option to add in my server.conf but I really don't know.

Here is the routing table on my client when connected:
I'm a competent Linux sysadmin but network routing is a weak point for me. Can someone kindly suggest a solution?

TIA

You are trying to add a static route to a router device .. better read your router manual.

SOLVED:

The following update to the server's firewall rules to allow traffic on local network via LAN interface enp7s0 did the trick:

iptables -t nat -I POSTROUTING -o enp7s0 -s 10.8.0.0/24 -j MASQUERADE

luckynutwood wrote: ↑

Tue Dec 14, 2021 7:30 pm

SOLVED:

The following update to the server's firewall rules to allow traffic on local network via LAN interface enp7s0 did the trick:

iptables -t nat -I POSTROUTING -o enp7s0 -s 10.8.0.0/24 -j MASQUERADE

While that may appear to be a solution, it is not a good one. And note it does not "allow traffic", it merely performs source NAT for the packets. SNAT (or MASQ in this case) is necessary for RFC 1918 networks to route to the Internet, but (in an ideal world) should never be needed for interconnecting RFC 1918 networks. You simply set the routes you need along the way.

Using NAT for this, you really have only allowed one-way communication. Packets go the other way only as replies to the SNAT packets. The LAN hosts cannot initiate connections of any kind to your VPN clients, unless/except where DNAT is in use.

Granted, that might be what you want, but there too, NAT is not the best way to enforce network restrictions. Set your routes as needed, and then use firewall rules (iptables -j DROP or -j REJECT rules in filter/FORWARD) to restrict what you will.

What routes do you need? It's really pretty simple. Every host that will handle your packets needs to have a route to the subnet in question, via a nexthop host which is able to get the packets to their destination.

A few other notes: first, Linux nettools have been deprecated by the kernel for ~20 years. The netlink-based iproute2 package is the replacement. Also, while there is nothing wrong with using an iptables(8) command to set a rule one time, any distro that is still using iptables will use iptables-restore(8) to restore rules at boot.

That said, most distros have moved to nftables. But we here at OpenVPN have not, and as far as I know, we're not considering it. The Netfilter project is going to continue supporting iptables long-term: it's not like ipchains which was only in use in the 2.2 kernel series, but was incompatible with later kernels.

I hope this helps.

regards, rob0

Thank you for your response. I do indeed want one-way communication as I don't want servers on the server's local LAN to be able to reach my OpenVPN clients. Nonetheless, I will educate myself on the routing rules needed to implement a better solution.
Your response does bring up one question however. If I download and install your commercial product, OpenVPN Access Server, it can be deployed with LAN access without adding any additional routes as well. How is that accomplished if not via masquerade rules on the server?

Hi Lucky,

Indeed you are correct in that Access Server will by default use iptables(8) source NAT rules to provide access to RFC 1918 networks. "Do as I say, not as I do." But just as with community openvpn, Access Server can be configured to DTRT with routing. And we have extensive documentation about various routing and NAT settings.

I'm not in sales, and for a small-time user you might not even have to buy a license at all. That said I would encourage you to check out Access Server. One caveat: while community openvpn will work on any Linux/Unix and even MS Windows, Access Server is only supported for a limited set of long-term-support Linux distributions.

Access Server really does provide a lot of added convenience for the admin. If I had bothered to look at it years ago, I would have been using it for my personal VPN needs. But I only started as an AS user after I was hired here. It's of course actively being developed, and cool new features are on the way.

regards, rob0