Hi I added on Custom options "keepalive 10 20;" on openvpn client and restarted the service, and the openvpn client reconnected via alternate wan (with main wan down). Unfortunately it never reconnect after a pfsense reboot.

@mscaff: you generally never get an OpenVPN provider that can maintain close to 100Mbit/s downstream. Eh, in what part of the world? My VPN provider can max my 150/10Mbps connection on a single thread.

thanks for the reply, but how can this be done for 1 spesific client? i have 3 and all should have static ip

@Derelict: /30: https://forum.pfsense.org/index.php?action=dlattach;topic=129155.0;attach=98690 When you run Peer to Peer SSL/TLS with larger than a /30 subnet on the tunnel network it is considered a PTMP server and you need routes into OpenVPN (Remote Networks in the server) and iroutes to each client (even if there is only one) using Remote Networks in Client-Specific Overrides. When the tunnel network is a /30 it is considered a PTP connection and the iroutes are not necessary. Ah! Interesting! HOLY COW! That was it, that's the key! Thank you - that fixed everything! I saw this: For site-to-site shared key, only a /30 is used, not a /24, even if /24 is specified. but didn't interpret it as clearly as how you explained it above. Thank you! Back to OpenVPN for everything!

Multiple vpn clients are no problem as long as they use different tunnel subnets. Each client has to be assigned an interface after set it up. Just enable the interface, do no IP settings. Then this interface can be used for policy routing.

are you trying to do this?  https://forum.pfsense.org/index.php?topic=128718.0 But Server/Client the other way round? [image: openvpn.png] [image: openvpn.png_thumb]

The issue seems to be that the subnet 0.0.0.0/1 is ignored, but 128.0.0.0/1 is evaluated because….. with IPv4 Remote Network/s = 0.0.0.0/1,128.0.0.0/1 I can ping www.bbc.co.uk PING www.bbc.net.uk (212.58.246.90) 56(84) bytes of data.                                                                                                                              64 bytes from bbc-vip011.cwwtf.bbc.co.uk (212.58.246.90): icmp_seq=1 ttl=54 time=15.0 ms                                                                                              64 bytes from bbc-vip011.cwwtf.bbc.co.uk (212.58.246.90): icmp_seq=2 ttl=54 time=13.7 ms but cannot ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.                                                                                                                                          c^C                                                                                                                                                                                    --- 8.8.8.8 ping statistics ---                                                                                                                                                        3 packets transmitted, 0 received, 100% packet loss, time 2006ms So any IP below 128.0.0.0 is dropped by OpenVPN GET INST BY VIRT: 8.8.8.8 [failed]

This worked for me using IVPN today: https://www.ivpn.net/setup/router-pfsense.html Mulvad setup looks very similar but I haven't tried it: https://www.mullvad.net/guides/using-pfsense-mullvad Has anyone tried to do this with Algo VPN?

check out https://blog.dhampir.no/content/pfsense-as-a-cisco-anyconnect-vpn-client-using-openconnect

The routes you're pushing to the client are messing up the connectivity when the client is on the local LAN or one of the other local networks. Unfortunately there is no way to tell the OpenVPN service to selectively push options based on the client's IP address.

SSSOOOOOOOOOOLLLLLLVVVVEEEEEED!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! GGGGGGGGGGOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALLLLLLLLLLLLLLLLL It was the automatic TLS authentication gen; the key it generated was inconsistent with the .ovpn sent by ExpressVPN. The answer; when you enter info for a new certificate, enter your private key data and save, then go to VPN -> OpenVPN -> Clients -> in the 'Cryptographic settings' section, the first time you create the client it may not have a 'key' box. But save the client and if their is an option to "automatically generate key", uncheck that box. After you save, go back into the client edit and in the 'key' box delete the auto-generated key and replace it, with the one sent to you by the vpn provider (inside the .ovpn file under <tls-auth>). [image: tlskeysettings.PNG_thumb] [image: tlskeysettings.PNG]</tls-auth>

"10.0.0.70 for the VPN going to the external IP of the DR" This is confusing me.. So you have an extended layer 2 via dark fiber that is using the same network 10.0.0/24  See below drawing. Why would you not just use a vpn into location A, and another Vpn into local B.  If you source natted your vpn connection then you be able to access whatever you wanted on your extended vlan no matter what vpn you were connected to..  So if vpn A is down, you just vpn into vpn B. The use of source nat so you either look like .1 or .2 would remove the need of host routing or any sort of hairpin issues..  If you don't want to source nat then your devices on your 10.0.0 network would need host routing to know who to talk to .1 or .2 depending on the tunnel network your using on each vpn connection. [image: extendedvlan-darkfiber.png_thumb] [image: extendedvlan-darkfiber.png]

Nobody needs to use those auth user/pass files any more. Just use the username and password in the gui config. Perfect example of old internet "walk throughs" not being updated with current information.

If that is the case then it could not locate the port forwards used to redirect the VPN to localhost. It tries to locate port forwards that target the OpenVPN binding, so if it's bound to Localhost on port 1194, the port forward target has to be 127.0.0.1 port 1194.

Thank you. Pkg_mgr_settings.php I changed the settings in the file. The problem's been solved.

Well, I found what I had missed. Having done this before (with linux) I was comfortable that I had overlooked something and had to find it. One little sentence. "Do this on both routers . . ." Once I discovered that, setup firewall rule to allow any traffic on my "site b" router and everything started to work. Now that IPsec is working I can get to work setting up OpenVPN (my end goal) as I would prefer it over IPsec. Easy enough to temporarily disable IPsec and enable OpenVPN to test. Thanks for reading and commenting. Believe it or not, it helped.

I'm not 100% sure on what you are trying to do. I think you are trying to use a Windows machine as an OpenVPN Access Server, and then connect to it from a Linux client, behind a pfSense firewall? Maybe start here: http://blog.bobbyallen.me/2016/02/07/setting-up-openvpn-server-on-windows-2012-r2/ With a tutorial (have not used it, found from random Google search) to set up OpenVPN Access Server on a Windows machine. After that, if your Linux machine is behind pfSense, you can just NAT (Firewall > NAT > Port Forward) port 1194 (or whatever port you specified) to the Linux machine and connect like that. This would be a 1:1 connection "through" pfSense.

Derelict - that was it!.  Previously my OpenVPN sessions were just internal so there was a PASS all rule.  Removed this and now i can see what I was missing. Thank you!

Works like this for me: Single OpenVPN road-warrier server instance bound to Localhost. Port forward on both WAN-1 and WAN-2 to the same OpenVPN localhost instance. Add appropriate FW rules to allow forward VPN traffic Separate DDNS entries for each WAN. Then In the Client config file, simple add two entries for the VPN host connections, i.e. remote wan1.ddns.com 1194 tcp-client remote wan2.ddns.com 1194 tcp-client Note: I used TCP for my OpenVPN, because UDP didn't work well in my scenario, but UDP should also work. This way when your two WAN gateways switch from High to Low tier, the VPN clients should reconnect to the second DDNS.  Only downside is they will remain connected to the Low tier GW when the high tier comes back online, however when they disconnect & reconnect later they will get the high tier as it's the first in the client list.