Compare your latency outside the tunnel (ping the remote server IP) vs. inside. The difference is likely very small. Probably ~99.99% of your 70-110 ms is the current latency on the Internet between your source and destination. Most of that's likely from the distance between the locations (or the distance it needs to travel on the Internet between the locations). With a faster CPU and better NICs you might shave a fraction of 1 ms off, but that'll have no real impact on performance.

Thanks for your returns and sad for this that it's not possible to use Windows Credentials directly, it's the only thing who keep hard for my users to adopt OpenVPN. I think I gonna try certificate by user, need to script it now to generate certificate for everyone :)

Yeah, not sure… I didn't get anything other than "OK \n 0", running that... but I couldn't connect the minute prior to (and a day or so) doing that change, then could straight afterwards. Edit: CN was "internal-ca"

@johnpoz: did you reinstall the package?  It has been recently updated. Well, that was easy. Thanks!

The DC pfSense is still on 2.1 HQ is on 2.2.2 I will turn on the extra IPsec debugging and report back. Thanks.

They are used during key exchange, and mostly the CPU-intensive part is generating them not using them, though I suppose that would depend on the systems on either side. I wouldn't expect them to have an ongoing/persistent effect on the VPN speed, just portions including key exchange.

Sadly this did not work

i want to add something i forgot: on client side when the openvpn process i s finished(as previous code) the tun interface came up without ip address. when i do the trick there is no problem. thanks again

Not really sure the issue with certificates with OpenVPN.  The  main purpose is to validate the connection between the user and server.  If you set up to require the user to put in the current password to be checked against RADIUS server I don't see what the issue is. I've set up the commercial OpenVPN AS server that way.  Long as the user have a valid and active account in Active Directory it doesn't matter.  It's really the administrator's responsibility to make sure any employee who are termed the accounts in AD are disabled. In this case with pfSense it's the same thing.  You still have to make sure the accounts in pfSense are disabled. Restricting the users to one connection is one way to make sure nobody is sharing the same certificate and user account password.

I didn't think so, but just wanted to make sure - thanks!

Thanks for the tip about Nitro Key. It looks intriguing, at the very least as a way to encrypt the OpenVPN client keys

Create Allow all policy for troubleshooting purpose. If ping works, create a policy which defined IPV4 ICMP to destination server

Can download the oldest config available in the history and see how it was set in there if you haven't already. That's likely before the upgrade, so you'll at least see it's been that way since before. @Zflash76: I'll blame my Minions for this ;) Pretty much a certainty. :) Every time we've had a "my config settings changed after upgrade!" support case along these lines, that's been the ultimate root cause. Show them their config history and that username@ <ip>actually made that change at X time on Y date, pre-dating the upgrade. Sometimes it was so long before the upgrade that the change isn't there, but the oldest revision proves it was set that way well before the upgrade.</ip>

That's no ghost tab. It's interface group tab for all defined OpenVPN servers. Usually, there's no need to assign these, if you do, then you'll have separate tabs for each assigned inteface as well. Note that the OpenVPN tab rules will still apply in that case, before the rules defined on individual assigned interfaces.

To be totally sure you're not getting munged by Windoze effects, you have to turn of the firewall on both ends, the source and the destination. Do you have anything else you can use to test? The web page of a printer on one side or the other is often a good choice for a test. Can you log in to the 10.50.1.1 pfSense from the 10.50.0.0 side? May be worth a ping test from 10.50.1.1 to 10.50.0.71 just to prove you have traffic flow in both directions. Other than that, I would be looking for something else blocking traffic after pfSense.

Hi, Just wanted to report back that, your advice was correct and when I checked my actual config, i had done all that. It was in fact fine. My problem was situational… in that my connection is PPPoE so when i send FW1 for a reboot during testing, i have to wait until that PPPoE is established on FW2, the CARP VIP's are transferred to FW2 and eventually the VPN connection will come back up. The issue was FW1 rebooted so fast that it causes a flip flop effect whereby it takes the CARP Master roles back...but the PPPoE WAN connection is still up on FW2 until i reboot it. I have now tested this all works with a full shutdown of one node (and someone on site to power it back up :) ) and visa versa. Interestingly the VPN all stay up despite the FW2 now having the backup CARP role for the VPN VIP, This may be due to the fact I do connect with "other" -> "ovpn.domain.com" in my client exports and that resolves anywhere with applicable DNS lookup to the CARP VPN VIP (an alias on the WAN). Seems this is nice and versatile. If you have any suggestion for how to handle an automatic failback (although doing it manually is ok) ....whereby the PPPoE gets dropped from FW2 back to FW1 if it comes back up i'd love to hear about that. Also I'll raise a seperate topic for this if I can't get it to work, but is there an easy way of assigning a static ip to an openvpn client, obviously not in the main network range but just making sure it gets the same ip everytime it connects in without creating a ton of different servers. I've read a bit about doing this but wondered if there was a nice way through the web gui... most other methods are detailed file edits in the underlying FreeBSD system? On 2.2.4 on both nodes now. Thanks.

And still- 2/ Do you have any rules on the OpenVPN tab? Then go to status/openvpn and post whats there. Got to status/system logs/openvpn and post what is there.

Yeah, the only problems I've ever had is when you don't run as administrator. That's a big one.