No, it's always been around 75ms. We have a roadwarrior in Site4 that ALWAYS had this issue with pulling files from Site1, so months ago I configured a separate openVPN server at Site1 for them using TCP and a different port. I just switched Site2 to use the TCP openVPN server and now I can pull large files without issue, albeit much slower then UDP. Just can't figure out why this Site2 UDP problem started now, but it seems to be latency induced.?.?

OpenVPN is more flexible in routing, NAT, etc. IPsec generally performs better at higher speeds. Both will securely transport multiple subnets to and from the mothership.

Problem solved / workaround… I had been using the setting to store the key in the Windows Certificate Manager, instead of local files. This seems to work on PCs where the local user is in the domain, but not when the user is logged on with a local account. I changed the settings in the package manager on the pfSense to just use local files and et voilá it connected first time! So there seems to be some problem with the way that the Windows Certificate Manager and OpenVPN are interacting, when local account name doesn't match the VPN login (we use RADIUS on the pfSense to authenticate users). Once the name matches, the error about the exired certifivate goes away, but it still can't connect (server log says that the key was not transmitted / "TLS Error: cannot locate HMAC in incoming packet from [AF_INET]". Once OpenVPN is configured to use local certificate files, instead of the Windows Certificate Manager, there are no errors and OpenVPN can connect without problem. Not 100% ideal, but at least we can move forward with implementing pfSense now.

Bump…does no one have any ideas here?  Surely this is possible right? :)

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.