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.

SIP-client behind NAT disconnects incoming external call after 8-10 seconds

Scenario: a SIP server running Elastix (Asterisk and FreePBX) with SIP-clients behind NAT. Outgoing calls from the clients (which where CounterPath Xten and Siemens Gigaset C530ip, i.e. completely different brands) works well, but incoming calls are disconnected after 8-10 seconds.

Googleing the problem suggests the problem is caused by a SIP REINVITE on the client side, which can’t happen because of NAT. During testing, I discovered that calls between SIP-phones connected to the same SIP PBX worked fine, even between different locations. Only calls that originated externally would be interrupted.

This made me focus on the trunks instead and I found out that the problem indeed was a REINVITE but it occured on the trunk side.

The solution was to add the following lines to the PEER DETAILS and USER DETAILS on the trunk configuration in the SIP server: