/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 -  So I added a static route - 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?

  • Rebel Alliance Developer Netgate

    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

  • 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.

Log in to reply