PfSense woes with new tunnel – packets going out WAN instead of through the tun

[breakaway]

Hi All,

I've got two routers at two sites with a bunch of IPSEC tunnels – a bunch of 172.16.0.0/16 (Local Site) and 172.17.0.0/16 (Remote Site) subnets. These IPSEC tunnels on the work fine between the local and remote sites. I am now required to add a new tunnel, this time with a different subnet.

The local subnet is 192.168.2.0/24, the remote subnet (which I added and configured at the remote pfSense) is 192.168.3.0/24
So I duplicated the PHASE 2 config and put all the settings in. The tunnel came up all fine and dandy. But when I try to ping 192.168.2.1 (pfsense at local end) from the remote end, I get destination host unreachable. So I trace it -- which shows that the packets are going out the WAN interface of my pfSense (i.e. my internet connection/default gateway).

This happens at both ends -- both the local site and the remote sites. The packets are being forwarded out the default gateway instead of being sent through the tunnel.

Any ideas on why this may be the case? I've double and triple checked the configs - I'm sure they're correct. Is it something simple that I may have missed?

I've already tried the simple stuff like restarting racoon and restarting pfsense at both ends.

Any help appreciated.

[dew67]

If the phase I settings are good but the phase 2 settings don't match, the second tunnel won't come up. If the tunnel is down I expect the packets would route through the WAN interface.

Under Status –> IPsec does it show the tunnel between 192.168.2.0 and 192.168.3.0 is up? If no, then check the IPSec logs to determine why the tunnel is not coming up.

[breakaway]

Hi,

Yes – the tunnel is definitely coming up (I've got a Green ">" next to the tunnel name) -- but yet the packets are going out WAN.

I'm at a loss as to what this could be!

[Moohouse]

Sorry if these are very basic steps.

You say 192.168.2.1 is the local end pfsense. Is this a virtual IP on a relevant interface? Is the network mask 24 bit, or something else?

I assume 192.168.3.1 is the remote end pfsense. Is this a virtual IP on a relevant interface? Is the network mask 24 bit? Replace 192.168.3.1 with whatever 192.168.3.x IP the remote end pfsense uses, if different.

When the tunnel is up, try ping from the shell on local end pfsense.

ping -c 1 192.168.2.1
ping -c 1 -S 192.168.2.1 192.168.3.1

Same from remote end shell:
ping -c 1 192.168.3.1
ping -c 1 -S 192.168.3.1 192.168.2.1

The responses from ping could be informative. "Communication prohibited by filter" is logical if the packets leave via the WAN interface, and this interface blocks private networks.