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 :)

Dude it's UDP not TCP (UDP is the preferred protocol for OpenVPN). You can't port scan for it. What do the server logs say? Run a packet capture like I said. Make a connection attempt. If you see traffic, check the logs for why it failed. If you don't you need to see why it is not arriving from outside.

Try adding this line to Advanced VPN > Server config directives; push "route-metric 1000" And save settings and update running servers. Undo the change you made to your wifi interface and try connecting and see what happens.

The key direction is in fact included in the config file, so I guess this is a bug in Gnome's Network Manager import code.

Nope. Figure out how to route the traffic instead.

Check "Don't pull routes" and policy route LAN traffic to the VPN gateway. Or, leave "Don't pull routes" unchecked and policy route Wifi out the WAN gateway.