luckynutwood wrote
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
