OSX Viscosity to pfSense 2.1 not working - cert issues?



  • Hello:

    I'm trying to access the LAN behind pfSense from remote locations using OpenVPN.

    xxx.xxx.xxx.xxx = pfSense WAN, yyy.yyy.yyy.yyy = client IP

    Connection fails, in Viscosity log I see:

    Oct 08 21:41:46: Viscosity Mac 1.4.5 (1151)
    Oct 08 21:41:46: Viscosity OpenVPN Engine Started
    Oct 08 21:41:46: Running on Mac OS X 10.8.4
    Oct 08 21:41:46: ---------
    Oct 08 21:41:46: Checking reachability status of connection...
    Oct 08 21:41:47: Connection is reachable. Starting connection attempt.
    Tue Oct  8 21:41:47 2013 DEPRECATED OPTION: --tls-remote, please update your configuration
    Oct 08 21:41:49: OpenVPN 2.3.2 i386-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Jun  7 2013
    Oct 08 21:41:59: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
    Oct 08 21:41:59: Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
    Oct 08 21:41:59: UDPv4 link local (bound): [undef]
    Oct 08 21:41:59: UDPv4 link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
    Oct 08 21:42:59: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    Oct 08 21:42:59: TLS Error: TLS handshake failed
    Oct 08 21:42:59: SIGUSR1[soft,tls-error] received, process restarting
    
    

    and errors on pfSense

    Oct 8 21:41:59 	openvpn[85187]: yyy.yyy.yyy.yyy:1194 VERIFY ERROR: depth=0, error=unsupported certificate purpose: C=US, ST=California, L=Lovelytown, O=secret, emailAddress=xxx@domain.com, CN=hidden
    Oct 8 21:41:59 	openvpn[85187]: yyy.yyy.yyy.yyy:1194 TLS_ERROR: BIO read tls_read_plaintext error: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
    Oct 8 21:41:59 	openvpn[85187]: yyy.yyy.yyy.yyy:1194 TLS Error: TLS object -> incoming plaintext read error
    Oct 8 21:41:59 	openvpn[85187]: yyy.yyy.yyy.yyy:1194 TLS Error: TLS handshake failed
    

    I went through the wizard and exported the config. The CN is a word with no spaces. Firewall has an incoming rule on WAN from the wizard (UDP, * sources, * ports, dest WAN address, port 1194, * gateway).

    Packet capture on 1194 shows:

    22:09:13.464442 IP (tos 0x0, ttl 55, id 12839, offset 0, flags [none], proto UDP (17), length 70)
        yyy.yyy.yyy.yyy.1194 > xxx.xxx.xxx.xxx.1194: [udp sum ok] UDP, length 42
    22:09:13.464887 IP (tos 0x0, ttl 64, id 62599, offset 0, flags [none], proto UDP (17), length 82, bad cksum 0 (->42b8)!)
        xxx.xxx.xxx.xxx.1194 > yyy.yyy.yyy.yyy.1194: [udp sum ok] UDP, length 54
    

    One (probably unrelated) question: The "IPv4 Tunnel Network" setting in pfSense – should that be a different subnet than the LAN? Will I still be able to reach LAN machines if it is a different subnet?

    Thanks. Your help is appreciated.



  • I had this same problem (and more than a year later). The solution I found was to generate a new bundle using the OpenVPN Client Export Utility package, and switching the "Verify Server CN" setting to "Automatic - Use verify-x509-name", since using tls-remote is now deprecated. The resulting .visc bundle worked perfectly. This was on the latest version of pfSense (2.1.5), so YMMV if you're running an older version.