In this case your worry is not with OpenVPN itself, that would still encrypt the authentication, but with the traffic between pfSense and the RADIUS server since RADIUS is sent in the clear. If that leg is secure you shouldn't have much to worry about. The way MSCHAPv2 is used by PPTP and WAP2-Enterprise makes it easy to compromise those protocols, but OpenVPN is a much different animal.

@TDJ211: You could run "wc -l /path/to/timestamp/file" to get a count. Where do I run this? On the CLI in putty? When I did I got "no such file name exists blah, blah, blah" Is it because it has yet to report an OpenVPN restart yet? You run that on the command line using putty or through the pfSense web interface. I assume you're putting the full path to wherever you have the timestamp file. When I used the relative path, like in the script I posted, it put the file at /var/log/timestamps.txt (which is not the location I expected). If you're not sure where it is, you can run this to find the absolute path: find / -name "timestamps.txt" In light of the above issue, I would recommend editing the script and changing "./timestamps.txt" to "/root/timestamps.txt" or some other absolute path so there is no question as to where it is. I will go back and change what I posted earlier. If the script hasn't kicked in and restarted your VPN yet, the file won't exist. If you want to see what the file will look like, run this from the command line:``` date "+%Y-%m-%d %H:%M:%S" >> /absolute/path/to/timestamps.txt That will create the file, insert a timestamp, and then you should be able to run the "wc" command (with absolute path) successfully with a result of 1. * I'm not sure how much you know about this stuff, so I apologize if the absolute/relative path comments are unnecessary.

i used this https://www.highlnk.com/2013/12/configuring-openvpn-on-pfsense/ it was great :) only few issues with WPAD but thats another story

MontanaIce, Glad it's working!  Just wanted to point out that no manual advanced settings or static routes were required though…. if you put the relevant info into the GUI, the correct openvpn configuration statements are automatically generated.  e.g.: Push 10.5.0.0/16 to your clients This can be added to the server config in the GUI under "IPv4 Local Network/s" Add a return route for the road warrior tunnel network (172.16.4.0/24) to Site A This can be added to the client config in the GUI under "IPv4 Remote Network/s" This will keep everything "cleaner" and within the openvpn config.  It will also be helpful if you ever need to analyse your .conf files and/or GUI options.  Also, while it's working, I don't think you want a static route to the external IP…  I would add the relevant info to the GUI and let PFsense generate the correct directives.

Okay, this makes no sense to me.  On a whim, I changed the tunnel network from a /30 to a /29 and now both ends are routing.  I had it as a /30 because the documentation I read said that no matter what size you make your tunnel network, it will chop it into /30s for each client.  Since I only had one client, I just made it a /30.

How exactly did you create your certificates? If you generated them all with the same serial number, that would explain why revoking one blocks them all. CRLs work by certificate serial, and if your certificate generation script or system did not give each certificate a unique serial number, then they all will be revoked if you revoke one of them. Look at the full cert details from a few of your certs and compare the serials.

Problem solved, user certificates was missing.

In the server settings check "Redirect Gateway". This should push the default route to the client. Remember that you run OpenVPN on Windows with admin privileges. On the pfSense server go to Firewall > NAT > Outbound and check if there is a rule for WAN interface, with source = your vpn tunnel network and NAT Address = WAN address. If it isn't there, add it manually.

Success! I accomplished this with two LAN rules, which I forgot to move to the top, duh. One for Hulu/PC routing to WAN, another for Server routing to PIAVPN. Marked the latter one as NO_WAN_EGRESS. Created then a floating rule. Question: PIA has a few US servers. Can I create multiple interfaces and use them for failover? E.g. PIA1 US-EAST, PIA2 US-NY, if PIA1 goes down, pfSense will try to bring up PIA2. Action: Reject Quick: Checked Interface: WAN (you can also select multiple WAN interfaces or an interface group here) Direction: out Protocol: any Source: any Destination: any Description: Reject outbound traffic marked NO_WAN_EGRESS Advanced: You can match packet on a mark placed before on another rule: NO_WAN_EGRESS

Replying to myself, I found the solution thanks to this post: https://forum.pfsense.org/index.php?topic=88467.msg504596#msg504596 Go to "System->Advance Networking" and disable: Hardware Checksum Offloading Hardware TCP Segmentation Offloading Hardware Large Receive Offloading and reboot.

Don't push a default route and put rules on your OpenVPN tab only allowing access to LAN.

do you allow ping to your wan?  If not then ping would fail.. Is the site using a proxy?  If so you have to tell the openvpn client to use a proxy. So your saying the tcp openvpn works at hotspot location #1 but not at this #2 site?  Or is your tcp vpn not working anywhere?

Glad you worked it out. Perhaps you could update the title of your first post with "[Solved]".

Everything I've read seems to indicate that my choices are bridged or routed+NAT For a simple remote access setup, you don't need NAT.  There are situations where NAT is a workaround or puts a band-aid on certain issues, but none of them apply to your situation. I've searched and could not find a post or any documentation for running openvpn with an external dhcp server unless you setup a bridged solution.  Even if you could, it might mess with tracking on your dashboard. Configure a road warrior, routed solution where your clients get their IP from the OpenVPN server.  Problem solved…. and you can monitor your connected clients from the dashboard. Pretty straight forward -> https://doc.pfsense.org/index.php/OpenVPN_Remote_Access_Server