Thanks for clarification. That's what I am currently doing killing OpenVPN connection manually from pfsense firewall. But was seeking some auto mechanism that you clarified there is no way for OpenVPN.

After playing around with way too many settings, I finally discovered the solution: 1. Go to System/Advanced/Networking 2. UNCHECK -> Allow IPv6 [  ] All IPv6 traffic will be blocked by the firewall unless this box is checked 3. REBOOT If you don't reboot the changes won't go through for this setting. I'm still shaky on most of this stuff, so I'll leave it to someone else to educate me and others why this worked. P.S. To verify it was this setting I did the following: 1. Reboot pfsense + phone with Allow IPv6 setting CHECKED 2. Verify YouTube app is closed on phone (swipe it away) 3. Open YouTube app, and verify it's taking 10+ seconds to load the main page 4. Change the allow IPv6 setting to UNCHECKED 5. Reboot pfsense + phone 6. Repeat steps 2 and 3, except instead of 10+ seconds it should be a few seconds

@ftass: Did some debugging, haven't really had any impact since the vpn connection has worked even though the gui states not running. It is apparantly the management socket for openvpn (client 5 for me) that refuses connections. [2.1.2-RELEASE][root@pfsense-1.basement2.int]/var/etc/openvpn(24): cat client5.sock cat: client5.sock: Connection refused [2.1.2-RELEASE][root@pfsense-1.basement2.int]/var/etc/openvpn(25): cat client6.sock INFO:OpenVPN Management Interface Version 1 – type 'help' for more info I tried stopping openvpn using the gui but since it seems to be using the management socket for shutting down the client as well this wasn't working. I killed the client manually over ssh and after restarting it everything worked as intended. Seems like openvpn sometimes failes to create the management socket? I think the gui should report failure to shut down the openvpn client if the management socket isn't reachable. Could you elaborate on how you killed the client manually over ssh. I am trying to kill the process as other guys are suggesting using ps aux | grep openvpn and then killing it with kill -9 PIDnumber but it always comes back with "No such process". Thanks for the help

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.