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

Going to leave a reply here since I figured it out. Turns out layer 3 routing doesn't work with a switch. Which in retrospect obviously it doesn't, switches are level 2. I had previously followed a guide that had me set up an interface group consisting of a few nics I have on the pfsense box. And the guide had me set up an allow all rule on the interface group. And any rules I placed on the interface group doesn't actually redirect packet to gateway according to source. It just doesn't work. But as it turns out, I didin't actually need the allow all rule on the interface group anyways. I deleted the rule on the interface group, and then everything worked as it should on lan0. Again, this should have been obvious in retrospect because the lan0 firewall rule never had any states, but the interface group rule had all the states. Hope this helps someone else.

OK, so all of the answers to the ultimate questions listed  were a 100% match for me.  This is what I had to do:  In pfSense, go to System - Package Manager - Available Packages. Find the package called openvpn-client-export and hit the install button, then confirm.  I wasn't aware that there were additional packages. And now it makes sense why folks who have fresh installs run across this.

Redirect Gateway: is set to Force all client generated traffic through the tunnel. The user when he goes home the traffic is "correctly" redirected through the tunnel The user when he is at a client side the traffic does not redirect through the tunnel. (OpenVPN is on his laptop) What i was wondering is why does it get redirected in his home network and why it does not get redirected at another location. I do understand that it way have to do with network traffic policy’s that exist within the clients network but I just needed a more detailed view on the issue. Thanks for the previous reply.

@Pippin: There is the –float directive. See manual 2.4: https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage How that is handled by pfSense firewall. i do not know, just try it. As I read about the float directive, it appears to deal with incoming connections from clients and does not address updating the IP that the OpenVPN service is bound to after a WAN IP change on PFsense.    E.g. if a client is on a laptop connected to a flaky cellular hotsot and the connection breaks briefly causing the hotspot to reconnect and acquires a new public IP … the float directive will allow the client to re-connect and authenticate even though subsequent connections (post reconnect) are coming from a different IP than the initial connection.

True, every day learning more …

You do not need to create user in pfsense to allow for vpn access.  You just need to create a user cert using the CA you setup for your openvpn.

:) No opinions at all? Is this soo bad cfg approach that noone won`t even comment it? :)

@Derelict: Then you are still performing NAT there. Turn that off. Would you be able to explain? Thank you

@johnpoz: I would try the fast i/o option and play with your send/recv buffers while doing your testing  Does that help? It got a little better when enabling fast i/o, It seemed like I got the best speed (~4 Mbit/s) with 2.00 MiB send/receive buffer. I still think I could expect higher speed than this no?