Sounds like you have a low-level filesystem issue. Take a config backup before doing anything about it. You might be able to use the console reboot menu to run a fsck (disk check) for the next reboot, if that doesn't work you'll need to reboot to single user mode from the loader menu and then run "fsck -y /" a few times until it finds nothing wrong. Don't stop running it when it claims the disk has been fixed, it needs to be re-run until it finds no new problems. Worst case scenario, reinstall using the recover config.xml option to retain your existing settings.

OK Solved! I've flag the option "Force all client generated traffic through the tunnel" in client specific overrides, this time worked perfectly! Thanks to all!!

The optimal buffer size depends on your connection and other factors, it's not so simple as picking a number and using that for everything. There is a GUI control for send/receive buffer in 2.4.x, you can use that if you like, or if you leave it set at 'default' then you can still use whatever advanced option you want for those directives.

It's actually not the e-mail address that is the trigger but any SAN in addition to a CN with a space. It tries to copy the CN to the SAN list, but a CN with a space can't make a valid SAN entry, so it ended up with a bunk empty entry due to the way I coded that feature originally. https://redmine.pfsense.org/issues/8252 I just pushed a fix, should show up in a few minutes.

We might misunderstand each other or I might be wrong.. -> Since the server never pushed the route "push "route 192.168.1.0 255.255.255.0"" to the client, the client on the lan(192.168.1.0/24) would use  the "wifi interface" when requesting host's in the 192.168.1.0/24 range instead of tun interface (opnvpn adapter). When I added "push "route 192.168.1.0 255.255.255.0"" to the server config, the client now knows it should use the tun interface instead. The reason I thought this could be a bug is because when I configured the server I specified these options(using the wizard): Tunnel Network 10.0.8.0/24 Redirect Gateway checked Local Network 192.168.1.0/24 Because of the "Local Network 192.168.1.0/24" entry I expected "push "route 192.168.1.0 255.255.255.0"" to be present in the server.conf. Any way, things are working and im happy:)

Thnx for the guide it is very clear :). Still can't get it to work. Is there a way to see what rule is blocking communications from clients connected to the OpenVPN server?

Well we have to find out what you have buggered up because it does indeed work for tens of thousands of other people. I guess post your /cf/conf/config.xml in a pm to me. Unfortunately PMs don't allow attachments.

Well I feel stupid. I started to do  traceroute from Diagnostics tab and did a ping test from server located inside the azure network and realized it the traceroute was leaving my network but stopping when it hit Azure. So i logged into Azure and checked my "Local network gateway" and realized that forgot to add the address space of 10.0.12.0/24. Yay its working [image: pic4.png] Also I had to switch the outbound NAT to Manual Outbound NAT rule generation. (AON - Advanced Outbound NAT) with the rules generated.  The order of the outbound NAT are very important to getting it work correctly.

after several more hours of this i have this working the way i required it. my cameras and tv are running on the gateway wan. all other devices are working through the nordvpn tunnel.      this has been an absolute nightmare.  i finally have a good backup to my cloud account of the console config backup… i also feel along the way with the support tickets i have sent to them they have fixed several issues they were having with servers and speed.  as of last night i am getting faster speeds than ever connected. i haven't changed anything but with my pictures of the config its just working better. i hope it stays this way. i ended up canceling my subscription to NORDVPN>  they could not give me the speeds they said were available on any of their servers.  i have those speeds through a difference provider

@Hakon74: Hello. lates guide https://helpdesk.privateinternetaccess.com/hc/en-us/articles/115005760606-Setting-up-a-Router-running-pfSense-Firmware i posted that in the official PIA thread the day it happened.  i feel because of several of my support tickets to them. they no longer suggest using their 256 bit encryption, the above is the ONLY "supported" way of connecting with a openvpn device… i had told them how unhappy i was with the logs i was getting from them(console).  then i switched to nordvpn and that was a whole nother mess.... anyways i am glad its working for you.  these openvpn setups have taken hours of my days trying to get this to work!

the server is working now, solution is missing gateway on WAN interface.

The NAT method is also called masquerading and that puts it in a nutshell. A Windows firewall by default only trusts devices in its own network and with this method it seems that the access comes from its own network segment. To do this is an easy workaround as long as you have no need to determine the source device on the destination device. So, in my opinion, its sufficient for home use, but in a business environment I would prefer the routing method and configure the firewalls to allowing access as needed.

I was struggling with this for a while and nothing i did in "advanced" on the server itself worked. In client specific overrides I chose the correct server, put in the common name from the certificate, and chose tunnel network of 192.168.68.6/24 Now the first (and in my case only) VPN client always gets 192.168.68.6 In the server the tunnel is 192.168.68.0/24. I know that's what Jim said but I am spelling it out so that future googlers (including me probably!) can find it in a more idiot proof form.

thank you for the help :)