Fresh build 2.3.3-Dev - Solved



  • Note sure this does in 2.3.3-dev board or in the OpenVPN board, but I will start here because It's more likely my inexperience with OpenVPN is the problem compared to a 2.3.3-dev bug.

    Been using pfSense for quite a few years, but was never really comfortable with certs and Open VPN.

    Fresh Rebuild on yesterdays code, and upgraded to todays.
    Simple 2 interface LAN/WAN, DNS resolver and DHCP have been configured, most of the rest remains stock.
    only package installed in openvpn client export.
    -created a CA (VPN server CA)
    -created a VPN user, and a user cert for it and assigned the user cert to the user
    looking at the certs, I indeed see three there.  the webconfig that came with, the VPN server cert (server:yes), and the VPNUSER cert (user:yes)

    I ran the open VPN wizard and I see the server, with my port and UDP listed, the tunnel network I chose for the connecting users.  I specified the Domain name and my internal DNS so that I can resolve names through VPN once connected. I see no client, and thats fine as I do not want to use VPN as a client, just a server.

    in the client export area, things seem OK, all I need to change is change the host name resolution to the second last entry (my tested working dynamic dns domain name)
    under Open VPN clients it lists vpnuser and vpnuser cert, so I click x64-win6 to get the client for my surface pro.

    I installed in on my surface pro and run it as an admin. use my vpnuser account name and password and this is where things go off board

    1. if I am on my internal wifi (LAN segment on my pfSense) it autheticated and connects.  obviously this is of no value why vpn from inside my network into inside my network !
    2. If I use my mobile phone wifi as a hotspot for an external Internet connection it does not complete the connection. It says connecting to myip:myport, then error tls key negotiation failed to occur within 60 seconds tls handshake failed , and process restarting.

    under firewall, I see a couple outbound nat entries (one LAN, one WAN) that reference my internal network as well as the tunnel network. but no floating / WAN / LAN or OpenVPN rules.

    checking the openvpn system log, I only see one line that looks like an error (Oct 16 22:02:13 openvpn 15575 ioctl(TUNSIFMODE): Device busy: Device busy (errno=16)) and no reference to the attempted connection.

    any ideas on where to look next?

    Oct 16 22:02:13 openvpn 15388 OpenVPN 2.3.12 amd64-portbld-freebsd10.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Oct 6 2016
    Oct 16 22:02:13 openvpn 15388 library versions: OpenSSL 1.0.1s-freebsd 1 Mar 2016, LZO 2.09
    Oct 16 22:02:13 openvpn 15575 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
    Oct 16 22:02:13 openvpn 15575 Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file
    Oct 16 22:02:13 openvpn 15575 TUN/TAP device ovpns1 exists previously, keep at program end
    Oct 16 22:02:13 openvpn 15575 TUN/TAP device /dev/tun1 opened
    Oct 16 22:02:13 openvpn 15575 ioctl(TUNSIFMODE): Device busy: Device busy (errno=16)
    Oct 16 22:02:13 openvpn 15575 do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
    Oct 16 22:02:13 openvpn 15575 /sbin/ifconfig ovpns1 192.168.2.1 192.168.2.2 mtu 1500 netmask 255.255.255.0 up
    Oct 16 22:02:13 openvpn 15575 /usr/local/sbin/ovpn-linkup ovpns1 1500 1557 192.168.2.1 255.255.255.0 init
    Oct 16 22:02:13 openvpn 15575 UDPv4 link local (bound): [AF_INET]WAN_IP:VPNPORT
    Oct 16 22:02:13 openvpn 15575 UDPv4 link remote: [undef]
    Oct 16 22:02:13 openvpn 15575 Initialization Sequence Completed



  • This is solved

    as I noted above, I was missing the firewall rule that the wizard was to create.  I suspect that I didn't check the two boxes to make my rules, bonehead move!

    Since I was not sure what to do to manually create the rules, I reran the wizard, exactly as I wanted, except on another port. I then edited the rule created to reflect the port I wanted.

    That's all it took!