<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[&#x2F;32 route being passed over ipSec when told not to?]]></title><description><![CDATA[<p dir="auto">I'm not sure if this is a bug or "expected behavior"…</p>
<p dir="auto">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.</p>
<p dir="auto">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.</p>
<p dir="auto">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.</p>
<p dir="auto">If I drop the tunnel it works, so it is something related to IPSec.</p>
<p dir="auto">Is this expected, and if so any work-arounds I can try?</p>
]]></description><link>https://forum.netgate.com/topic/54330/32-route-being-passed-over-ipsec-when-told-not-to</link><generator>RSS for Node</generator><lastBuildDate>Fri, 17 Jul 2026 08:36:31 GMT</lastBuildDate><atom:link href="https://forum.netgate.com/topic/54330.rss" rel="self" type="application/rss+xml"/><pubDate>Tue, 19 Mar 2013 03:48:15 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to &#x2F;32 route being passed over ipSec when told not to? on Tue, 19 Mar 2013 21:48:12 GMT]]></title><description><![CDATA[<p dir="auto">Thank you Jim, I appreciate the reply.</p>
<p dir="auto">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?</p>
<p dir="auto">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).</p>
<p dir="auto">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).</p>
<p dir="auto">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.</p>
<p dir="auto">If pf can't handle this, then I guess I'll have to consider a secondary router just for the VPN traffic.</p>
]]></description><link>https://forum.netgate.com/post/385423</link><guid isPermaLink="true">https://forum.netgate.com/post/385423</guid><dc:creator><![CDATA[ZPrime]]></dc:creator><pubDate>Tue, 19 Mar 2013 21:48:12 GMT</pubDate></item><item><title><![CDATA[Reply to &#x2F;32 route being passed over ipSec when told not to? on Tue, 19 Mar 2013 12:53:24 GMT]]></title><description><![CDATA[<p dir="auto">Static routes have no effect on traffic that matches an IPsec phase 2 definition (SPD). SPD entries in IPsec trump all.</p>
<p dir="auto">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</p>
]]></description><link>https://forum.netgate.com/post/385282</link><guid isPermaLink="true">https://forum.netgate.com/post/385282</guid><dc:creator><![CDATA[jimp]]></dc:creator><pubDate>Tue, 19 Mar 2013 12:53:24 GMT</pubDate></item></channel></rss>