I figured everything out –- the problem was with the OVPN export part. I needed to change the hostname resolution part because it was defaulting to the WAN IP address but because there is a Verizon Router in front of my pfSense box, that WAN IP address is still an internal subnet address. After I changed the host name resolution to use a name, everything worked fine. Hope this helps anyone else who runs a pfSense behind a Verizon router

I hate to assume, so I'll just ask…. have you verified that they are launching the app as admin every time?  Check the clients routing table when they are connected.

Not currently. There is a redmine ticket out there already for it though. It would require some significant work to pull off.

That would be a question for OpenVPN itself. https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage

Are these SSH sessions idle during the 80 seconds? What happens if you run something that frequently updates like top?

@cmb: What version are you running? Deleting OpenVPN instances kills off the PID that OpenVPN writes to its PID file. There were issues with earlier OpenVPN 2.3.x versions where it doesn't correctly write out its PID file's contents, in which case deleting that instance will try to kill a PID that doesn't actually correspond to OpenVPN (and likely doesn't exist at all). You'll find the PID file in /var/run/openvpn_server1.pid (assuming it was instance 1). Check the running instance with 'ps auwwx | grep openvpn'. Its PID that's running is 43054 judging by your logs. That PID file likely has some other number in it ('cat /var/run/openvpn_server1.pid' to check). After verifying that, just run 'killall openvpn' and it'll be gone. Thanks, killall openvpn seemed to clear it out. There was a process running with PID 43054 but could not find any file in "/var/run/" for openvpn_server. Anyhow setup a new server and all seems to be working great. Thanks

i'm on 2.3 beta

Ok, the Issue is gone away after re-installing the box.

Solved by enable VPNDialogs system app, it was frozen and disabled before, using OpenVPN for Android.

It's an option. If you have small groups you can string them together, so that your groups can be expressed with e.g. /28 for 4 users or /27 for 8. So it is easy to create firewall rules with this subnets.

A second subnet on one interface isn't really a good idea, unless your ISP router supports VLANs. With a separate VLAN for pfSense it could route VPN traffic to pfSense. To add routes to each of your hosts you need to access from VPN isn't an option for you? Bridge mode is a bit tricky to get it up. There are many threads in this forum, but I don't use it myself. No, that has nothing to do with the one interface. If you have no other option you can try it. If you do NAT on pfSense for VPN the source address of packets from a VPN client is translated to the pfSense interface address. Subsequently it's not possible at a LAN host to determine which of client packets are coming from.

Have you run openssl speed tests on an older supported version and on the new 2.2 version of pfsense? I am curious if the padlock stuff was added into openssl similar to how aes-ni was. It may be wishful thinking but I am running into the same problem with a 64 bit VIA Nano board. I am trying to benchmark vs. linux installs. The pfsense numbers i'm getting (for a 1.6 ghz nano) are: openssl speed -evp aes-128-cbc: type            16 bytes    64 bytes    256 bytes  1024 bytes  8192 bytes aes-128-cbc      39334.77k  185436.84k  1302134.78k  3322120.07k 17558786.42k openssl speed -evp aes-128-cbc -engine cryptodev: type            16 bytes    64 bytes    256 bytes  1024 bytes  8192 bytes aes-128-cbc      34315.05k  140591.87k  728903.31k  2726613.71k 18504954.68k I don't have an install of the 2.1 branch with hardware crypto acceleration though. The difference between those two benches is small. I wonder if either you cannot turn the padlock engine off, or if you cannot turn it on. If you install 2.1, would you post the speeds you are getting please. Let me know if you can think of any other tests to run. Edit: From the pfsense mailing list, I also found this if you want to test your hwrng speed $ dd if=/dev/random of=/dev/null bs=1M count=100

@[NUT: link=topic=105139.msg586807#msg586807 date=1452746714] @Arancho: [SNIP] The only issue I have found occours when the OVPN tunnel goes down, for any reason, also if I shut it down, and PFSense does not delete the associated route. When the tunnel tries to go up again the service stops because it is not able to add the route (that already exists). The only way I found is to destroy the hanging interface "ifconfig ovpnc1 destroy". You know… this sounds a lot like the problem me and some others are having… though I never thought of fixing the interface that way.... I usually reboot once a service restart won help... ;) that's because ospf distributes the tunnel networks aswell. site1=a&c site2=c&d a–--b c----d when "a" goes down, the tunnel network(=route) for "a-b" is still being distributed via the "c-d" connection and never gets removed from the routing-table of site1. the solution is to prevent the tunnel-networks to be distributed. see: -Services: Quagga OSPFd: Edit interface: Accept Filter -play with disable acceptance/distribution in the global settings. takes some experimenting to get it to work & behaves differently when you run it on an interface or just a plain openvpn connection

You sure do not need that nat is for sure…  You have it on your lan interface... Here is what I found - 99 out of 100 times when someone thinks they need a nat, and dick with the outbound rules they mess it up ;)  Leaving it on automatic is most likely all you need.. Also curious what stops working?  Most likely your lan devices firewall would block these remote vpn tunnel networks unless you allow it - this is also common mistake made.

If your client gets disconnected and then reconnects quickly (< 60 sec), that would look like an additional connection from the provider's perspective since it would not have timed out yet. pfSense can't run more than one instance of a specific client at a time (even if you wanted to), so if you only have four configured in pfSense then it can only be running four. So either the provider is seeing a disconnected "ghost" session hanging around, or there is another client somewhere off pfSense connecting (local PC, perhaps? local lab setup?)

Hi, have you find any suitable solution to this issue? I'm experiencing quite the same. I'm not using your configuration but the problem is that the route created for the Ovpn tunnel sometimes is not deleted when the tunnel goes down. So I have to change the IPv4 Tunnel Network if I want to recreate the tunnel as the previous address in not more usable. Many thanks.

Hallo Frank :-) i can't change anything of the firewall. Also the network is as it is. My goal was to just establish a VPN-Tunnel from WAN-Interface of "pfsense B" to LAN-Interface of "pfsense A", which are both in the inner (trusted) network. I missed to draw the "LAN" Interface on "pfsense A", which may mislead you… Also the "WAN"-Interface of "pfsense A" is not drawn, which is connected to "Firewall".