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

    Update from nanobsd (4g) 2.1.5 to 2.2.1, no ovpn after boot

    Problems Installing or Upgrading pfSense Software
    4
    12
    1.5k
    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.
    • stephenw10S
      stephenw10 Netgate Administrator
      last edited by

      So is this every boot or just after the upgrade?
      Check the openvpn logs for reason for the connection failure.

      Steve

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

        hi Steve
        This happens at every boot. I am thinking now its a bug. there is no error message in the ovpn log. The only suspicous entry is the Device busy line. after ovpn client restart it doesnt appear anymore and it works.
        best regards
        steve

        1 Reply Last reply Reply Quote 0
        • stephenw10S
          stephenw10 Netgate Administrator
          last edited by

          Do you have the exact error given?
          I expect it to continue trying to connect if for some reason it's at first unable to. Odd that it isn't. You are using the Via Padlock driver yes? Perhaps it's that that's busy. Try unselecting that as hardware crypto as a test.

          Steve

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

            hi stephenw10
            here is the last part of the ovpn log

            Apr 10 11:10:42 openvpn[14650]: TUN/TAP device /dev/tun1 opened
            Apr 10 11:10:42 openvpn[14650]: ioctl(TUNSIFMODE): Device busy: Device busy (errno=16)
            Apr 10 11:10:42 openvpn[14650]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
            Apr 10 11:10:42 openvpn[14650]: /sbin/ifconfig ovpnc1 10.8.0.6 10.8.0.5 mtu 1500 netmask 255.255.255.255 up
            Apr 10 11:10:42 openvpn[14650]: /usr/local/sbin/ovpn-linkup ovpnc1 1500 1542 10.8.0.6 10.8.0.5 init
            Apr 10 11:10:43 openvpn[14650]: Initialization Sequence Completed
            Apr 10 11:10:43 openvpn[15185]: TUN/TAP device ovpnc4 exists previously, keep at program end
            Apr 10 11:10:43 openvpn[15185]: TUN/TAP device /dev/tun4 opened
            Apr 10 11:10:43 openvpn[15185]: ioctl(TUNSIFMODE): Device busy: Device busy (errno=16)
            Apr 10 11:10:43 openvpn[15185]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
            Apr 10 11:10:43 openvpn[15185]: /sbin/ifconfig ovpnc4 10.9.0.18 10.9.0.17 mtu 1500 netmask 255.255.255.255 up
            Apr 10 11:10:43 openvpn[15185]: /usr/local/sbin/ovpn-linkup ovpnc4 1500 1542 10.9.0.18 10.9.0.17 init
            Apr 10 11:10:43 openvpn[15185]: ERROR: FreeBSD route add command failed: external program exited with error status: 1
            Apr 10 11:10:43 openvpn[15185]: ERROR: FreeBSD route add command failed: external program exited with error status: 1
            Apr 10 11:10:43 openvpn[15185]: Initialization Sequence Completed

            i didnt get the error messages before which is strange. after restarting the ovpn client it works alright. the via padlock driver? i thought thats activated automatically? where could i disable it?
            best regards
            stephen

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

              Which of the two OpenVPN instances there in the log is it that doesn't work? The "ERROR: FreeBSD route add command failed: external program exited with error status" seems most likely to be the root cause, though restarting the client shouldn't change that (though it's possible you reconnect to a diff server which just happens to fix the issue).

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

                hi
                no ovpn instance works.

                Apr 11 03:16:47 openvpn[15949]: [TG-OVPN-CA] Peer Connection Initiated with [AF_INET]67.215.236.82:443
                Apr 11 03:16:49 openvpn[15949]: TUN/TAP device ovpnc4 exists previously, keep at program end
                Apr 11 03:16:49 openvpn[15949]: TUN/TAP device /dev/tun4 opened
                Apr 11 03:16:49 openvpn[15949]: ioctl(TUNSIFMODE): Device busy: Device busy (errno=16)
                Apr 11 03:16:49 openvpn[15949]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
                Apr 11 03:16:49 openvpn[15949]: /sbin/ifconfig ovpnc4 10.9.0.30 10.9.0.29 mtu 1500 netmask 255.255.255.255 up
                Apr 11 03:16:49 openvpn[15949]: /usr/local/sbin/ovpn-linkup ovpnc4 1500 1542 10.9.0.30 10.9.0.29 init
                Apr 11 03:16:49 openvpn[15949]: Initialization Sequence Completed

                again it says completed, evrything looks ok and is green on status page but i cant connect to internet. i have to restart the ovpn client manually to fix it.

                Apr 11 03:18:51 openvpn[8895]: [TG-OVPN-CA] Peer Connection Initiated with [AF_INET]67.215.236.82:443
                Apr 11 03:18:54 openvpn[8895]: TUN/TAP device ovpnc4 exists previously, keep at program end
                Apr 11 03:18:54 openvpn[8895]: TUN/TAP device /dev/tun4 opened
                Apr 11 03:18:54 openvpn[8895]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
                Apr 11 03:18:54 openvpn[8895]: /sbin/ifconfig ovpnc4 10.9.0.34 10.9.0.33 mtu 1500 netmask 255.255.255.255 up
                Apr 11 03:18:54 openvpn[8895]: /usr/local/sbin/ovpn-linkup ovpnc4 1500 1542 10.9.0.34 10.9.0.33 init
                Apr 11 03:18:54 openvpn[8895]: Initialization Sequence Completed

                this is the log after the restart. i am thinking about returning to 2.1.5 for one machine which has to work after boot without restarting manually the ovpn client. how insecure is the 2.1.5 version?
                best regards
                steve

                1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator
                  last edited by

                  Check the routing table after boot when the tunnel is up but traffic passes. Are the required routes there?

                  It looks from the routing error shown that there is some issue adding the routes.

                  This is something commonly caused by having both TUN and TAP configurations or having switched  between them.

                  Steve

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

                    Hi Stephen
                    Please disregard my paste with the error messages. That isn’t the normal procedure when I reboot. That was a one time only error.
                    After reboot everything is ok on status page and green and the ovpn log looks like this:
                    n
                    Apr 12 08:47:09 openvpn[15774]: WARNING: this configuration may cache passwords in memory – use the auth-nocache option to prevent this
                    Apr 12 08:47:12 openvpn[15774]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1542', remote='link-mtu 1574'
                    Apr 12 08:47:12 openvpn[15774]: WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'
                    Apr 12 08:47:12 openvpn[15774]: [TG-OVPN-CA] Peer Connection Initiated with [AF_INET]67.215.236.50:443
                    Apr 12 08:47:14 openvpn[15774]: TUN/TAP device ovpnc4 exists previously, keep at program end
                    Apr 12 08:47:14 openvpn[15774]: TUN/TAP device /dev/tun4 opened
                    Apr 12 08:47:14 openvpn[15774]: ioctl(TUNSIFMODE): Device busy: Device busy (errno=16)
                    Apr 12 08:47:14 openvpn[15774]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
                    Apr 12 08:47:14 openvpn[15774]: /sbin/ifconfig ovpnc4 10.9.0.38 10.9.0.37 mtu 1500 netmask 255.255.255.255 up
                    Apr 12 08:47:14 openvpn[15774]: /usr/local/sbin/ovpn-linkup ovpnc4 1500 1542 10.9.0.38 10.9.0.37 init
                    Apr 12 08:47:14 openvpn[15774]: Initialization Sequence Completed

                    And here after restarting manually the ovpn client:

                    Apr 12 08:48:38 openvpn[7583]: TUN/TAP device ovpnc4 exists previously, keep at program end
                    Apr 12 08:48:38 openvpn[7583]: TUN/TAP device /dev/tun4 opened
                    Apr 12 08:48:38 openvpn[7583]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
                    Apr 12 08:48:38 openvpn[7583]: /sbin/ifconfig ovpnc4 10.9.0.42 10.9.0.41 mtu 1500 netmask 255.255.255.255 up
                    Apr 12 08:48:38 openvpn[7583]: /usr/local/sbin/ovpn-linkup ovpnc4 1500 1542 10.9.0.42 10.9.0.41 init
                    Apr 12 08:48:38 openvpn[7583]: Initialization Sequence Completed

                    And it works alright.

                    Best regards
                    steve

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

                      I still have not found a solution for my problem. It think it’s a bug which only happens on my igel thin clients. Should I open a bug ticket?

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

                        Reporting that I have the exact same error but after upgrading to pfsense 2.2.2.

                        The issue is this line that shows up when the OpenVPN service starts at boot and automatically connects:

                        ioctl(TUNSIFMODE): Device busy: Device busy (errno=16)

                        Whereas if the OpenVPN service was restarted, this line is missing.

                        Am on a box with an Intel motherboard if it is helpful.

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

                          hi charliex
                          this is a surprise for me because i thought this problem appears only on the igel thin client.maybe because of the via padlock. but if you have the same problem on a different hardware it seems not related to the igel. i am with networks clueless so i have no idea whats the trouble. but it worked fine on 2.1.5 and after the update it didnt work anymore whitout me changing anything so i think its a bug in the software. i think will open a bug report.
                          best regards
                          steve

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