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

    RESOLVED [2.4.0.r.20170929.0700] Gateway groups priority changes

    Scheduled Pinned Locked Moved 2.4 Development Snapshots
    7 Posts 4 Posters 1.2k 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.
    • D
      drzoidberg33
      last edited by

      I've got a gateway group set as my main gateway and changing the priority of connections doesn't seem to be working currently, after swapping priority 1 to a different connection it continues to route through the old one.

      Can somebody see if they can reproduce this?

      What my config looks like:

      1 Reply Last reply Reply Quote 0
      • luckman212L
        luckman212 LAYER 8
        last edited by

        Your screenshots are not very helpful but I'll offer some general advice. Once states are established via a particular interface/gateway they will persist, even after mucking around with gateway priorities/rules. The length of time will vary depending on protocol and how each application behaves (does it use keep-alives, how often does it transmit data, etc). You can play with overriding these timeouts individually on the System>Advanced>Firewall page, or just change your overall optimization from Normal to Aggressive and see how that works for you. Another thing you can do (somewhat disruptive on a busy network) is to just kill all states after making policy routing changes (Diagnostics>States>Reset).

        1 Reply Last reply Reply Quote 0
        • D
          drzoidberg33
          last edited by

          @luckman212:

          Your screenshots are not very helpful but I'll offer some general advice. Once states are established via a particular interface/gateway they will persist, even after mucking around with gateway priorities/rules. The length of time will vary depending on protocol and how each application behaves (does it use keep-alives, how often does it transmit data, etc). You can play with overriding these timeouts individually on the System>Advanced>Firewall page, or just change your overall optimization from Normal to Aggressive and see how that works for you. Another thing you can do (somewhat disruptive on a busy network) is to just kill all states after making policy routing changes (Diagnostics>States>Reset).

          Thanks for the response, I actually did try resetting the states before posting the OP - it doesn't help.

          I'm pretty confident this always used to work previously as I've made these kinds of changes quite often in the past.

          1 Reply Last reply Reply Quote 0
          • C
            chrcoluk
            last edited by

            I have found that connections from the pfsense unit itself, ignore gateway groups, they always use the "default" gateway.

            But it works fine for any devices behind pfsense it routes traffic for.

            I never got round to submitting a report for this yet.

            I never thought of wiping the session data following a gateway change tho as luke suggested, so it may well be that does the trick for the scenario I had.

            pfSense CE 2.7.2

            1 Reply Last reply Reply Quote 0
            • K
              kpa
              last edited by

              @chrcoluk:

              I have found that connections from the pfsense unit itself, ignore gateway groups, they always use the "default" gateway.

              But it works fine for any devices behind pfsense it routes traffic for.

              I never got round to submitting a report for this yet.

              I never thought of wiping the session data following a gateway change tho as luke suggested, so it may well be that does the trick for the scenario I had.

              This should be common knowledge and somewhere in the wiki, PF on FreeBSD can not redirect locally originating connections because the routing decision has already been made at the time the packets hit the packet filter in the outbound queue and the decision can't be changed.

              1 Reply Last reply Reply Quote 0
              • C
                chrcoluk
                last edited by

                thanks for that information kpa, I agree it would be handy to have it in the wiki.

                The main issue is if you are running the dns queries from pfsense as they originate from pfsense, then it can lead to a dns outage when the gateway changes away from the default.

                I see it is mentioned in the wiki, thanks for pointing that out.

                quoting from the wiki, this should solve the issue I had.

                DNS Considerations
                At least one DNS server should be reachable on each WAN. This can be accomplished by editing the DNS servers under System > General and picking a gateway for each DNS server. Make sure that the DNS server chosen for a given WAN will work there (i.e. it's public or from that ISP). The system's DNS forwarder will query all DNS servers simultaneously, so it should not be affected by a WAN failure.

                pfSense CE 2.7.2

                1 Reply Last reply Reply Quote 0
                • D
                  drzoidberg33
                  last edited by

                  I recently moved over to a new pfsense appliance and running the 2.4.0 final release - started off with a completely fresh install and reconfigured everything again.

                  This seems to have fixed my problem as now changing the priority of my connections works perfectly again.

                  It may have been an issue with my old configuration but I'm really not sure but glad it's working again.

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