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.

Does not matter. All that means is he has to forward from upstream too. The traffic will still arrive to WAN address:1004. That is what needs to be forwarded. If the upstream router knows about the 192.168.10.55 address he's doing it wrong.

Hi, I saw the option to choose subnets but not a gateway address. Although I'm able to get a connection to the servers using a tun connection, I need to be able to use tap so homeworkers are able to use there VOIP phones. Do you have any other ideas on what I could try? Thank you for your response. Regards, Robert.