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

    Site to Site Re-Establish

    OpenVPN
    4
    12
    4.9k
    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
      Stevej
      last edited by

      Hi All,

      We're in the process of migrating the core VPN infrastructure of our network from a Draytek based ipsec network to a redundant (CARP) pfsense with a mix of IPSec and OpenVPN.

      Currently our test platform has 2 OpenVPN clients connected one via TCP/443 and one UDP/1195, these both seem absolutely fine, however i have noticed an odd (and hopefully simple) issue.

      If the internet connection at the client side drops for a period and then comes back the openVPN tunnel does not re-establish. The only way i can get it to do so is to either reboot the client side pfsense or disable and re-enable the client side openvpn profile.

      Is there any way to get the client side to automatically re-establish.

      Thanks in advance.

      Steve

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

        try ticking the
        "Infinitely resolve server" tickbox

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

          i did think of this, but the issue is more client side than server side. There is a risk that the client side connection may go down and we have seen that if it does sometimes the client side stops trying to connect.

          Sorry if im being thick

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

            OpenVPN is preferred in such cases because its reconnection is bullet proof. What's upstream of the box? Only failure like that I've seen is when something upstream won't let it connect (assuming the box running the OpenVPN client is NATed). Like it hangs on to an old NAT state and won't create a new one to send traffic out the correct new IP after a reconnect.

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

              @Stevej:

              We're in the process of migrating the core VPN infrastructure of our network from a Draytek based ipsec network to a redundant (CARP) pfsense with a mix of IPSec and OpenVPN.

              What are the reasons for moving away from IPsec?

              I have often considered it, but -at least in previous years- there was no embedded system hardware capable of acting as both ADSL modem and OpenVPN end-point, so one would have to maintain at least two hardware devices (ADSL modem + router w/ OpenVPN client) at each remote VPN site.

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

                @cmb The upstream of the customer side (supplied by ourselves) varies, it can be ADSL or leased line. What i've noticed is that if the connection on the customer size drops (this could be due to a link failure or such) then when the link re-establihes the VPN doesnt come back up, unless i disable the VPN profile and re-enable it. Is the key the infinetly resolve tick box?

                @dhatz The Draytek we're running in the DC Rack performs ok, but we need scalability and we're starting to see issues as we increase the number of customer VPNS. Hence why we've looked at pfsense as a replacement for our core routing hardware. Those customers still running draytek as CPE we will stick with ipsec, but it makes sense for us to use openvpn where we are deploying pfsense as CPE.

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

                  I see, I was referring to using Draytek as CPE (I agree that using something like pfSense at the DC would be a good idea).

                  However in recent months I've noticed several long-time Draytek users complain about the stability of their latest firmware…

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

                    dont get me wrong i love the draytek kit, but the new 3900 we've had on eval hasnt ben great.

                    We have a nice rack mount pfsense appliance which we partner with a Vigor 120 ADSL modem (if needed) and it seems to work very well.

                    Stability is definately an issue with the draytek kit thee days. We're a VSP and we've seen some odd issues where SIP traffic stops passing over a VPN if it drops and re-establishes, hence why we've looked at different hardware

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

                      Stability is definately an issue with the draytek kit thee days. We're a VSP and we've seen some odd issues where SIP traffic stops passing over a VPN if it drops and re-establishes, hence why we've looked at different hardware

                      What has been your experience wrt stability + features of the latest (summer 2012) firmware of the classic models, particularly 2820/30 and 2710 ?

                      @Stevej:

                      We have a nice rack mount pfsense appliance which we partner with a Vigor 120 ADSL modem (if needed) and it seems to work very well.

                      Indeed such a rack-mount appliance w/ V120 would be a good choice for medium-sized remote site (dozen or more users), but would you also use it for a remote site with only 3-4 users ? …

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

                        Truth be known we have better stability with older firmware on the 2820/30, we're running some Beta Firmware from Draytek to cure the SIP issue i mentioned. We tend to lean towards to 2920 and 2955 as we find them better. I have some 2850 on the ground but have had intermittent throughput issues too.

                        No firmware seems to cure all issues, but thankfully there is usually a firmare to cure the problem we're experiencing at a given time. If that makes sense.

                        We're in the process of having our CPE branded and this will be used on all sites for consistency and to make my support team's life easier :-)

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

                          @Stevej:

                          Truth be known we have better stability with older firmware on the 2820/30, we're running some Beta Firmware from Draytek to cure the SIP issue i mentioned. We tend to lean towards to 2920 and 2955 as we find them better.

                          Afaik 29xx don't include an ADSL modem, so one would have to deal with two devices (or three if one wants a WAN backup xDSL/3G)

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

                            @Stevej:

                            @cmb The upstream of the customer side (supplied by ourselves) varies, it can be ADSL or leased line. What i've noticed is that if the connection on the customer size drops (this could be due to a link failure or such) then when the link re-establihes the VPN doesnt come back up, unless i disable the VPN profile and re-enable it. Is the key the infinetly resolve tick box?

                            No, the completely default settings will reconnect automatically on their own. Would have to see some logs from the OpenVPN client while it's failing to reconnect to have an idea of what might be happening.

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