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.

Yes I did use the wizard! Found the problem, it was the Protocol setting in the VPN Server.  Was set to 'UDP IPv4 and IPv6 on all interfaces (multihome)' so I changed it to 'UDP on IPv4 only' and it all worked. Thanks for you assistance and have a great Christmas. Greg

What is the network scheme of the local network the remote client is connecting from? 192.168.1.0/24?

My sanitized client config dev tun persist-tun persist-key cipher AES-256-CBC ncp-ciphers AES-256-GCM:AES-128-GCM:AES-128-CBC:AES-256-CBC auth SHA1 tls-client client resolv-retry infinite remote xxxxx.dyndns.org 443 udp lport 0 verify-x509-name "OpenVPN-cert" name auth-user-pass pkcs12 xxxxx-udp-443-me.p12 tls-auth xxxxx-udp-443-me-tls.key 1 remote-cert-tls server

Tunnel network is no 10.8.0.0/24 which should be fine, right? It should be single NAT'd. I only have one NAT rule configured which translates incoming IPs from the WAN to 192.168.1.1. The static IP of the LAN interface. The WAN port is connected to a fritz.box. I noticed that it has a way to big subnet aswell: 10.0.0.0/16 So the WAN port get's it's ip from the fritz.box's DHCP. The LAN interface is configured with as static 192.168.1.1/16 IP?!? Shouldn't this be 192.168.1.1/32? But I don't see any overlapping networks :/ I attached our network (routers are switches in this image). [image: network.jpg] [image: network.jpg_thumb] [image: 2017-12-20-17:04:34-screenshot.png] [image: 2017-12-20-17:04:34-screenshot.png_thumb]

Thanks for the clarification. Didn't see that you need a PKI setup. I'll look into it. Currently it's a shared key environment

@Derelict: I would just remove the entries you do not want there. Double quotation or single quotation characters ("", '') can be used to enclose single parameters containing whitespace, and "#" or ";" characters in the first column can be used to denote comments. –- I have never tried embedding comment there. You are welcome to try, of course. The generated config file will be in /var/etc/openvpn. For the benefit of anyone who might actually care comments SORT OF work. VALID COMMENT ;VAILID COMMENT ;SCREWS UP; #SCREWS UP; Don't know if this is a bug, or if this is the way it is supposed to work, but it makes it difficult to comment out/document things for test purposes.  Two semi-colons on a like cause the parser to chuck it's cookies and OpenVPN client won't start due to a syntax error in the config file. As an aside… with no changes, I haven't had a problem for several days... don't know if this is because of the pfSense Update, or if the conditions for failure haven't yet occurred. I just put in the changes as per the post recommended here: @Derelict: There also appear to be some changes as VPN providers continue to experience growing pains. I found this interesting: https://forum.pfsense.org/index.php?topic=137438.msg754714#msg754714 If I have more problems, I'll post again, and if I remenber, I'll post an update, but no news can be considered to be good news.