Fwd: NAT for use with OpenVPN

[Phil Staub]

---------- Forwarded message ---------
From: Phil Staub <phil at staub.us>
Date: Sun, Nov 10, 2019 at 4:22 PM
Subject: Re: NAT for use with OpenVPN
To: Morgan Wesström <freebsd-database at pp.dyndns.biz>




On Sun, Nov 10, 2019 at 10:34 AM Morgan Wesström <
freebsd-database at pp.dyndns.biz> wrote:

> > One additional thing. If you by any chance want to communicate with any
> > of the other machines on your LAN from the VPN clients (not just
> > Internet access), you need to add a static route for 10.8.0.0/24
> > pointing to 192.168.1.200 IN YOUR NETGEAR ROUTER or they won't know
> > where to send their replies. Preferably you'd add such a route to each
> > of your LAN machines but it's not strictly necessary since they will
> > send any 10.8.0.0/24 packets to your router which then will route it
> > back properly to your FreeBSD machine. This shouldn't be needed for the
> > basic OpenVPN communication though since as far as your router is
> > concerned, this only involves pushing udp packets to 192.168.1.200 and
> > it already knows how to reach that ip.
> >
>

OK, I removed the lines you specified and added a static route on the
router:

10.8.0.0/24 -> 192.168.1.200

I confirmed that gateway was enabled on FreeBSD and restarted routing.

Unfortunately this didn't really seem to change anything. I'm still unable
to access the internet from a connected client.

So now I'm wondering about something.

Do packets with 10.8.0.x addresses ever actually make it on the wire
between the router and the OpenVPN server? I was under the impression that
the encrypted packets created a tunnel at which the IP address is only
known at the endpoints, which means the OpenVPN client and server
processes, and nothing in between has any access to anything that is going
on within the tunnel. If this is the case, I wouldn't think the router
needs to know how to deal with 10.8.0.x packets.

Furthermore, this pretty much HAS to be the case. The 10.8.0.x addresses
can't be routed across the internet, so the only way they could exist on my
private network would be as a result of NATing on the part of the router,
and I'm pretty sure this isn't happening.

But then this re-opens the question of how the connection happens between
the server end of the tunnel (10.8.0.1) and the public interface at
192.168.1.200. It would seem that there needs to be some routing
information within OpenVPN that makes that connection.

Am I way off here?

Phil