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

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.