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.

There were other unusual characters in passwords that were fixed up over the last few months. Personally I never put thse odd characters in passwords because I know there will be apps that don't work with them, and I will be on someones computer with a European keyboard variant and I will struggle to find the character anyway ;) Make sure you are on the latest pfSense and latest OpenVPN client, then it is probably worth reporting in redmine.pfsene.org to see if something can be done to fix it. < and > are not that weird.

If you have a reliable WAN at each end with a short/low latency path then it should work. I am in Nepal and we don't have anything like that :) If it feels like restarting then there will be some interruption to users. For the majority of users that use TCP-based apps, they will just see their app stall for a bit and then keep going, because TCP will retransmit packets that got lost while the VPN was restarting.

On the Linux server you could add static routes to these other subnets, presumably pointing to the pfSense router on your LAN from where the SSH comes. Or on pfSense on LAN put an Outbound NAT so the SSH from another subnet gets translated to pfSense LAN address as it goes out to the Linux server. Then the Linux server will think you are coming from the local LAN, and should answer fine.