/32 route being passed over ipSec when told not to?
-
I'm not sure if this is a bug or "expected behavior"…
I have an IPSec VPN back to my corporate office that has a pair of /16 phase 2 entries - 192.168.0/16 and 10.0/16. My LAN itself is 192.168.42/24, and I don't use that subnet anywhere at corporate.
I'm on a cable modem for WAN. I wanted to check the diagnostics - 192.168.100.1. So I added a static route - 192.168.100.1/32 via the WAN interface.
This isn't working, and I'm not sure why. I can see the route entry on the firewall (route get), but I can't pass traffic to that IP and a traceroute from a client on the LAN is still trying to go via the VPN.
If I drop the tunnel it works, so it is something related to IPSec.
Is this expected, and if so any work-arounds I can try?
-
Static routes have no effect on traffic that matches an IPsec phase 2 definition (SPD). SPD entries in IPsec trump all.
There won't be a way to make that work as you expect, not unless you can get more specific IPsec tunnel networks that wouldn't cover 192.168.100.1
-
Thank you Jim, I appreciate the reply.
The remote side is a Palo Alto firewall which is capable of both SPD-based ("policy-based") as well as so-called "route-based" VPNs. I'm guessing there is no way to do a route-based VPN with pfSense?
I have the broad VPN tunnel in place because I was trying to avoid adding an SPD for every remote subnet at corporate - these are all MPLS sites on /24s that are sent back to the corporate Palo Alto via BGP. Rather than me manually having to maintain the tunnel and add SPDs each time we add a remote site (which is regularly as the business keeps growing), I just used /16s in the tunnel with the assumption that it would obey static routes and more specific routes would take precedence over the tunnel (like basically every other router/firewall I've worked with).
It is very handy for me to be able to poke the remote MPLS sites across the tunnel so I can access things from home without an additional stop between (RDP / SSH to something at the office first).
If I could do a route-based tunnel, I could then also carry a routing protocol (either OSPF or BGP) and get the correct set of routes directly from the Palo Alto instead.
If pf can't handle this, then I guess I'll have to consider a secondary router just for the VPN traffic.
