Understanding when pfSense will NAT or route directly incoming OpenVPN connections

swinster

Hi,

pfSense 2.6.

I'm working on providing an OpenVPN connection to a virtual lab environment using pfSense. This is not a typical network setup, and I want to understand what configurations affect how pfSense NATs or routes incoming OpenVPN connections. I have managed to configure pfSense to achieve both, and whilst I can make a manual configuration change to go from NAT'ed to routed connections, manually undoing those changes doesn't revert the behaviour. I have to restore a previous configuration to revert the behaviour. I suspect something is changed in an automatic rule somewhere, so I want to understand what configuration changes need to be updated.

Here is a network topology:

OOTB, I configured pfSense with two interfaces, one in each network. As both networks provide a route out via their gateway, I configured each interface to use this gateway (as per the diagram).

In this configuration, pfSense NATs the OpenVPN connection when a request is sent to a VM in Network 2, and the host can then replies to where the traffic came from. All is Good.

This is a pcap take from the VM 10.160.75.252:

If I DELETE (not disable) the gateway from the pfSense interface attached to Network 2 such as:

pfSense now routes the OpenVPN connections directly. As the VMs in Network 2 have a default gateway set to the non-pfSense router, they will try send reply traffic to this unknown network via this gw, so we have asynchronous routing, which of course fails.

We could add a static route to the VM (or even update their default gateway) to ensure traffic is routed via pfSense, but this is not the question....

If I re-add the gateway on the pfSense interface in network 2, I expected that NAT'ing would be re-established, however, it isn't. I have to revert to a previous config to restore the behaviour.

Why, and what am I missing?

viragomann

@swinster
For masquerading the traffic it is necessary that the gateway is stated in the LAN interface settings. I assume, that re-enabling the gateway didn't bring it back there.

Apart from this, you can enable masquerading manually by adding an outbound NAT rule to the LAN. So you can configure it more specifically so that it is only applied to packets from a VPN client.

However, masquerading is generally the worst solution for enabling communication in such circumstances and I'd only recommend it if the VPN is for your own purposes.
The better ones would be to either run the VPN on the upstream router or to set up a transit network between the VPN endpoint and the router and add static routes to both for proper routing the traffic between the local and the remote site.

swinster

@viragomann, I went off snooping in each of the menus to see what I could see when comparing the differences between the different configs, and you are absolutely correct. The Outbound NAT rule of Network 2 (LAN in this case) gets deleted when the gateway is deleted and never recreated.

.

In this case, the VPN is a requirement of the lab environment. I agree that an upstream VPN would be best, but this is impossible with the current infrastructure setup. However, I might delete the NAT rules and add static routes to the VM (as there are only a few) in any case.

I appreciate the response - it answers my question nicely.