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

    Failing back to a VPN connection

    Scheduled Pinned Locked Moved Routing and Multi WAN
    13 Posts 3 Posters 721 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.
    • Bob.DigB
      Bob.Dig LAYER 8 @jrhjr
      last edited by Bob.Dig

      @jrhjr You don't need a gateway group because it is the default behavior of pfSense to use the default gateway if another gateway fails.
      That said, I can't tell you why your not failing back. Maybe it is happening to often with minimal times in between?

      J NogBadTheBadN 3 Replies Last reply Reply Quote 0
      • J
        jrhjr @Bob.Dig
        last edited by

        @bob-dig Hmmm, I'll have to ponder what the setup would look like if there was no gateway group. I originally tried it without groups and never could completely fail OVER - let alone fail back. In that config I was using two LAN firewall rules (and the skip rules when gateway is down setting) to route traffic out a specific gateway - I was not leveraging the default gateway - I'll have to try that I guess.

        In terms of fail back - understand that the VPN connection recovers - it reconnects and the gateway & group status are green again - everything indicates everything is up but clients don't route to the VPN - they fail to fail back to the second tier gateway and remain stuck on the fourth tier. Just this morning they were stuck for like 45mn - until I trivially changed a firewall rule description and applied it.

        As for falling over too often - maybe but it's because I'm testing pfSense now - it won't happen nearly as often or as fast if I replace my Asus routers with pfSense the way I want to.

        Thanks!

        Bob.DigB 1 Reply Last reply Reply Quote 0
        • Bob.DigB
          Bob.Dig LAYER 8 @jrhjr
          last edited by

          @jrhjr said in Failing back to a VPN connection:
          (and the skip rules when gateway is down setting)

          That is not the default but you seem to know and have planed accordingly.

          1 Reply Last reply Reply Quote 0
          • J
            jrhjr @Bob.Dig
            last edited by

            @bob-dig By default my WAN interface's gateway is being selected as the "Automatic" Default Gateway and that results in clients using the WAN (not the VPN) to get out. If I change the Default Gateway in System/Routing/Gateways to NordVPN no clients can communicate out at all. At least not at first (or second) glance. It doesn't seem like there's any sort of blocking firewall rule but I am not having any luck so far.

            Bob.DigB 1 Reply Last reply Reply Quote 0
            • Bob.DigB
              Bob.Dig LAYER 8 @jrhjr
              last edited by Bob.Dig

              @jrhjr I meant if you create a rule to use nord (policy based routing) and that is offline, it would switch to WAN by default.
              Screenshot 2022-11-21 214958.png

              Btw you should in general select WAN as the default gateway, not automatic.

              1 Reply Last reply Reply Quote 0
              • J
                jrhjr
                last edited by

                @bob-dig So this appears to be a bug in 2.6 (introduced in 2.5). There's a good discussion of it at the link below.

                https://redmine.pfsense.org/issues/11570

                Also - I backed up my config and restored it to the latest 2.7 build (pfSense-CE-2.7.0-DEVELOPMENT-amd64-20221121-0600.iso) and it worked like a champ - it fails over and back in less than 30 seconds which is very acceptable. The whole process of testing it took less time than writing this response - sheesh!

                @bob-dig you did help me realize that if you specify a gateway in a FW rule (in my case a VPN) and the gateway goes down - it doesn't mean the rule isn't matched but rather that it just fails to the WAN - which is my desired behavior. I think I sort of was aware of this but I was so bogged down in the failback bug that I never bothered to digest it. It makes the config oh-so-simple which is my preference.

                As for my pfSense journey - I don't know what comes of it. I hate to downgrade to 2.4 - especially on a router/firewall. I might just wait until 2.7 is released which seems like probably it'll be soon - a couple months ... Or I might just run on this development version - something I don't like doing. I know opnSense is an option but that seemed way buggier than pfSense - it had my head spinning. In any case I'm glad to have figured this out - I've been pulling the few remaining hairs out of my head for over a week now on this issue.

                Incidentally the absolute killer feature I have to have that makes me want pfSense is the ability to use FQDN names in Firewall aliases ... That pfSense periodically resolves the names to IPs it then uses in FW rules is killer. This is helpful for sites like Spectrum TV which don't like VPNs ... It's relatively easy to determine the DNS names they're hitting - but an absolute nightmare to keep up with the IPs behind the names. This feature makes it a dream!

                Bob.DigB 1 Reply Last reply Reply Quote 0
                • Bob.DigB
                  Bob.Dig LAYER 8 @jrhjr
                  last edited by

                  @jrhjr You can get the plus version of pfSense for free for home use. Just "buy" it on their website, it should be bug free.

                  J 2 Replies Last reply Reply Quote 1
                  • J
                    jrhjr @Bob.Dig
                    last edited by

                    @bob-dig I didn't know this, thank you. I'll probably go down this path then. Thanks again!

                    1 Reply Last reply Reply Quote 0
                    • NogBadTheBadN
                      NogBadTheBad @Bob.Dig
                      last edited by

                      @bob-dig I'd still use gateway groups and have 3 NordVPN connections set up incase there is an issue with any one the VPN endpoints.

                      Andy

                      1 x Netgate SG-4860 - 3 x Linksys LGS308P - 1 x Aruba InstantOn AP22

                      Bob.DigB 1 Reply Last reply Reply Quote 0
                      • Bob.DigB
                        Bob.Dig LAYER 8 @NogBadTheBad
                        last edited by Bob.Dig

                        @nogbadthebad said in Failing back to a VPN connection:

                        I'd still use gateway groups and have 3 NordVPN connections set up incase there is an issue with any one the VPN endpoints.

                        Same here with my VPN-Provider.

                        Screenshot 2022-11-22 194537.png

                        It is almost unusable without it, sadly.

                        1 Reply Last reply Reply Quote 1
                        • J
                          jrhjr @Bob.Dig
                          last edited by

                          @bob-dig Welp - unfortunately pfSense Plus 22.05 does not include the fix - it looks like it might not include it until 23.05 based on the comments. :( Oh well, the development versions do have the fix and upgrading to pfPlus helped me understand that using the development versions could be easier than I thought - just upgrade via the GUI.

                          Bob.DigB 1 Reply Last reply Reply Quote 0
                          • Bob.DigB
                            Bob.Dig LAYER 8 @jrhjr
                            last edited by Bob.Dig

                            @jrhjr No problem here, also I don't unplug my WAN cable...
                            Anyway, one other thing you can try is not failing back to WAN but to another VPN-Client. As far as I have understand you, it is not WAN failing but a VPN-Client. We, in this thread, do use Gateway Groups for VPN-Clients and it is working for us.
                            And btw. not every redmine ticket/issue is affecting everyone.

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