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

    How to prevent restarting OpenVPN tunnels/ifaces if gateway monitor goes down

    Scheduled Pinned Locked Moved OpenVPN
    14 Posts 4 Posters 3.0k 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.
    • S
      Soyokaze
      last edited by

      @Derelict:

      If you bind the OpenVPN server to localhost instead and port forward CARP:1194 to 127.0.0.1:1194 it might help.

      I use this configuration (binding OpenVPN servers to localhost) daily. It works.

      Need full pfSense in a cloud? PM for details!

      1 Reply Last reply Reply Quote 0
      • S
        snow
        last edited by

        @Soyokaze:

        @Derelict:

        If you bind the OpenVPN server to localhost instead and port forward CARP:1194 to 127.0.0.1:1194 it might help.

        I use this configuration (binding OpenVPN servers to localhost) daily. It works.

        Are you using this configuration because of the same issue (Tunnel restart when the appropriate interface will be omitted and added back again to multi wan group as in my case)?

        If not, do you have any other pros/cons for this config?

        1 Reply Last reply Reply Quote 0
        • DerelictD
          Derelict LAYER 8 Netgate
          last edited by

          I use that configuration in HA clusters so OpenVPN server does not stop/start based on who is the master.

          The servers just stay running on both and whichever one is master receives the traffic.

          Chattanooga, Tennessee, USA
          A comprehensive network diagram is worth 10,000 words and 15 conference calls.
          DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
          Do Not Chat For Help! NO_WAN_EGRESS(TM)

          1 Reply Last reply Reply Quote 0
          • S
            Soyokaze
            last edited by

            @snow:

            @Soyokaze:

            @Derelict:

            If you bind the OpenVPN server to localhost instead and port forward CARP:1194 to 127.0.0.1:1194 it might help.

            I use this configuration (binding OpenVPN servers to localhost) daily. It works.

            Are you using this configuration because of the same issue (Tunnel restart when the appropriate interface will be omitted and added back again to multi wan group as in my case)?

            If not, do you have any other pros/cons for this config?

            Somewhat.
            It is easier to toss around endpoint in case of multiple IPs/multihomed setups (and for RR/FO multihomed endpoint this is a must).
            It is easier to control outbound connections (for 'client' VPN) using floating rules.
            …
            and I use it like that for so long I don't even remember all nuances.
            But less daemon restarts is one of them.

            Need full pfSense in a cloud? PM for details!

            1 Reply Last reply Reply Quote 0
            • S
              snow
              last edited by

              Thank you guys.

              I'm now using the OpenVPN server bound to localhost with appropriate port forwarding from carp to localhost.
              That's working perfectly.

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

                Hello !

                I use the same kind of solution for OpenVPN servers (binding the OpenVPN server to localhost when using CARP).

                But I still have the problem for the OpenVPN site to site clients. Indeed these clients are bound to a Gateway group and when the backup gateway (which doesn't route any traffic when active gateway is UP) goes down, the OpenVPN clients restart and for example SSH connexions through VPN get broken.

                Did someone find a good solution for this ?

                Regards,

                1 Reply Last reply Reply Quote 0
                • DerelictD
                  Derelict LAYER 8 Netgate
                  last edited by

                  No. Those states are going to break. They will need to reconnect.

                  Chattanooga, Tennessee, USA
                  A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                  DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                  Do Not Chat For Help! NO_WAN_EGRESS(TM)

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

                    OK that's crystal clear, thanks !

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

                      Actually, it looks like SSH don't break anymore when unsetting ""State Killing on Gateway Failure / Flush all states when a gateway goes down".

                      But I have to check if there are negative side effects, since this option was set in order to improve WAN failover with different OpenVPN clients bound to different gateway groups.

                      1 Reply Last reply Reply Quote 0
                      • DerelictD
                        Derelict LAYER 8 Netgate
                        last edited by

                        If it doesn't it is because it actually reconnects.

                        I have never seen ssh do that.

                        Chattanooga, Tennessee, USA
                        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                        Do Not Chat For Help! NO_WAN_EGRESS(TM)

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