@viragomann: If the cloud has no route back to the clients LAN, you have to set an S-NAT rule on the server site for the client-cloud connection. Ah ha!  This was the missing piece.  I added an outbound NAT rule for the remote LAN on the WAN interface and that completed the route. Thanks!

DERP! I figured it out.  I had the tunnel network set to a /24 instead of a /30.  with a /24 you need to specify routing commands manually on a site-to-site.

Tired of tinkering with the production environment to find out the problem and sometimes knocking down all the connections I decided to build a lab of virtual machines / networks and followed this tutorial creating an environment from scratch. https://forum.pfsense.org/index.php?topic=144212.0 And I have achieved connectivity between all pfsense hosts also between pfense hosts and the servers located in the Main Office. With this result I went into the production environment and created a new openvpn server on different port and started to migrate the branches from old configuration to new successfully. The above link is very practical and produces very little configuration on the clients, controlling almost everything in server configuration. Thanks to the friends who tried to help. Now I can rest my head, 8) 8) 8), because I have not thought of anything else for more than 7 days.

@bond_it: The only issue is that the OpenVPN export exports the interface IP address On the client export page, change host name resolution to 'other', enter vpn.mycompany.com in the host name box, then click the 'save as default' button.

Since I had a similar issue the solution I found was written here: https://forum.pfsense.org/index.php?topic=88467.msg491409#msg491409 System -> Advanced -> Networking (tab) and check the "Disable hardware checksum offload"

If you were using SSL/TLS, then the exporter will only show users with certificates created by the same CA set in the OpenVPN server as the Peer Certificate Authority. Without that they wouldn't be able to log in anyway so they are not shown for export. There is no Shared Key remote access server so I don't know what you actually did. Why are we talking about the Windows client when you're dealing with a site-to-site?

@svarto: The OPENVPN_interface is what I assigned in the Interfaces to network port ovpnc1, the other OpenVPN was created automatically when initializing OpenVPN service however there was no gateway created so that is why I bound the Network port ovpnc1 to a OpenVPN_interface. I assume this is the one I should be using? @svarto: I have DHCP activated on DO_VPN interface (and subnet), however the OpenVPN_Interface has both ipv4 and ipv6 types set as None. @svarto: I have specified explicitly the DNS servers for the DO_VPN DHCP_Server, please see attached screenshot. However, for LAN and OPT1 I haven't explicitly specified it and I assume they will be able to pull it automatically from my ISP through the WAN interface?

I tried this but it didn't help with PID_ERR large diff [227] [SSL-0] or Authenticate/Decrypt packet error: bad packet ID (may be a replay) Everything still goes slow and fast intermittently. Did you suggest it to help with the recursive problem? If so I think I've already fixed that by not having the LAN IP be 10.0.0.x. Not sure i understood everything I read up about recursive routing but it seemed to be related to subnets and where things go on either the vpn or home network. PIA gives a virtual address starting in 10.x.x.x so i took a guess and assumed having my LAN doing the same was a bad thing and the recursive error has gone now my LAN is on 192.168.1.x. Unfortunately the slow down wasn't affected by it. Still it's something. One less error to worry about. After trying to look up the PID_ERR it generally takes me back to or is linked with the Authenticate/Decrypt packet error. I've tried all the suggestions goggle has to offer to fix this but nothing seems to have worked. The only thing I'm left to conclude is that its either a PIA or ISP issue. Thanks for the help though.

Did your computer "walk barbarian"?  ;)

That happened to me because of many things: -  First i did not create firewall rules, so check them and also OpenVPN firewall rules.   -  Second check the Nat Outbound you have to create entrys according to your ip's.   -  Third Check the pfsense routing, also if your pfsense is behind a router ISP you have to contact them to check he routing.   -  Fourth The damn windows firewall also cause that problem. Hopes it helps you!

Sorry i should have been more clear, with the wrong net and without nopull everything was dropped. adding nopull was necessary to access internet but didn't fix vpn issues. correcting net meant nopull option could be removed without breaking internet access.

Hi, I was able to install the shit driver again but I`m still stuck on the OpenVPN connection. Maybe the TAP-Adapter is still not right installed. The office may block vpn access but then.. why did it worked some days ago? I think its more my TAP driver. Wed Feb 21 08:53:21 2018 OpenVPN 2.4.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 26 2017 Wed Feb 21 08:53:21 2018 Windows version 6.2 (Windows 8 or greater) 64bit Wed Feb 21 08:53:21 2018 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.10 Wed Feb 21 08:53:22 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]IP:1194 Wed Feb 21 08:53:22 2018 UDP link local (bound): [AF_INET][undef]:1194 Wed Feb 21 08:53:22 2018 UDP link remote: [AF_INET]IP:1194

So it should work with 2.4 client and 2.3 server! I have to give it a try in the weekend. Tx for your reply! /Peter @TriStarGod: OpenVPN 2.4 is backwards compatible with pfsense 2.3 OpenVPN 2.3. I was able resolve my random disconnect issue.

Hi! Just wanted to inform you that I finally manage to get this OpenVPN connection working!  :) If it can help, the only extra thing that I did is to create an account a noip.com and filled my freshly created DNS into the OpenVPN before exporting the config file (instead of my box provider external IP), and it worked like a charm (or almost, I had another bug with TAP windows driver, but thas was not a big deal…  ;) ) So thanks again for the help!  :)

I had this same problem.  I tried a bunch of the solutions found from googling and such. In my case, my NIC was bad. I swapped in a new NIC and the connection came up. pfsense version didn't matter, client OS didn't matter.  NIC card fail. 6 hrs troubleshooting argh