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.


Log in to reply