Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Policy Routing Behind Separate LAN and IPSEC Routers

    Scheduled Pinned Locked Moved Routing and Multi WAN
    4 Posts 2 Posters 961 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      mannyjacobs73
      last edited by

      Hi,

      I'm trying to setup, what I think should be be easy enough, policy route to a system located at a remote site.  It is connected via 1. an internet site-to-site as well as 2. internal leased line.

      I have an internal pfsense (PF_INTERNAL), which has connectivity to the LANs allowing access to the two paths:

      1. via an ipsec connection configured on a secondary pfsense, connected to internet (PF_INTERNET)

      2. via a local / internal L3 router (LAN_L3)

      (Architecture diagram attached).

      • The default gateway on PF_INTERNAL is set to PF_INTERNET - This should also remain the primary route for the remote IP I am accessing (so via the internet site-to-site).

      • I have added a gateway on PF_INTERNAL interface connected to the LAN containing LAN_L3.

      Essentially what I would like is, if the site-to-site tunnel goes down, for the connection on PF_INTERNAL to change its route to the internal router (LAN_L3).

      I've followed steps to:

      • Add gateway on interface connected to LAN_L3
      • Add gateway groups
      • Added firewall rules to allow my PC LAN out to the remote IP via the gawetway group

      Am I correct in thinking gateway-groups is not the correct method as it doesn't monitor the ipsec tunnel, but rather the IP of the gateway?

      Am I over-complicating things?

      pfsense v2.3.2-RELEASE

      Thanks,
      Policy_Routing_Architecture.jpg
      Policy_Routing_Architecture.jpg_thumb
      gateways_policy.png
      gateways_policy.png_thumb
      gateways_group_policy.png
      gateways_group_policy.png_thumb
      FW_rule_policy.png
      FW_rule_policy.png_thumb

      1 Reply Last reply Reply Quote 0
      • M
        mannyjacobs73
        last edited by

        For anyone coming across this thread later..

        Right, so it seems what I need isn't inherently possible due to the way *BSD handles routing.

        Unless there are some newer *BSD routing updates on this, *BSD is unable to have multiple (static) routes to the same location / ip / subnet.  It looks like the only way to have priority with the routes used is to use a routing protocol / process.

        From the threads I've seen, it looks like I'm not the only one to have been caught out by this ;-).

        1 Reply Last reply Reply Quote 0
        • T
          tim.mcmanus
          last edited by

          I think this should work.  They are two different routes to the same remote network, but the gateways are different.  And, it's not load balancing, it's a failover group.  So if one goes down, the other takes over.

          Have you built this out and tested it?  Im guessing that it would work as you've designed it.

          You are correct that it monitors if the gateway is up or not.  I usually monitor past the gateway to an endpoint on the destination network.

          1 Reply Last reply Reply Quote 0
          • M
            mannyjacobs73
            last edited by

            Hi Tim,

            Yes I did build and test it out.  The main 'issue' I have is that the connectivity and vpn out the device 'pf_internet' from 'pf_internal' is used for other services too.

            If, on the device 'pf_internal' 192.168.166.x interface, I set a gateway of pf_internet (192.168.166.x) but with a monitor of an IP across the tunnel, I believe yes, this would work.  However, if only the tunnel to that remote IP being monitored goes down, I run the risk of causing failover for other services, even when the rest of the connections are up.

            – I hope you understand what I mean?

            My workaround for the moment is to have static routes, specific for the remote IP, disabled on pf_internal.  In the case of failure of ther tunnel, the static routes are simply enabled.

            --- Yes, I know....  Manual intervention like this is not ideal, I'm just not seeing any other way around this scenario.

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.