Installed 2.3.5.  Restored backup.  Ran the same battery of speed tests.  Instant improvement! Speed's are still nothing like my non-vpn,  but that's as expected.  I got 50-80 Mbps on all the test sites that should be VPN.  Ironically, speedtest.net which the other day was showing my comcast IP but testing super slow, is now showing my vpn IP, but testing at 276 Mbps.  Oh well, at least I'm getting workable speeds through the vpn. Definitely are some different settings for OpenVPN in 2.4.2 vs 2.3.5.  Even though I set them per the guides, apparently something wasn't agreeing with my system. I think I'll stick with 2.3.5 until I see a real reason to upgrade.

Yes. It is possible. Remote Access Server: https://doc.pfsense.org/index.php/OpenVPN_Remote_Access_Server Policy-routed OpenVPN Client: https://www.infotechwerx.com/blog/Creating-pfSense-Connection-VPNBook VPNbook used there but any provider would work.

@bcruze: i've posted it a few times on here.    i did 2 trials with Nordvpn and my speeds with openvpn on pfsense and their proprietary software.  with 3 different devices at 3 different locations were terrible. i canceled both trials within the cancellation period.    i've love to hears others experiences I have managed NordVPN to work reasonably.  On ubuntu the trick was to use command line OpenVPN

Can you expand on why CSOs are used and why they are needed with SSL/TLS servers? Thanks.

if your policy routing you would have to have a rule above where you force traffic out a gateway or group that could not get to the vpn. Or sure it could be firewall on the vpn client side. Here pinging my vpn client box from the vpn server side. $ ping 10.0.8.2 Pinging 10.0.8.2 with 32 bytes of data: Reply from 10.0.8.2: bytes=32 time=112ms TTL=127 Reply from 10.0.8.2: bytes=32 time=104ms TTL=127 Reply from 10.0.8.2: bytes=32 time=102ms TTL=127 Reply from 10.0.8.2: bytes=32 time=114ms TTL=127 Ping statistics for 10.0.8.2:     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:     Minimum = 102ms, Maximum = 114ms, Average = 108ms

AES-256-CBC (256 bit key, 128 bit block) is utilised on both AirVPN clients.  See attached screenshot. [image: Capture.JPG] [image: Capture.JPG_thumb]

Same thing here but with a different option: 'ns-cert-type' was deprecated in OpenVPN 2.4 and removed in OpenVPN 2.5

With VyOS you have to go IPSec not openVPN.

Site B default gateway will need a route to the network you assign to ovpn clients. Have you configured it?

What is the default gateway of clients on both sides? Is it the pfsenses?

Well I managed to figure it out. Turns out I am an idiot. When I moved the machine off my edge, I had disabled the firewall under advanced settings. I had forgotten about this, and it turns out, as the helpful text points out, this also disables any NAT functionality. So after enabling the firewall, everything works as expected! Thanks for the help! And sorry for the confusion.

Hi Derelict Thanks for replying Its a very basic setup really, My  satelite box vu+ solose has ftp telent etc and would like to have access to ftp, i cant seem away to change port settings. So a simple setup of pfsense working fine, setup port forwarding and got the ftp working fine too. setup my Pia vpn and both ftp and Pia vpn working. Tried to add a kill switch using the floating rules my ftp stops dead. If i follow the https://www.privateinternetaccess.com/forum/discussion/29231/tutorial-setup-pia-on-pfsense-2-4-2 and use https://www.privateinternetaccess.com/forum/uploads/editor/92/w00wmc2lq7yt.png Then i get no ftp anway On the bottom of the post i read Disabling NAT'ing for the WAN is AN ABSOLUTE HORRIBLE IDEA and DOES NOT STOP TRAFFIC ROUTING. Disabling NAT address translation rules does not stop traffic from being routed out an interface if the VPN is down.  It only prevents the IP addressing from being translated when traffic is routed out that interface, which can result in routing RFC1918 addressing onto the WAN. The only way this blocks traffic is that an upstream router is most likely blocking non-internet routeable RFC1918 addresses, but at that point your traffic has already been leaked onto the WAN interface. The better solution is to make sure unintended traffic never leaves the WAN by creating pfSense float rules that allow only DNS and OpvenVPN traffic out the WAN and block everything else going out the WAN.  Such rules would only have affect when the VPN link is down and the WAN is the default route, to allow DNS lookup of the PIA host, and creating the VPN link, all other outbound traffic out the WAN should be blocked or rejected.  Once the VPN link is up and becomes the default route traffic will route unblocked over the VPN link. Thanks

You were probably right!

@dims: In order machines from his LAN respond to my pings, I was to configure NAT. By default, Windows machines do not respond for packets, came from networks, other than LAN. Allowing such access can be set in the Windows firewall. If all your traffic goes through the vpn there will be set the "Redirect gateway" option in the server settings. If your brother doesn't need this for other purposes, he should remove the check and enter his LAN network in the "Local Network/s" box. If he need that option, you can prevent that by adding the no-pull option and a route to the remote LAN to your client config.

Still get no luck. Somebody can give me more advice, please.