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

    Mutil Wan routing to wrong/offline interface.

    Scheduled Pinned Locked Moved Routing and Multi WAN
    5 Posts 3 Posters 530 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.
    • K
      kitdavis
      last edited by

      I asked about this in the IPSEC section yesterday but suspect it really belongs here.

      I have a multiwan setup where I have a fast starlink connection for most traffic, and a second slower fixed wireless connection for a number of IPSEC tunnels to various client networks. Hurricane Fiona, knocked out power to that ISP and as a result the slow connection is off-line.

      What I have discovered is that, of course, the IPSEC connection is down so I can not connect to that network using the natted address. However, I also can not connect to anything on the client network using their public IP address. (So for clarification the client has 1 public IP address 142.176.xxx.yyy. I use that as the gateway for the IPSEC connection which then lets me attach to their internal natted network at 192.168.2.xxx. I also connect to a server on their network that allows me to enter invoices and expenses using a FQDN which resolves to the same public address 142.176.xxx.yyy that is used for the gateway)

      I have both connections in a gateway group and have assigned the slow connection to a lower tier so that it will failover to it only if the other member is down. Looking at the gateway status shows that indeed PFSense recognizes the connection as being off-line, however if I look at the routing table, I see entries telling PFSense to route all traffic for that public IP address via the slow (OPT1) connection even though the connection is off-line. If I manually go into the interfaces and disable OPT1 then traffic is routed through the working connection. As soon as I re-enable the OPT1 connection it starts trying to route all traffic for that public IP address through the OPT1 interface again.

      I've searched and looked through the options and can't find anything that needs to be set to resolve this. (And I expect the this is the same behavior that occurs when both interfaces are working i.e. all traffic to that network be it IPSEC or other gets routed through the OPT1 connection which is why my access to the public server is very slow in normal conditions).

      Any ideas about how to fix this issue?

      V S 2 Replies Last reply Reply Quote 0
      • V
        viragomann @kitdavis
        last edited by

        @kitdavis said in Mutil Wan routing to wrong/offline interface.:

        I have both connections in a gateway group and have assigned the slow connection to a lower tier so that it will failover to it only if the other member is down

        Did you specify this gateway group as default gateway in System > Routing > Gateways?

        K 1 Reply Last reply Reply Quote 0
        • K
          kitdavis @viragomann
          last edited by

          @viragomann Yes, the default gateway is set to the group.

          1 Reply Last reply Reply Quote 0
          • S
            SteveITS Galactic Empire @kitdavis
            last edited by

            @kitdavis Are you using policy routing to force the traffic there? (vs failover)

            Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
            When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
            Upvote 👍 helpful posts!

            K 1 Reply Last reply Reply Quote 1
            • K
              kitdavis @SteveITS
              last edited by

              @steveits That fixed the problem - changing the gateway from "Default" to the gateway group resolved my issue. Thanks.

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