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.

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