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



  • hi there
    i wanted to update a pfsense igel with the latest version. it went ok but the problem is now that after reboot i dont have internet access. it seems all alright and green on the status page of pfsense but i cant connect to any page of the internet.  i use ovpn just to tunnel all traffic to a vpn service. i have to restart the ovpn client service manually and then it works. Did anyone experience the same? maybe found a solution for it? or does anyone have another clue what the problem could be?
    thanks in advance for any helpful comment.
    best regards
    steve


  • Netgate Administrator

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

    Steve



  • 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


  • Netgate Administrator

    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



  • 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



  • 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).



  • 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


  • Netgate Administrator

    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



  • 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



  • 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?



  • 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.



  • 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


Log in to reply