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

    OpenVPN Disconnects every 5-10 minutes

    Scheduled Pinned Locked Moved OpenVPN
    17 Posts 5 Posters 14.6k 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.
    • C
      CM350
      last edited by

      I checked it again today and found this:
      Jul 30 09:30:58 php-fpm[77172]: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WANGW.

      I guess it started here, but don't know what it means?

      1 Reply Last reply Reply Quote 0
      • ?
        Guest
        last edited by

        Jul 30 09:30:58    php-fpm[77172]: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WANGW.
        

        I think that this VPN endpoints got a new IP address by or from their ISPs!
        They have dynamic IPs and no static (fixed) ones or a DynDNS account!  :-\

        I guess it started here, but don't know what it means?

        For setting up VPNs you should be sure that both endpoints of a VPN connection are
        sorted with static IP addresses or DynDNS accounts. If this will be so called road worrier
        set ups or the VPN endpoints will be mobile clients this might be not worse and is running
        smooth but if the VPN endpoints are also pfSense firewalls or VPN Servers this will be then
        a problem.  :o

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

          @BlueKobold:

          Jul 30 09:30:58    php-fpm[77172]: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WANGW.
          

          I think that this VPN endpoints got a new IP address by or from their ISPs!
          They have dynamic IPs and no static (fixed) ones or a DynDNS account!  :-\

          I guess it started here, but don't know what it means?

          For setting up VPNs you should be sure that both endpoints of a VPN connection are
          sorted with static IP addresses or DynDNS accounts. If this will be so called road worrier
          set ups or the VPN endpoints will be mobile clients this might be not worse and is running
          smooth but if the VPN endpoints are also pfSense firewalls or VPN Servers this will be then
          a problem.  :o

          The pfsense (OpenVPN Server) is connected to a modem which has a static WAN IP.

          The clients are indeed laptops/desktops with the OpenVPN application with a dynamic ip. But I can't imagine they change ip every 5 minutes :).

          Yesterday I got sick of it and rebooted the pfsense. After this the VPNclients stayed connected for over an hour (maybe 2). But now it's back to reconnecting like every 5 minutes :(.

          1 Reply Last reply Reply Quote 0
          • ?
            Guest
            last edited by

            But now it's back to reconnecting like every 5 minutes

            You can have a closer look to the OpenVPN settings and search the lease time for the
            given internal IP, after connecting to the OpenVPN server. But not on the client side.

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

              you mean the vpn ip? I have no idea how I should do that?

              here is my server.conf file

              dev ovpns1
              verb 3
              dev-type tun
              dev-node /dev/tun1
              writepid /var/run/openvpn_server1.pid
              #user nobody
              #group nobody
              script-security 3
              daemon
              keepalive 10 60
              ping-timer-rem
              persist-tun
              persist-key
              proto udp
              cipher AES-256-CBC
              auth SHA1
              up /usr/local/sbin/ovpn-linkup
              down /usr/local/sbin/ovpn-linkdown
              client-connect /usr/local/sbin/openvpn.attributes.sh
              client-disconnect /usr/local/sbin/openvpn.attributes.sh
              local 192.168.200.2
              tls-server
              server 10.221.14.0 255.255.255.0
              client-config-dir /var/etc/openvpn-csc
              username-as-common-name
              auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify user 'Local Database' true server1" via-env
              tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'CustomerSRVCA' 1 "
              lport 1194
              management /var/etc/openvpn/server1.sock unix
              push "route 10.220.14.0 255.255.255.0"
              push "dhcp-option DOMAIN local.customer.be"
              push "dhcp-option DNS 10.220.14.82"
              push "register-dns"
              ca /var/etc/openvpn/server1.ca
              cert /var/etc/openvpn/server1.cert
              key /var/etc/openvpn/server1.key
              dh /etc/dh-parameters.2048
              tls-auth /var/etc/openvpn/server1.tls-auth 0
              comp-lzo no
              persist-remote-ip
              float
              topology subnet

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

                Okay, did some more testing.

                Created a new OpenVPN server, changed it to TCP port 1195.

                Looks like a breakthrough, now it is connected for almost 3 hours without a disconnect.

                It doesn't make sense though…

                I'll keep you posted

                B 1 Reply Last reply Reply Quote 0
                • C
                  CM350
                  last edited by

                  After hours of testing it looks solved.

                  We are slowly going to update the clients their vpn files to the new port.

                  Can someone tell me this is even possible? Is this solution even recommended?

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

                    Well using a port other than the default 1194 is definitely possible and if it solves your problem, I'd say it's advisable…

                    I often use ports other than 1194 for OpenVPN if only to avoid conflicts/blocking/port spying/etc.

                    Just a guess on my part but your scenario could easily involve ISP "managing" OpenVPN traffic or possibly some DOS/malware/spying trying out your OpenVPN port.

                    -jfp

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

                      @divsys:

                      Well using a port other than the default 1194 is definitely possible and if it solves your problem, I'd say it's advisable…

                      I often use ports other than 1194 for OpenVPN if only to avoid conflicts/blocking/port spying/etc.

                      Just a guess on my part but your scenario could easily involve ISP "managing" OpenVPN traffic or possibly some DOS/malware/spying trying out your OpenVPN port.

                      A possibility yes. But not sure.

                      I've putted the 2 mac clients on another server, maybe it's them (don't have a lot of experience with MAC clients)

                      But it still works like a train, so client is happy and we are happy ;-) !

                      Thanks all!

                      1 Reply Last reply Reply Quote 0
                      • B
                        billsecond @CM350
                        last edited by

                        @CM350 Changing from UDP to TCP also worked for me. Same port is fine. But I think the ISP may have been have been having issues with UDP.

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