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.

Fixed my problem by unchecking the block outside dns button in settings on Torguard app, now works as expected.

Tunnel Network is 10.0.8.0/24 Pfsense gateway 192.168.1.1/24 client gets 10.0.0.8.2

My OpenVPN client configuration on a freshly installed FreeBSD 10.3 and openvpn 2.3.14 works fine. It is unfortunate that this does not work on pfSense :(

You need a Phase 2 definition on the IPsec tunnel that covers the OpenVPN subnet going to the remote IPsec network.