Right I have found the issue. They are VMware installed and I didn't realise that promiscuous mode needed to be enable on the interface of the VMware side. You will also need forged transmits on.

No pushing of gateways is required, that gets handled automatically when the client connects to the OpenVPN server. You can watch the process in action. Go to the OpenVPN client icon, rgt-click->Edit Config then add the line "Verb 5" to the end of the config file and save it. Reconnect the client to the OpenVPN server and "View Log" on the client after it connects. You'll have a whole bunch of excess verbage, but near the end you'll see some lines like: "C:\Windows\system32\route.exe ADD 192.168.x.x MASK 255.255.255.0 10.x.x.x" These lines execute the Windows ROUTE command to tell your client how to send traffic to the OpenVPN server's network. What subnets are you now using for: pfSense LAN? OpenVPN tunnel? Remote PC's LAN? These three items must all be unique networks as we said earlier.

@Derelict: Your rule on OpenVPN was TCP only.  Ping is not TCP, it's ICMP.  Many protocols are not TCP. Wow.  I must have looked at that rule and compared like 10 times and still missed that.  Yesterday was not my day.  I guess 12 hours of upgrading everything on my entire home network took a toll on me. Thanks for that catch.

Thanks so much for the answer. Just what I needed!

This is my settings for «normal» openvpn client. LAN -> OpenVPN client -> OpenVPN gateway -> OpenVPN interface. [image: thumb.png] Make this a rule, but for OPT1. Maybe this will help you.

I made a virtual machine for the test (84,4 МБ). Start VirtualBox. File -> Import -> pfSense.ova. Start VM pfsense. After start go to 192.168.1.10 Login admin Pass pfsense Menu VPN -> OpenVPN -> Client. The settings in the screenshot. [image: thumb.png] An IPv4 protocol was selected, but the selected interface has no IPv4 address. How fix this error?

disabling gateway monitoring fixed the problem. I guess cable is just variable and not clean.

Thank you dr41 and doktornotor forgot to do that. That at least resolves the error in the OpenVPN status window However For some reason it still is an unidentified network with no internet or my "home" network access. I have a bridge in my pfsense config so I was wondering if the vpn server needs to be in the bridge as an enabled device.

No such thing there.

I have just used a road-warrior connection with SSL/TLS+User Auth to both a 2.1.5 and a 2.2.2 system. So it does work. I am using OpenVPN Manager on Windows 7 and config produced by the OpenVPN Client Export package. For me, it "just works". TLS key negotiation failed to occur within 60 seconds (check your network connectivity) That message usually means the client is simply not reaching the server - FQDN used by the client does not resolve to the proper server IP, server is not listening on the port… Post your server settings, what client you are using, how you installed on the client.

What interface are those rules on?  And can we see the full set of rules.  And screenshot of your firewall log vs that text would be much easier to read.

Hmm.  Works fine for me.  What are you exporting to?

I ended up using 192.168.1.0/24 as the tunnel, and 192.168.0.0/22 as the ip4 networks. And then NAT'd that /24 to that /22 on the LAN interface as suggested. 192.168.0.0/22 includes 4 "/24" subnets: 192.168.0.0/24 192.168.1.0/24 192.168.2.0/24 192.168.3.0/24 So it overlaps with the tunnel 192.168.1.0/24 That is not going to be a happy thing. As you say, you can "completely redesign it from the bottom up using more thought out networks".

Was there a confirmed solution for this?  I'm having the same issue with T46G ever since upgrading to from 2.1 to 2.2.  I can also add that it does actually connect to the vpn when connecting from the LAN side, but not from the WAN side.  What's even more confusing is that I can connect with some different clients, such as OpenVPN connect on Android, while getting similar failing results with other phones such as a SNOM 720.  The sip phones all seem to run various versions of OpenVPN 2.2 or 2.1.  These all did work prior to the 2.2 upgrade. ** Edit CA and certs are SHA1

Outbound NAT rule on Interface Opt1 Source being 10.0.2.0/24 Destination being any NAT address is 192.168.1.0/24 I just noticed that. You should not need any Outbound NAT going to OPT1. And in any case you should be NATing that to "Interface Address" - forcing the NAT to 192.168.1.0 would break things because that is the base subnet address and likely will not work. OPT1 is an ordinary LAN-style interface here - do not put any upstream gateway.

That is not a fatal error. If that's all you see in the logs, odds are the server is not receiving the connection. Check the WAN firewall rules, firewall logs, OpenVPN logs from both sides, etc. Show a bit more detail and perhaps the problem can be solved.