After a bit of struggle I got it working. It's been a crash course in certificates and stuff like that, I just couldn't get everything to line up properly. Most guides shows how easy it is to export vpn settings to a windows client, but I run linux and had to struggle some more. At one point I even swapped out the drive in my laptop to an old harddrive installed with windows - just to see it work - which it didn't.. Then I discovered that even though I've told my ISP supplied router/modem to fork over the entire connection and external ip to my pfsense box, believing that would make the router/modem function as a pure modem, for some peculiar reason the firewall in the router/modem were still active. I disabled that, leaving the firewall duties to pfsense and suddenly everything worked. I flopped the linux drive back into the laptop and whadda'ya'know the linux vpn client worked just fine too.. Finally I modified the firewall rule for openvpn to block access to my local lan, so now I can connect to the virtual lan and use my internet connection to surf the web, while my home lan remains off limits fomr the outside. All in all I'm a happy camper!

In this case the static route doesn't depend on a OpenVPN connection. The route goes to a static interface address of the other pfSense.

Thanks Jimp!

What do you have chosen for "Hardware Crypto" in your OpenVPN config? Is this on your SG-2220? I presume with the default crypto options under System>Advanced, having AES-NI enabled. Past instances of this were all in pre-release 2.2.0 versions with certain ciphers and certain hardware crypto. Those were attributable to a problem in OpenVPN that we got fixed in OpenVPN pre-2.2.0 release. But apparently there is still some combination of options there that triggers the same issue.

You mean like the settings for host name resolution and everything else? No. You have to set them every time, unfortunately. You could probably modify the php with defaults but it'll get clobbered by updates. You could maybe make a patch.

For anyone else who runs into this; https://forum.pfsense.org/index.php?topic=106559.0

This appears to be a simple setup… post the openvpn configs from both sides (server1.conf and client1.conf respectively) and we'll have a better idea of what is happening.

Thank you both for your comments and insight.  I think that since I am the only person with VPN access, I will probably leave things as they are.  It will actually be helpful for administrative purposes, as I have no access to some of the devices on the vlans (other than my regular LAN) in my network unless I physically plug a machine into the correct port on my switch.  So this way, if I need to manage one of the devices on another vlan, I can simply connect via VPN, and I will have access to all vlans.

Thank you it seems that it was the firewall of the computer the weirdest  thing as if connected though LAN able to ping but on OpenVPN nothing until the firewall is down on the PC Thank you again

Again a quick update. It appears that the OpenVPN connection is now working! I have no idea what made it work, but I assume it has something to do with the fact that I'm not using a certificate anymore, but the username / password combination. I reset the pfSense router to factory defaults and it still works :-) The only problem now is that I seem to be losing connection now and then and the fact that I have no Internet at all whenever I'm connected to the VPN. I saw that there are more users that have experienced this issue, so I hope to find all the information I need here :-)

Another very basic consideration, what's your home LAN IP subnet and what's your sister's? If they're the same (eg. 192.168.0.0/24 or 192.168.1.0/24) you're likely going to have issues…...

Yes, I had that set. The solution was to select the VPN interface at Services -> DNS resolver -> Outgoing Network Interfaces. Thank you too!

i'm using ssh to connect to pfsense from LAN. then from pfSense i ssh to a host on the internet by routing through a site-2-site openVPN tunnel. no ssh-tunneling involved, but i doubt it matters. i did forget to mention i had to manually add a NAT entry for the vpn-interface so that it would also NAT the WAN-address of the def gw. (because automagically, it doesn't )

Do you have any more detail to share?  OpenVPN logs? System logs? There should be some record of why it's failing there, especially the OpenVPN log (Status > System Logs, OpenVPN tab)

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.