[Solved] PureVPN almost working…. with pfSense 2.3.4



  • I've spent several days Googling, I'm swallowing my pride and asking for help.  :-[

    Goal:  I do NOT want the VPN used except for explicit firewall rules from specific IP addresses.  When I try this, I see States being assigned to the firewall rule.  It appears packets are being sent out, my problem is that inbound packets are not being seen.

    pfSense 2.3.4.  The VPN is UP and VPN Gateway is connected.

    The PureVPN CA and Client Certs, and OpenVPN client configured per typical guidelines, except - ticked "Disable IPv6".  I set the following Advanced Custom Option:
    [code]verb 5;
    auth-nocache;
    remote-cert-tls server;
    route-nopull

    NOTE - with the "route-nopull" I do not see inbound packets.  If I remove that, then I see a steady stream of packets.  I assume from the connection monitoring.  This observation is based on the dashboard traffic graph widget.

    OpenVPN Client Logs:

    May 30 20:12:39	openvpn	88266	OpenVPN 2.3.14 amd64-portbld-freebsd10.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on May 3 2017
    May 30 20:12:39	openvpn	88266	library versions: OpenSSL 1.0.1s-freebsd 1 Mar 2016, LZO 2.10
    May 30 20:12:39	openvpn	88266	WARNING: file '/var/etc/openvpn/client2.up' is group or others accessible
    May 30 20:12:39	openvpn	88606	MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client2.sock
    May 30 20:12:39	openvpn	88606	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
    May 30 20:12:39	openvpn	88606	Control Channel Authentication: using '/var/etc/openvpn/client2.tls-auth' as a OpenVPN static key file
    May 30 20:12:39	openvpn	88606	Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
    May 30 20:12:39	openvpn	88606	Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
    May 30 20:12:39	openvpn	88606	LZO compression initialized
    May 30 20:12:39	openvpn	88606	Control Channel MTU parms [ L:1558 D:1184 EF:66 EB:0 ET:0 EL:3 ]
    May 30 20:12:39	openvpn	88606	Socket Buffers: R=[42080->42080] S=[57344->57344]
    May 30 20:12:39	openvpn	88606	Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:143 ET:0 EL:3 AF:3/1 ]
    May 30 20:12:39	openvpn	88606	Local Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client'
    May 30 20:12:39	openvpn	88606	Expected Remote Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server'
    May 30 20:12:39	openvpn	88606	Local Options hash (VER=V4): '9e7066d2'
    May 30 20:12:39	openvpn	88606	Expected Remote Options hash (VER=V4): '162b04de'
    May 30 20:12:39	openvpn	88606	UDPv4 link local (bound): [AF_INET]192.168.1.8
    May 30 20:12:39	openvpn	88606	UDPv4 link remote: [AF_INET]172.111.234.4:53
    May 30 20:12:39	openvpn	88606	TLS: Initial packet from [AF_INET]172.111.234.4:53, sid=5384af81 00559ad6
    May 30 20:12:39	openvpn	88606	VERIFY OK: depth=1, C=HK, ST=HK, L=HongKong, O=PureVPN, OU=IT, CN=PureVPN, name=PureVPN, emailAddress=mail@host.domain
    May 30 20:12:39	openvpn	88606	Validating certificate key usage
    May 30 20:12:39	openvpn	88606	++ Certificate has key usage 00a0, expects 00a0
    May 30 20:12:39	openvpn	88606	VERIFY KU OK
    May 30 20:12:39	openvpn	88606	Validating certificate extended key usage
    May 30 20:12:39	openvpn	88606	++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
    May 30 20:12:39	openvpn	88606	VERIFY EKU OK
    May 30 20:12:39	openvpn	88606	VERIFY OK: depth=0, C=HK, ST=HK, L=HongKong, O=PureVPN, OU=IT, CN=PureVPN, name=PureVPN, emailAddress=mail@host.domain
    May 30 20:12:40	openvpn	88606	Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
    May 30 20:12:40	openvpn	88606	Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    May 30 20:12:40	openvpn	88606	Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
    May 30 20:12:40	openvpn	88606	Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    May 30 20:12:40	openvpn	88606	Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
    May 30 20:12:40	openvpn	88606	[PureVPN] Peer Connection Initiated with [AF_INET]172.111.234.4:53
    May 30 20:12:42	openvpn	88606	SENT CONTROL [PureVPN]: 'PUSH_REQUEST' (status=1)
    May 30 20:12:42	openvpn	88606	PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 172.111.234.5,dhcp-option DNS 4.2.2.2,sndbuf 393216,rcvbuf 393216,route-gateway 172.111.234.193,topology subnet,ping 10,ping-restart 120,ifconfig 172.111.234.195 255.255.255.192'
    May 30 20:12:42	openvpn	88606	Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS])
    May 30 20:12:42	openvpn	88606	Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
    May 30 20:12:42	openvpn	88606	Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
    May 30 20:12:42	openvpn	88606	OPTIONS IMPORT: timers and/or timeouts modified
    May 30 20:12:42	openvpn	88606	OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
    May 30 20:12:42	openvpn	88606	Socket Buffers: R=[42080->393216] S=[57344->393216]
    May 30 20:12:42	openvpn	88606	OPTIONS IMPORT: --ifconfig/up options modified
    May 30 20:12:42	openvpn	88606	OPTIONS IMPORT: route-related options modified
    May 30 20:12:42	openvpn	88606	WARNING: potential conflict between --remote address [172.111.234.4] and --ifconfig address pair [172.111.234.195, 255.255.255.192] -- this is a warning only that is triggered when local/remote addresses exist within the same /24 subnet as --ifconfig endpoints. (silence this warning with --ifconfig-nowarn)
    May 30 20:12:42	openvpn	88606	TUN/TAP device ovpnc2 exists previously, keep at program end
    May 30 20:12:42	openvpn	88606	TUN/TAP device /dev/tun2 opened
    May 30 20:12:42	openvpn	88606	do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
    May 30 20:12:42	openvpn	88606	/sbin/ifconfig ovpnc2 172.111.234.195 172.111.234.193 mtu 1500 netmask 255.255.255.192 up
    May 30 20:12:42	openvpn	88606	/sbin/route add -net 172.111.234.192 172.111.234.193 255.255.255.192
    May 30 20:12:42	openvpn	88606	/usr/local/sbin/ovpn-linkup ovpnc2 1500 1558 172.111.234.195 255.255.255.192 init
    May 30 20:12:42	openvpn	88606	Initialization Sequence Completed
    

    The OpenVPN Client Status:

    Client Instance Statistics
    Name	Status	Connected Since			Virtual Address	Remote Host	Bytes Sent	Bytes Received
    PureVPN	up	Tue May 30 20:12:42 2017	172.111.234.195	172.111.234.4	64 KiB		5 KiB
    

    Interfaces:
    I created an Interface named "VPN" using port ovpn2 for UDP.  (ovpn1 is for TPC, that client is disabled).

    Gateways:

    NAT Rules - Manual Outbound NAT rule generation:

    LAN Firewall Rule:

    NOTE:  There are NO firewall rules for VPN or OpenVPN interfaces.  The WAN only has the default rule to "Block bogon networks".

    As you can see above, the rule picks up States when I test from the client,  This is what I get from the client:

    root@sabnzbd_1:/ # ifconfig | grep inet
    	inet6 ::1 prefixlen 128 
    	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
    	inet 127.0.0.1 netmask 0xff000000 
    	inet 192.168.0.236 netmask 0xffffff00 broadcast 192.168.0.255
    
    root@sabnzbd_1:/ # ping 172.217.3.36
    PING 172.217.3.36 (172.217.3.36): 56 data bytes
    ^C
    --- 172.217.3.36 ping statistics ---
    8 packets transmitted, 0 packets received, 100.0% packet loss
    
    root@sabnzbd_1:/ # ping google.com
    ping: cannot resolve google.com: Host name lookup failure
    
    

    As soon as I disable the VPN Firewall Rule, works fine:

    root@sabnzbd_1:/ # ping google.com
    PING google.com (216.58.217.78): 56 data bytes
    64 bytes from 216.58.217.78: icmp_seq=0 ttl=55 time=8.964 ms
    64 bytes from 216.58.217.78: icmp_seq=1 ttl=55 time=12.396 ms
    64 bytes from 216.58.217.78: icmp_seq=2 ttl=55 time=3.883 ms
    ^C
    --- google.com ping statistics ---
    3 packets transmitted, 3 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 3.883/8.414/12.396/3.497 ms
    root@sabnzbd_1:/ # ping 172.217.3.36
    PING 172.217.3.36 (172.217.3.36): 56 data bytes
    64 bytes from 172.217.3.36: icmp_seq=0 ttl=55 time=7.659 ms
    64 bytes from 172.217.3.36: icmp_seq=1 ttl=55 time=9.544 ms
    64 bytes from 172.217.3.36: icmp_seq=2 ttl=55 time=7.082 ms
    64 bytes from 172.217.3.36: icmp_seq=3 ttl=55 time=7.237 ms
    ^C
    --- 172.217.3.36 ping statistics ---
    4 packets transmitted, 4 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 7.082/7.880/9.544/0.983 ms
    

    I have squid and squid guard services disabled to reduce complexity.  I did a clean reboot of pfSense prior to posting this.

    Any suggestions would be appreciated.  If you need additional information, let me know.



  • Apparently I did everything correctly.  I tried an alternate VPN server instance and it fired right up.  Was able to sustain 12MB/s transfers over the VPN.

    Since this started working, I changed the firewall rule to use an IP alias instead (to allow additional IP's to be added without editing firewall rule itself).  Other wise the configuration is the same.

    Hope this helps someone in the future.



  • Just to add some interesting and noted material for PureVPN…

    I followed the PureVPN instructions to the letter and looked here and other places because for all the setup, I wasn't getting jack squat for traffic coming through.  It would appear as though in the Advanced Custom Option, I wasn't running any of Reefland's extra items.  I did a little debug and found adding this one following item made it all work:

    comp-lzo

    The tip-off was I didn't think much of it but the log was squawking about an MTU difference of one byte.  I can definitively say this parameter got it working flawless for me.



  • You can also change Firewall Optimization Options to conservative



  • Another issue I found, could not connect for the life of me, following PureVPN steps and tips here, then spoke to support, turns out dedicated IP hosts dont work with OVPN, only PPTP / L2TP. As soon as I changed to one of PureVPNs "normal" public hosts it connected instantly.  Im using PF 2.4.3 with custom options in VPN client settings as below:

    verb 5;
    auth-nocache;
    remote-cert-tls server;
    comp-lzo

    a handy list of PureVPN servers –>>  https://support.purevpn.com/vpn-servers