@mrito Jul 2 12:41:01 openvpn 43855 ip:33556 TLS Error: TLS handshake failed Jul 2 12:41:01 openvpn 43855 ip:33556 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Jul 2 12:39:04 openvpn 66093 Initialization Sequence Completed Jul 2 12:39:04 openvpn 66093 UDPv4 link remote: [AF_UNSPEC] Jul 2 12:39:04 openvpn 66093 UDPv4 link local (bound): [AF_INET]127.0.0.1:44441 Jul 2 12:39:04 openvpn 66093 /usr/local/sbin/ovpn-linkup ovpns3 1500 1622 10.1.1.1 255.255.255.0 init Jul 2 12:39:04 openvpn 66093 /sbin/ifconfig ovpns3 10.1.1.1 10.1.1.2 mtu 1500 netmask 255.255.255.0 up Jul 2 12:39:04 openvpn 66093 TUN/TAP device /dev/tun3 opened Jul 2 12:39:04 openvpn 66093 TUN/TAP device ovpns3 exists previously, keep at program end Jul 2 12:39:04 openvpn 66093 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Jul 2 12:39:04 openvpn 66093 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Jul 2 12:39:04 openvpn 66093 WARNING: experimental option --capath /var/etc/openvpn/server3/ca Jul 2 12:39:04 openvpn 66093 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Jul 2 12:39:04 openvpn 65856 library versions: OpenSSL 1.1.1k-freebsd 25 Mar 2021, LZO 2.10 Jul 2 12:39:04 openvpn 65856 OpenVPN 2.5.1 amd64-portbld-freebsd12.2 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Apr 5 2021 Jul 2 12:39:04 openvpn 65856 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set. In firewall port is added ... to allow ... and this problem is after i update to 2.5.1 Tnx very much i use Mode: Peer to Peer ( SSL/TLS )

i use 3 servers with pfsense 1 is server-vpn 2 is client-vpn 3 client-vpn all have installed pfsense and use Mode: Peer to Peer ( SSL/TLS ) and after update VPN disconected and no connect again ... all have TUN option enabled. Jul 2 12:51:36 openvpn 20529 92.84.56.226:59685 TLS Error: TLS handshake failed Jul 2 12:51:36 openvpn 20529 92.84.56.226:59685 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Jul 2 12:49:29 openvpn 20529 Initialization Sequence Completed Jul 2 12:49:29 openvpn 20529 UDPv4 link remote: [AF_UNSPEC] Jul 2 12:49:29 openvpn 20529 UDPv4 link local (bound): [AF_INET]127.0.0.1:44441 Jul 2 12:49:29 openvpn 20529 /usr/local/sbin/ovpn-linkup ovpns3 1500 1622 10.1.1.1 255.255.255.0 init Jul 2 12:49:29 openvpn 20529 /sbin/ifconfig ovpns3 10.1.1.1 10.1.1.2 mtu 1500 netmask 255.255.255.0 up Jul 2 12:49:29 openvpn 20529 TUN/TAP device /dev/tun3 opened Jul 2 12:49:29 openvpn 20529 TUN/TAP device ovpns3 exists previously, keep at program end Jul 2 12:49:29 openvpn 20529 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Jul 2 12:49:29 openvpn 20529 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Jul 2 12:49:29 openvpn 20529 WARNING: experimental option --capath /var/etc/openvpn/server3/ca Jul 2 12:49:29 openvpn 20529 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Jul 2 12:49:29 openvpn 20366 library versions: OpenSSL 1.1.1k-freebsd 25 Mar 2021, LZO 2.10 Jul 2 12:49:29 openvpn 20366 OpenVPN 2.5.1 amd64-portbld-freebsd12.2 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Apr 5 2021 Jul 2 12:49:29 openvpn 20366 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set. In dashboard i see this in VON category: UNDEF IP:30965

@viragomann In order not to be misunderstood, I'm talking about running two OpenVPN servers on a unique pfSense box. This one which has a static public IP. For instance you run one OpenVPN server on port 1194 for the branches and a second one as site-to-site on port 1195 for the client in the main location. Why didn't i think of this?! Didn't know, that this works that easy but it's a good point, thank you.

@joshucha pfSense Plus now has a .ovpn client import package.

I'm coming back to this as this was not resolved and would like this to be taken care of. I thought instead of "saving" the vpn configuration on the main server I'd try rebooting the main firewall instead to see if that would rectify the problem. It didn't. It appears that when the main internet drops and the firewall switches to the "backup", there is a VPN setting that is getting corrupted (either gets hung up on the switch and doesn't switch back, or some other setting that gets flipped, but gets reset when I click save). I have attached the server VPN log Server VPN.txt and client VPN log Client VPN.txt from 6pm to 8am (outage was 7:30pm to 8:30pm) I am also attaching the main server log Server Main Log.txt I noticed this line OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WANGW Is this not reloading correctly? Thanks in advance...

I also have an OpenVPN site to site tunnel between this pfsense box and another. I get the same symptom set on both pfsense boxes.

@viragomann I indeed missed that part of the docs. Thank you VERY much!!

Update: I needed a state reset for the block rules to work. I am now blocking connections to ovpn from the lan so that is a solid workaround. I still would like to know what changed.

In case anyone has the same problem, this is what I ended up getting back from Netgate support: "Unfortunately it's not supported to have multiple OpenVPN TAP servers bridging to the same interface"

@viragomann I'll have to try again with Wireshark running on the VPN client, but the command prompt on that PC was showing a timeout. At first glance, it seems to be an issue of translating back from the LAN subnet to the VPN Tunnel subnet.

Yes Sir! Many thanks for the speedy response. Kind regards, jB

@bafcharles what version of pfS ? maybe deprecheated version best guess go and update your box to 2.5.1 brNP

As mentioned already you need correct routing, and you would need correct rules in your openvpn interface on both ends.. Pretty sure it default to any any. Another mistake common, is policy routing being done with would shove traffic out the wrong interface and not allow pfsense to send traffic out the vpn interface. Another common issue is host firewall on where your trying to go, etc.

You can already get lport 0 by setting the option to randomize the local port, though I can't recall off the top of my head if that is the default. I don't think it has a way to set nobind. If it doesn't set that by default, we should probably update the package to work that way and use nobind.

@bcruze said in OpenVPN 2.5 released - Overview of changes: Did you update Pfsense somehow? No, I just used the new Windows-Client with the Server on pfSense.

Thanks to viragomann, the problem is solved. The problem is that the default gateway for devices in the client lan is not pfSense, we need to setup NAT mapping as a work around. Really appreciate the help @viragomann !