VM is OK. No IPsec problems with a VM. Start a new thread in the IPsec section for that with details for help with that.

Good work.  It really is amazing isnt it :)

I did make 2 open vpn servers on different ports and have each client connect to the separate one. I don't know if that is how it's supposed to be. The pfsense forums were down when I configured this the other day. Client 2 vpn config IPv4 Tunnel Network 192.168.22.0/24 IPv4 Remote Network 192.168.1.0/24,10.10.1.0/24 Client 1 vpn config IPv4 Tunnel Network 192.168.21.0/24 IPv4 Remote Network 192.168.1.0/24,10.10.2.0/24 Server vpn config client 1: IPv4 Tunnel Network 192.168.21.0/24 IPv4 Local Network/s 192.168.1.0/24 IPv4 Remote Network/s 10.10.1.0/24,10.10.2.0/24 client 2: IPv4 Tunnel Network 192.168.21.0/24 IPv4 Local Network/s 192.168.1.0/24 IPv4 Remote Network/s 10.10.2.0/24,10.10.1.0/24

The hub can't see the same subnet twice. To avoid the conflict, the remote sites have to do NAT. No way around it.

Update: Okay, I got this far that firewall rules added to the default OpenVPN interface work (i.e. drop all traffic from client 10.1.0.1 on Site B firewall), but if I add the same rule to the ovpnc1 (VPN) interface nothing happens. What is the purpose of adding ovpnc1 if firewall rules applied to it don't work?

If you want the VPN to be connected to LAN you must do both. Selecting LAN for the bridge in OpenVPN does not create a bridge, it only tells it where your LAN network is. You must create the LAN/OpenVPN bridge yourself separate from that setting.

Can you give any notes on this setup, did you need to create static routes on the remote ipsec routers to point to the openvpn subnet?

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 [image: index.php?action=dlattach;topic=97625.0;attach=65260] Under Firewall: Rules -> OPT1 tab, add the appropriate. ex: pass all traffic [image: index.php?action=dlattach;topic=97625.0;attach=65262] 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) [image: index.php?action=dlattach;topic=97625.0;attach=65264] [image: nat_rule.PNG_thumb] [image: nat_rule.PNG] [image: firewall_rule.PNG_thumb] [image: firewall_rule.PNG] [image: assign_interface.PNG_thumb] [image: 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.