Sorry folks, it was a firewall rules. On the client side I had to put allow ALL rules into the OpenVPN firewall tab section. It was already done at the server by virtue of being the server and whatever guide I read. Thanks for the advice.

Everything is now working, thank you very much divsys and heper for all the pointers.

For those looking for a similar setup, here's what I needed to do.

I needed to assign the OpenVPN client connection sto an interface, ex: OPT1 and set the Interface Type to none

Under Firewall: Rules -> OPT1 tab, add the appropriate. ex: pass all traffic

Under Firewall: NAT -> Outbound tab, select the interface used for the OpenVPN connection (ex: OPT1) and add the destination network (ex: 10.8.0.0/24)

nat_rule.PNG_thumb
nat_rule.PNG
firewall_rule.PNG_thumb
firewall_rule.PNG
assign_interface.PNG_thumb
assign_interface.PNG

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.