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?

Snímka.PNG
Snímka.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  ;)

The windows client yes.  I'd assumed you were talking about pfsense as client.

@Derelict:

Should get you going OK.  Note that this connection will be routed so broadcast discovery will not work.

Two errors in the video.  The WAN rule on prirouter only needs to be UDP 1194, not TCP/UDP and the WAN rule on secrouter is unnecessary and can be eliminated completely.

Thank you for your help. Actually broadcast is exactly what I want the most. Furthermore, I followed https://forum.pfsense.org/index.php?topic=46984.0 and it seemed to be covering what I am looking for, but how can I use it as point to point (pfsense to pfsense), rather than pfsense directly to the client PC?

Found my answer on below thread

https://forum.pfsense.org/index.php?topic=81291.msg443963#msg443963

IPv4 tunnel network should probably be optional also because you might be doing pure IPv6, and in that case you would put an IPv6 tunnel network but no IPv4 tunnel network.
The validation is in /usr/local/www/vpn_openvpn_server.php
Look for:

if ($pconfig['dev_mode'] != "tap") { $reqdfields[] = 'tunnel_network'; $reqdfieldsn[] = gettext('Tunnel network'); } else { ...

That makes tunnel_network a required field.