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.

hi, can you pleas post some screenshots for dummies (ie me)  ;) ? Thx. EDIT: in outbound nat rules i create this rule, but still cant access pc that dont have default gateway setup to openvpn server pfsense box: @robm: I am configuring OpenVPN on pfSense to allow remote users 'dial-in' type VPN access (this is to replace legacy PPTP connections). This is all working as expected, apart from access to LAN devices is only possible if the LAN device either the has the pfSense LAN IP set as the default gateway, or a route is added for the 'tun'/OpenVPN IP range(s). For legacy reasons the pfSense won't be the default gateway for most LAN devices (at least not initially). To work around this I have created a Outbound NAT rule on the LAN interface with a Source of my 'tun'/OpenVPN range with a NAT address of the LAN address. This appears to work (at least under minimal testing). Any reason that this should be not used, or an alternate solution? [image: Sn%C3%ADmka.PNG] [image: Sn%C3%ADmka.PNG_thumb]

I don't know if that is possible. However, you can bind openvpn to the LAN carp ip and forward it. This ip is available for both, master and slave.

ram is not an issue … openvpn is very cpu intensive. you'll have to see how much throughput you'll get.

I have plenty of OpenVPN site-to-site links on 2.2.2 and they work fine just like they did in 2.1.5 - put the right subnets in Tunel, Local and Remote Network/s boxes on server and client, make sure the firewall rules on LAN and OpenVPN at both ends allow the relevant traffic - that is all there is to it. When I setup a new office it takes only a couple of minutes to bring up OpenVPN site-to-site links back to our main offices, it really does work.

Sorry, I don't remember who it was. I searched a lot here and I don't have time to look for this thread in my browser history. Anyway, I found the solution and I don't care for this wrong information any more. That's the nature of forums at the internet. Not all information you find is correct  ;)