1:1 NAT over OpenVPN with gateway change -> not working

  • Hi,
    I have two pfsense boxes running that are connected with an OpenVPN tunnel ( pfSense-1 has a /24 of official IP adresses and I'd like to make some lan servers behind pfSene-2 available via public ip adresses.
    I thought that I might be able to do it like this:

    • have a 1:1 NAT entry on pfsense-1 pointing to the lan adress of the server in the lan of pfsense-2
    • on pfsense-2 create a firewall rule with gateway changing for the server ip adress on the lan interface with the gateway pointing to the openvpn tunnel ip of pfsense-1
    • perhaps tune the outgoing nat rules on pfsense-1

    For this I had to assign an interface on pfsense-2 to the OpenVPN client instance in order to have a gateway to select for the firewall rule.

    Now to the problems I have…

    This above mentioned construct does not work as expected. The ip packets are nated correctly to the server ip adress on pfsense-1 and are transmitted via the OpenVPN tunnel to the server. The server responds and the response packets are received by pfsense-2.
    But pfsense-2 does not put the packets back onto the OpenVPN tunnel and instead puts them unnated to the wan-1 interface. And that I don't really understand.

    Here the ip addresses of the setup:

    • pfsense-1:

    • WAN IP:

    • 1:1 NAT IP:

    • LAN IP:

    • OpenVPN IP:

    • pfsense-2:

    • WAN IP-1:

    • WAN IP-2:

    • 1:1 NAT IP:

    • LAN IP:

    • OpenVPN IP:

    • server:

    • LAN IP:

    As far as I know until now it has something todo with the state tracking. As packets generated from the lan server are sent out correctly. But still after trying a lot of different rules I cannot get answer packets to leave via the openvpn interface. The answer packets leave pfsense-2 via pppoe2 (wan-1) which is the default gw without being nated…

  • Bump. Has no one an idea what is going on here?

  • Hi, I have had your example working with an IPsec tunnel and with a GRE tunnel.
    I too had an issue with state tracking, although not quite in the way you described.

    For me upgrading both ends to  2.2-RC (i386) built on Fri Jan 09 09:52:49 CST 2015 resolved my issue, perhaps it will help you too ?

Log in to reply