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

    Strange logs -> losing OpenVPN connection every 20 - 120 seconds

    Scheduled Pinned Locked Moved 2.1.1 Snapshot Feedback and Problems - RETIRED
    18 Posts 6 Posters 13.2k 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.
    • E
      eri--
      last edited by

      So find a machine to ping on the other side then :)

      Though disabling monitoring should have avoided this unless you have other problems in the tunnel.

      1 Reply Last reply Reply Quote 0
      • O
        Oliver
        last edited by

        I reverted back to

        2.1-RELEASE (amd64)
        built on Wed Sep 11 18:17:48 EDT 2013

        and this oddity is gone for good. Guess I'm going to stick to that for a some more time!

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

          The system log isn't all that telling on its own, what does the OpenVPN log show?

          1 Reply Last reply Reply Quote 0
          • D
            doktornotor Banned
            last edited by

            Still happening even with latest snapshot. The WAN IP is in fact static, it never changes. These newwanip detections are a pile of BS.

            
            rc.newwanip: pfSense package system has detected an ip change
            
            

            Same thing happens with IPsec:

            
            php: rc.newipsecdns: IPSEC: One or more IPsec tunnel endpoints has changed its IP. Refreshing.
            
            

            As for OpenVPN log, nothing useful there either:

            
            Mar 6 12:25:37	openvpn[47673]: /sbin/ifconfig ovpns1 10.0.8.1 10.0.8.1 mtu 1500 netmask 255.255.255.0 up
            Mar 6 12:25:37	openvpn[47673]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=1
            Mar 6 12:25:37	openvpn[47673]: TUN/TAP device /dev/tun1 opened
            Mar 6 12:25:37	openvpn[47673]: TUN/TAP device ovpns1 exists previously, keep at program end
            Mar 6 12:25:37	openvpn[47673]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file
            Mar 6 12:25:36	openvpn[47673]: Initializing OpenSSL support for engine 'cryptodev'
            Mar 6 12:25:36	openvpn[47673]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
            Mar 6 12:25:36	openvpn[47673]: OpenVPN 2.3.2 i386-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [eurephia] [MH] [IPv6] built on Jan 23 2014
            Mar 6 12:25:36	openvpn[97470]: SIGTERM[hard,] received, process exiting
            Mar 6 12:25:36	openvpn[97470]: /usr/local/sbin/ovpn-linkdown ovpns1 1500 1558 10.0.8.1 255.255.255.0 init
            Mar 6 12:25:36	openvpn[97470]: event_wait : Interrupted system call (code=4)
            
            
            1 Reply Last reply Reply Quote 0
            • E
              eri--
              last edited by

              Every time a connection/reconnection occurs you see the logs for newwanip.

              Do you have anything similar to below in your logs?

              
              log_error("DEVD Ethernet attached event for {$iface}");
              log_error("HOTPLUG: Configuring interface {$iface}");
              
              

              Give this a try again as well:

              
              diff --git a/etc/rc.linkup b/etc/rc.linkup
              index 1994336..43607b1 100755
              --- a/etc/rc.linkup
              +++ b/etc/rc.linkup
              @@ -100,7 +100,7 @@ if (!file_exists("{$g['varrun_path']}/booting") && empty($g['booting'])) {
                              break;
                      }
                      $interface = convert_real_interface_to_friendly_interface_name($argv[2]);
              -       if (!empty($interface))
              +       if (!empty($interface) && substr($argv[2], 0, 4) != "ovpn")
                              handle_argument_group($interface, $action);
               }
              
              
              1 Reply Last reply Reply Quote 0
              • D
                doktornotor Banned
                last edited by

                No, no hotplug/devd events in the log. As for the patch, well yes I can try that (should obviously stop triggering the OVPN restart), but it's not really like it'd happen for any good reason at all. It seems like it just decides the WAN IP "changed" a couple of times a day, randomly.

                1 Reply Last reply Reply Quote 0
                • E
                  eri--
                  last edited by

                  Well if your Dyndns or any other monitoring for hostname changes triggers the event you have to find which is doing that.
                  Also find out why its triggering the event.

                  To me from the logs it looked like devd was doing that since it was not clear on dyndns/hostnames on vpns being used from the logs.

                  Maybe the config.xml can help to validate the options here.

                  1 Reply Last reply Reply Quote 0
                  • D
                    doktornotor Banned
                    last edited by

                    @ermal:

                    Well if your Dyndns or any other monitoring for hostname changes triggers the event you have to find which is doing that.
                    Also find out why its triggering the event.

                    To me from the logs it looked like devd was doing that since it was not clear on dyndns/hostnames on vpns being used from the logs.

                    Now that you mention dyndns…

                    
                    Mar 7 08:22:53	check_reload_status: Restarting OpenVPN tunnels/interfaces
                    Mar 7 08:22:53	check_reload_status: updating dyndns HEIPV6_TUNNELV6
                    Mar 7 08:22:53	check_reload_status: Restarting OpenVPN tunnels/interfaces
                    Mar 7 08:22:53	check_reload_status: updating dyndns WAN_DHCP
                    Mar 7 08:22:52	check_reload_status: Reloading filter
                    Mar 7 08:22:52	check_reload_status: Restarting OpenVPN tunnels/interfaces
                    Mar 7 08:22:52	check_reload_status: Restarting ipsec tunnels
                    Mar 7 08:22:52	check_reload_status: updating dyndns WAN_DHCP
                    Mar 7 08:22:52	check_reload_status: Reloading filter
                    Mar 7 08:22:52	check_reload_status: Restarting OpenVPN tunnels/interfaces
                    Mar 7 08:22:52	check_reload_status: Restarting ipsec tunnels
                    Mar 7 08:22:52	check_reload_status: updating dyndns HEIPV6_TUNNELV6
                    
                    

                    Obviously, this again makes no sense since there is nothing dynamic - except for the gateway being statically "dynamic". The GW IP never changes, it is configured as static IP on the GIF interface. What's "updating" there? Again, the WAN_DHCP is a static DHCP lease, never changes.

                    1 Reply Last reply Reply Quote 0
                    • E
                      eri--
                      last edited by

                      Can you check the relevant files for this to see why it triggers?

                      1 Reply Last reply Reply Quote 0
                      • D
                        doktornotor Banned
                        last edited by

                        @ermal:

                        Can you check the relevant files for this to see why it triggers?

                        Maybe… if only I knew the relevant files. :D

                        1 Reply Last reply Reply Quote 0
                        • E
                          eri--
                          last edited by

                          /conf/dyndns*.cache

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