pfSense port forward to a NAT:ed IP-address located on the other side of a ipsec tunnel

This is kind of a special scenario but actually occured for me. A port on the pfSense WAN should be NAT:ed to an IP-address located on a remote subnet via an ipsec tunnel. The problem here was the router on the other end of the tunnel did not route all it’s outgoing traffic over the tunnel. Only a few subnets behind the pfSense went through the tunnel. All other traffic was using the routers normal Internet connection.

In the image above, a port (123 in the example code below) on the pfSense ( should be NAT:ed and port forwarded to The result was the NAT:ed port forwarded packets reached the intended host ( but replies probably went straight back on the internet, not going back through the tunnel.

I solved this by setting up a simple proxy on a server using iptables located on a machine in one of the subnets at the pfSense site which was reachable from through the tunnel. See next image.

The proxy was made using iptables in a Ubuntu machine on Both the proxy server on and the host could reach each other over the ipsec tunnel.

In pfSense I changed the NAT / port forward of port 123 from to (and deleted the existing states in pfsense from my previous tries, until I did that, this didn’t work).

The proxy server using IP-tables was set up like this (guide found here):

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i ens160 -p udp --dport 123 -j DNAT --to
sudo iptables -t nat -A POSTROUTING -o ens160 -p udp --dport 123 -j SNAT --to-source
sudo iptables -t nat -A POSTROUTING -p udp --sport 123 -j SNAT --to-source

You will probably want to make sysctl ip_forward and iptables statements persistent over reboots.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published.

nine − 6 =