Yes, I find it wierd behavior. But the device is otherwise good - and this has to be a one device environment. Asus AC-55U. It's got proper syslogging, good wifi and good 4G with antenna support. Compared to others, this is enterprisey. And comes with a OpenVPN -client built in. The specs with just one device is pretty unbeatable. I hate the NATtin though, and hope to find some obvious misconfiguration being the reason.

That is what happens on pfsense default "Allow all" policy and when the routing is properly done. So congratulations! To block the traffic I did: First I added one "quick" floating rule permiting my IP address to pass everything (like an antilock out rule to access the webgui). Secondly I  added another "quick"  floating rule bellow it to block all ipv4/6 traffic from all the subnets that have routes on the server, with every interface selected on this rule.  I did this using an alias with every subnet that I which to block. Thirdly, above the previous rule I created another  "quick" floating rule allowing only the desired subnets, or even single ips, to pass. All interfaces maintained their "allow all" rule. From the moment you add a floating "quick" rule to block it all, you are bound to use floating "quick" rules above the "block all" to permit access to anything you need communicating. That is how I did it.

my apologies. The latency was due to a faulty internal connection on my side, which coincided to the exact minute of testing the vpn. such is the life on IT Cheers

<= bump => Hopefully it's something obvious. My second attempt was with pfSense 2.3.2 (2 Nics, 1 assigned WAN, 1 assigned 'LAN') I have openvpn listening on the LAN adapter.  I have created a nat rule to allow vpn connections to the lan (WAN,UDP,,,WAN ADDRESS,1194,lan adapter ip, 1194)… however who shows wan adapater. I have setup other servers running OpenVPN (off an Ubuntu box) and the server logs are as I would expect (client IP shows). ==================================================================================================== Well if anyone stumbles upon this, here is what I did to fix this: *Automatic nat to manual nat *Removed WAN nat entries for my tunnel network (left lan... still need to validate traffic is going through my lan interface) *On Azure, create an inbound rule on NSG allowing my tunnel *On Azure, create a route table, tunnel next hop = pfsense (associate to the subnet)

There is no save default button at the bottom.  Thanks though.

No you can use the same certs if you want..

up

OK, so with all my remote lans being on different subnets can I run a single server and a client at each end? The block access to the lan from the remote using rules. Would that work?

You're looking for a VPN-bridge: http://sclabs.blogspot.co.at/2012/05/openvpn-bridge-with-pfsense-201.html That's not well supported and it's not recommended: https://doc.pfsense.org/index.php/OpenVPN_Remote_Access_Server#OpenVPN_Client_Bridging Some guys here who tried that got no luck with it. It's better to do routing with a different tunnel subnet.

Thank you, problem solved  :)

As long as each client has a different certificate it looks like that should work. If you gave the same certificate to everyone then it would only work for one at at time.

Would have to be a false positive. It is a self-extracting executable that isn't signed, which some paranoid systems may flag. I doubt it's that sophisticated, but it could also be flagging the out-of-date OpenSSL in the out-of-date OpenVPN binary you'd have there. The export package for 2.2.x is not being maintained, use pfSense 2.3.x.