1.2.3 RC3 - IPSEC works for clients, pf box unable to ping other end of tunnel
-
I have a fairly simple setup.
Main office has a SonicWALL (10.1.1.254/24)
Satellite office has a newly installed pfSense box (10.5.10.254/24)I set the pfSense box up in place of an old SonicWALL. Everything is working normally. Clients on both networks can communicate without problems.
The strange thing I am seeing is that the pfSense box (10.5.10.254) can't talk to anything in 10.1.1.0/24.
Looking at the routing table on the pfsense box, I don't see anything for 10.1.1.0/24 even though clients are able to access resources in 10.1.1.0/24
This is my first IPSEC VPN setup. Once all the SonicWALLs have been replaced with pfSense boxes, I want to switch back to OpenVPN.
Is this normal for IPSEC? Did I find a bug in 1.2.3-RC3?
-
IPsec doesn't route like other protocols. The magic all happens in the kernel, you'll never see the "routes".
You have two choices to get traffic to move along the tunnel from the pfSense box itself. The first is to add a static route on the LAN interface pointing the remote subnet to the LAN interface IP. That will "trick" traffic into entering the tunnel.
If you're just worried about ping, you can try:
ping -S <pfsense lan="" ip=""><remote ip="" address="">That will source the ping from the LAN IP, which will enter the tunnel as expected.Much of this is covered in the doc wiki
http://doc.pfsense.org/index.php/Why_can%27t_I_query_SNMP%2C_use_syslog%2C_NTP%2C_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN%3F</remote></pfsense> -
Thanks for the pointer–I totally missed that doc on my first trip through the FAQ.
Not being a BSD guy, I couldn't remember the darn ping flag to send traffic through the LAN interface.SonicWALLs suffer from this exact same problem....I wonder what they use as their base OS... ;)
