Packets not routed across functioning IPSec tunnel
-
I have a pfSense 1.2 Embedded device that is using two WAN connections at a small office. I have an IPSec tunnel up from it to a primary office via one of the WAN connections. The tunnel is up and running from the logs on both ends.
When a host on the LAN behind the firewall attempts to ping a host in the primary office subnet, the packet is NAT'ed and sent out one or the other of the two WAN interfaces rather than being sent across the tunnel. I've tried setting up a static route, I've tried setting up advanced NAT and disabling NAT on packets destined for the primary office subnet, and I've tried defining a LAN routing rule that pushes packets over the WAN interface that operates the IPSec tunnel…and I've probably tried a few other things. Nothing I've tried is getting this to work correctly.
When I look at the routing tables on the pfSense device, there is no route defined for the remote subnet. Is that normal? The tunnel is up, so I would think there would be a route defined in it's table somewhere.
Any hints as to how to diagnose this?
-
This is further evidenced by the state table:
icmp 192.168.201.6:512 -> 70.57.227.17:41639 -> 192.168.200.5 0:0Why is traffic not entering the tunnel? From the remote end, I can ping the LAN IP of the pfSense box, but I can't ping any host behind the pfSense box.
-
I think I figured this one out on my own…
I had to change my setup to advanced outbound NAT, create two NAT rules (one for each WAN interface), and make sure that the remote subnet was excluded from those rules. There is still no route to the remote subnet that displays in the web interface, but maybe that's normal. I'm just used to seeing one having come from a Linux/OpenSwan world.
So, judging from what I had to do, I'm assuming the NAT portion of the packet processing happens prior to the routing? It seems like you should figure out where the packet is headed before you figure out if it needs to be NAT'ed or not. ???