Longtime pfSense User here. Sure would be nice, though ::hint:: ::hint:: Can you give us any insight as to whether or not it is on the radar and if so how long it might be? (Given OPNsense has it already) [thanks, Tom!]

@spacebass Move WebGUI to some other port to free up 443?

@jknott I have a productive environment with external networks 10.5.x.0/24 with x=1..253. For a network 10.5.x.0/24, the corresponding external VPN client uses a tunnel IP 10.8.1.x/24: E.g., the VPN client for the external network 10.5.1.0/24 has a TAP interface with 10.8.1.1/24, the external network10.5.2.0/24 has a TAP interface with 10.8.1.2/24 and so on. 10.8.1.x with x=1..253 is reserved for external networks. For my setup the VPN server uses the last available IP 10.8.1.254 for the tunnel network because the first one is already in use. OpenVPNs' --server directive simplifies the setup and sets the server IP to .1. However, there is no reason that it has to be the first available IP and not to use a custom setup.

It's a video, so install Youtube. Then go to the Netgate channel. You'll find many OpenVPN video's. Like this one : Configuring OpenVPN Remote Access in pfSense Software edit : the video hidden, look : [image: 1625478974629-5b4bce8e-95a0-4636-a4d6-55f2c4da1534-image.png] It's on the first link proposed !!!!!!

@rafael-3 Thank you Rafael. I will give that a try.

@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