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  ;)

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.

Hi doktornotor, it succeeded: before I tried the same approach, but due to the concurrent presence of another problem (the missing change in depth, I suppose) I thought it was wrong… now it works. Thanks a lot, Diego

I should be doing this in the next week or so, if I do my part right the next post I make on this will be a successful-themed one!

Found great help on redit…  I suggest people go there.

Nice work Phil. Your changes works and the generated config now selects the IPv6 CARP interface address. Will make a bug report during the afternoon.

What are your pfsense server settings?  I'd love to see that server config page from pfsense to get an idea what you are doing wrong.