Strange behaviour with an IPSec tunnel (site-to-site) and Outbound NAT

TomS

Hi there,

I'm facing a strange phenomenon and do not currently have any clue how to get further there.
Maybe one of you guys can help me here.

Please let me describe my setup first.
There are two networks: mine and the network of another company.
I would like to access one (or a few) devices in the other company's network with each of my devices but I would like to hide my internal networking structure from them.

My network consists of many devices with IP addresses in the range 10.0.0.0/16.
The network is connected to the internet using a router which must not build the VPNs.
I added a pfSense (192.168.30.10) to the router's DMZ (192.168.30.0/24) which should take care of the IPSec stuff.

The router has several connections:

one internet connection (some fixed IPv4 address)
one connection (10.0.0.1) to the internal LAN (10.0.0.0/16)
one connection to the DMZ (as shown above)

The pfSense is configured to make Outbound NAT so that all the packets coming from 10.0.0.0/16 should have their source address rewritten to 192.168.30.20. (This should make sure the external company does not see anything from my internal network structure.)

The pfSense creates an IPSec tunnel to another pfSense in the other company's LAN. Let's say it has the IP address 192.168.20.1. The remote network be 192.168.20.0/24.
The target device I would like to get access to is 192.168.20.2.

An example device PC1 (10.0.0.10) in my internal network would now like to contact the target 192.168.20.2.

What works up to now:

the tunnel is up
the packets arrive at 192.168.20.2
they seem to come from 192.168.3.20 (so the Outbound NAT seems to work fine, too)
ping 192.168.20.2 works from 192.168.20.1
ping 192.168.20.2 works from 192.168.30.10
ping 192.168.20.2 works from 192.168.30.1

What does not work:

ping 192.168.20.1 from 10.0.0.1 (just the other interface of the Internet router)
ping 192.168.20.1 from 10.0.0.10

In the last test (ping 192.168.20.1 from 10.0.0.10) I can see the packets arrive on 192.168.20.2.
Then they are sent back to the source address (which is NATted) and the packets get back through the tunnel until they arrive at my local pfSense (192.168.30.10) and are not sent further anymore.
It seems as if the pfSense "forgot" which NAT translation it made some milliseconds ago and now cannot match the packets to any entry in the NAT table.

Does anyone have a clue what might be wrong here?
(Btw., the same also happens when using TCP packets. A "telnet 192.168.20.2 80" produces the same results...)

I know that it might be confusing what I just now wrote, but maybe the attached picture can help better understand my scenario...

Best regards,
Thomas