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

    OpenVPN over Gateway group doesn't fail back

    Scheduled Pinned Locked Moved OpenVPN
    6 Posts 2 Posters 931 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.
    • R
      robertko
      last edited by

      Hello,

      I am having the following issue with an OpenVPN client. I am running the lastest version of pfsense: 2.4.4-RELEASE-p3

      I have a multi-WAN setup (WAN + 4G) and a gateway group FAILOVER_WAN configured as follows:

      WAN - Tier 1 - Monitor IP: the public IP used as gateway for the connection
      WAN_PPP - Tier 2 - Monitor IP: 8.8.4.4
      Trigger - Packet loss or high latency (not relevant to the problem)

      Outbound NAT disabled since I only need the routes received from the server.

      For testing purposes, all interfaces have Permit on any protocol, any source, any destination in Firewall.

      OpenVPN client using the FAILOVER_WAN as a source interface, connected to an OpenVPN server (not relevant to the issue, either).

      If I disconnect the WAN, the gateway goes down and the OpenVPN service restarts and uses the 4G connection (Tier 2). All good so far.

      The issue comes when I reconnect the WAN, the gateway status changes to UP, but the OpenVPN connection stays up over the 4G connection. A simple service restart solves the issue and OpenVPN client connects via the Tier 1 GW.

      Any suggestion on how to make the OpenVPN client fail back to Tier 1 would be appreciated.

      I have tried (seen on other discussions on this forum):
      Use sticky connections - enabled/disabled
      Flush all states when a gateway goes down - enabled/disabled
      Default gateway IPv4 - Automatic/None/WAN_GW/WAN_PPP_GW
      Added openvpn in Service Watchdog

      The only workaround I can think of is adding a cron script to restart the service every hour or so, but it's not ellegant at all.

      Thank you!

      1 Reply Last reply Reply Quote 0
      • R
        renat_kaa
        last edited by renat_kaa

        This post is deleted!
        1 Reply Last reply Reply Quote 0
        • R
          robertko
          last edited by

          Thanks for the fast reply.
          It is 100% set as such, since otherwise it wouldn't fail Tier1->Tier2
          The issue is that OpenVPN doesn't switch back to Tier1 once it is available again (the system detects the GW back up, but I guess openvpn process needs to be restarted for it to reconnect using the preffered interface.)

          1 Reply Last reply Reply Quote 0
          • R
            renat_kaa
            last edited by renat_kaa

            I just found this client settings item in your post. (And deleted my answer)
            It is so strange, I use completely the same scenario (ex. trigger) and my OVPN client reconnect back after main GW became available.

            1 Reply Last reply Reply Quote 0
            • R
              robertko
              last edited by

              UPDATE: might have found the issue.

              Tier 1 WAN interface was set up to receive IP via DHCP. I have changed this to static IP/SM/GW and now failover works great in both ways :) . Don't know what the underlying issue is. To be fair, the DHCP server I was using was kind of slow. It would lease the IP after >30 sec, I will do some more digging.

              R 1 Reply Last reply Reply Quote 0
              • R
                renat_kaa @robertko
                last edited by renat_kaa

                @robertko huh! I'm not sure that dhcp mode is the reason itself (my pf wan interfaces based on dhcp both) But slow dhcp lease process could affect restoring process. It is great that you solved it! Congrats!)

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