A few weeks ago I went through and tested LDAP auth with extended query in a few different LDAP setups with/without RFC2307 groups and updated the docs with better info on that and using multiple server entries limited by groups for these sorts of purposes. If you haven't reviewed the docs recently, look them over again. https://docs.netgate.com/pfsense/en/latest/usermanager/ldap.html https://docs.netgate.com/pfsense/en/latest/troubleshooting/authentication.html Also I highly recommend using an LDAP browser such as Apache Directory Studio to test your queries and settings to dial in getting the results you want.

@jims The traffic doesn't go through the WAN interface in a logical way. It is tunneled and come in on the OpenVPN interface in pfSense. Also the traffic cannot pass through a LAN device by default. This would require special settings on the device. Since I assume, you control this device, you can be sure that they are not done. The whole security depends on the VPN authentication, regardless how you realize the access to the LAN devices. The server is under your control, you say, so use strong password and client certificates and you're safe. On pfSense you can additionally configure, what the clients are allowed to access.

To answer this myself - I do not think OpenVPN user authentication failures from the pfSesne local database causes account lockout. SSH and Web UI failed logins will cause the source of the connection to be temporarily added to the block list. @jimp just answered this (as I type) to say it does not lockout the local database users. I have found, with help from Lawrence Systems videos (Tom L is a legend, n'est pas?) I can install FreeRadius package, and enable mobile one-time-passwords, add Radius users with OTP and get two benefits - disable accounts that fail to authenticate AND MFA/OTP. This satisfies UK Cyber Essentials, and I have a much stronger login process. Today is a good day.

Solved it, and now I can ping LAN IPs and do RDP etc. It was the devices on my LAN were not using the pfsense IP as their gateway, but a different gateway device. I didnt think all the target devices on the inside of the network needed the pfsence box as their gateway. It makes sence now. Also, a gateway IP is still not present for the openVPN connection, but connection to LAN devices and to the internet is working normally despite this.

@viragomann I appreciate your help, it pushed me in the right direction, there must indeed have been my ISP router out in the street box/head office. My WAN was using a private IP address with I assume the public IP address at my ISP router. I believe that traffic was hitting my Pfsense router but the outbound traffic was not being NAT'd correctly by the ISP router. Anyway, I upgraded to have a public IP on my router which resolved the issue.

@chpalmer That is a very common problem caused by the need to use NAT & RFC1918 addresses with IPv4. Back in the early 90s, when I first started using the Internet, I had a static address, I was using SLIP, which required manual configuration. In 1997, I started at IBM, and had 5 static, public addresses, 1 for my own computer and 4 for testing. A couple of years later, when I got a cable modem and built a firewall/router on Linux, I ran into my first problem caused by NAT. FTP broke! Back then, command line FTP was used and NAT broke active mode FTP. At the time, FTP clients generally didn't support passive mode. These days, things like VoIP and some games require a hack called STUN, to get around the problems caused by the hack called NAT. The answer to this is IPv6!

@sfermindi bear in mind those instructions are from a release from 2018. Things do change.

@owlbear If you don't mind a video, you can get one form the source : Configuring OpenVPN Remote Access in pfSense Software

@viragomann you had it right they didn't show up because there were no user certificates. So my configuration wasn't complete.

@jims Spoke too soon. It now shows it reconnects but all the traffic isn't passed. I can get to one of my PCs through the VPN but can't get to others, even after rebooting pfsense. Thought it was something to do with the other PC so tried another and even a printer than has a web page and no go. Not sure what to check now...

I managed to get it all working using a combination of Client specific overrides and natting on the router

I switched the OpenVPN server from TAP to TUN, set the IPv4 Tunnel Network to a different subnet and everything works now.

@viragomann Yeah I'm aware of all that. OpenVPN gives the pfsense VPN IP as DNS server. It works with anything public. It doesn't work with anything that should resolve to LAN IP. Doesn't work with FQDN. From the LAN side same DNS server does resolve FQDN. The remote machine is using the same domain as pfsense and what the LAN machines get via DHCP. But again I tested FQDN so even if the remote machine didn't know the domain it should get the correct response from the DNS server. I get what NAT does. I don't see why I'm having to use it. pfsense sees both the LAN and VPN networks as it's own literally everywhere I look. Usually with pf you are fighting to keep traffic from being able to go between different networks.

@bp81 It all depends also on what are the workstations are doing through the tunnels! As an example, you have 20 tunnels and heavy load on (through) them and this is like 50 tunnels and more with only some small traffic through them. No one of us is able to answer this question without knowing what traffic and how much traffic is running through that tunnels.