OpenVPN Gotchas for upgrade to 2.4?
-
Are there any gotchas or precautions that need to be taken with regard to OpenVPN connections before upgrading to 2.4? I have site-to-site OpenVPN connections and multiple client OpenVPN connections (in a gateway group) to PIA that I want to ensure will remain active after an upgrade.
-
From my point of view, this is a very valid questions. I have two sets of HA/CARP pfSense devices with OpenVPN connections in between (Supermicro C2758) plus a mobile device (PC Engines APU). I did upgrade the mobile device frist, which has an OpenVPN client function. That does work without issues. Then, I upgraded a backup device of my main pfSense firewalls. Thereafter, none of the OpenVPN servers contained therein did work - neither site to site nor remote access. I did disable NCP. Nevertheless, the logs are not telling. An example is (repeating all the time):
Oct 13 23:25:07 openvpn 72405 Server poll timeout, restarting
Oct 13 23:25:07 openvpn 72405 SIGUSR1[soft,server_poll] received, process restarting
Oct 13 23:25:07 openvpn 72405 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
Oct 13 23:25:07 openvpn 72405 Preserving previous TUN/TAP instance: ovpns2
Oct 13 23:25:07 openvpn 72405 UDPv4 link local (bound): [AF_INET]192.168.1.79:1195
Oct 13 23:25:07 openvpn 72405 UDPv4 link remote: [AF_UNSPEC] -
If you have any "tun-mtu" config in the custom config box, remove it before upgrading. The new version of openvpn in 2.4 does not recognize it and instead of ignoring it, it completely prevents openVPN from starting until it is removed
-
In all of the various testing and 2.4 installs I've done, I have yet to see any OpenVPN connection fail that was upgraded. Even 2.4<->2.3 connections are fine as long as you don't set any options on the new 2.4 side that are not compatible with 2.3, which wouldn't be an upgrade problem.
It's always possible that something a user put in advanced/custom options might cause an issue because it's deprecated or doesn't work like it used to, but we don't have a reliable way to handle that without possibly breaking the VPN which could happen anyway with the bad directive.
-
FWIW, my VPN continues to work, but it was just a simple "road warrior" VPN, with nothing fancy.
-
At least two of us have had some pretty bad glitches with OpenVPN after the upgrade to v2.4. In my case it required restoring two pfsense installs because of broken OpenVPN and manually changing the configuration of the key bits to 256 (as it was before) because the install chose to add 128 along with 256 as an option (probably the risk is minimum, but if an organization has to comply to any requirement that sets 256bits as a minimum, the upgrade auto-adds 128, the connection still works and you don't notice you could have problems).
If you depend on OpenVPN and plan to upgrade to v2.4 I'd say be sure you can restore quickly on all the sites if anything goes wrong. (that rule should be valid for any upgrade anyway)
Check here if you can:
https://forum.pfsense.org/index.php?topic=138073.0 -
All of mine worked without any modification after 2.3.4_1 to 2.4-RC then 2.4.0-RELEASE. Two OpenVPN clients and an OpenVPN Remote Access server.
The VM lab in the diagram in the sig saw countless 2.4-BETA/RC/RELEASE upgrades. OpenVPN always worked without touching it.
-
I have some issues with openvpn clients on the firewall itself as well after upgrading to 2.4
The configuration I have is based on the 2.3 version of this guide (he has it now updated to 2.4): https://nguvu.org/pfsense/pfsense-multi-vpn-wan/
I use two client connections to AirVPN combined in a Gatewaygroup, and it was wording fine on 2.3
In 2.4 I can see the connection with AirVPN is setup ok, but it seems the creation of the interface is giving issues:/sbin/ifconfig ovpnc1 10.4.94.253 10.4.0.1 mtu 1500 netmask 255.255.0.0 up
ifconfig: ioctl (SIOCAIFADDR): File exists"Solved" it for this moment by disabling one of the clients, then it seems to work agin for that one client.
-
What is the ifconfig line logged from the other client when that happens?
-
starting up first client:
Oct 15 13:16:53 openvpn 49578 Initialization Sequence Completed Oct 15 13:16:53 openvpn 49578 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Oct 15 13:16:53 openvpn 49578 /usr/local/sbin/ovpn-linkup ovpnc1 1500 1558 10.4.94.253 255.255.0.0 init Oct 15 13:16:53 openvpn 49578 /sbin/route add -net 10.4.0.0 10.4.0.1 255.255.0.0 Oct 15 13:16:53 openvpn 49578 /sbin/ifconfig ovpnc1 10.4.94.253 10.4.0.1 mtu 1500 netmask 255.255.0.0 up Oct 15 13:16:53 openvpn 49578 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Oct 15 13:16:53 openvpn 49578 TUN/TAP device /dev/tun1 opened Oct 15 13:16:53 openvpn 49578 TUN/TAP device ovpnc1 exists previously, keep at program end
And second client:
Oct 15 13:20:11 openvpn 57957 Initialization Sequence Completed Oct 15 13:20:11 openvpn 57957 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Oct 15 13:20:11 openvpn 57957 /usr/local/sbin/ovpn-linkup ovpnc2 1500 1558 10.6.1.15 255.255.0.0 init Oct 15 13:20:11 openvpn 57957 /sbin/route add -net 10.6.0.0 10.6.0.1 255.255.0.0 Oct 15 13:20:11 openvpn 57957 /sbin/ifconfig ovpnc2 10.6.1.15 10.6.0.1 mtu 1500 netmask 255.255.0.0 up Oct 15 13:20:11 openvpn 57957 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Oct 15 13:20:11 openvpn 57957 ioctl(TUNSIFMODE): Device busy (errno=16) Oct 15 13:20:11 openvpn 57957 TUN/TAP device /dev/tun2 opened Oct 15 13:20:11 openvpn 57957 TUN/TAP device ovpnc2 exists previously, keep at program end
Hmmm, both connections active (I can also see in the AirVPN site), but GW for VPN1 is now down
-
and after closing both clients (client is disabled) and also setting loglevel back to 3 (from 6 above), waiting a few minutes and enabeling one of the clients again, I now get this error:
Oct 15 13:49:27 openvpn 18958 MANAGEMENT: CMD 'status 2' Oct 15 13:49:27 openvpn 18958 MANAGEMENT: Client connected from /var/etc/openvpn/server3.sock Oct 15 13:49:23 openvpn 45622 Exiting due to fatal error Oct 15 13:49:23 openvpn 45622 FreeBSD ifconfig failed: external program exited with error status: 1 Oct 15 13:49:23 openvpn 45622 /sbin/ifconfig ovpnc1 10.4.94.253 10.4.0.1 mtu 1500 netmask 255.255.0.0 up Oct 15 13:49:23 openvpn 45622 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Oct 15 13:49:23 openvpn 45622 TUN/TAP device /dev/tun1 opened Oct 15 13:49:23 openvpn 45622 TUN/TAP device ovpnc1 exists previously, keep at program end Oct 15 13:49:23 openvpn 45622 Incoming Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication Oct 15 13:49:23 openvpn 45622 Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key Oct 15 13:49:23 openvpn 45622 Outgoing Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication Oct 15 13:49:23 openvpn 45622 Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key Oct 15 13:49:23 openvpn 45622 OPTIONS IMPORT: route-related options modified Oct 15 13:49:23 openvpn 45622 OPTIONS IMPORT: --ifconfig/up options modified Oct 15 13:49:23 openvpn 45622 OPTIONS IMPORT: compression parms modified Oct 15 13:49:23 openvpn 45622 OPTIONS IMPORT: timers and/or timeouts modified Oct 15 13:49:23 openvpn 45622 Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS]) Oct 15 13:49:23 openvpn 45622 Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS]) Oct 15 13:49:23 openvpn 45622 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.4.0.1,comp-lzo no,route-gateway 10.4.0.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.4.94.253 255.255.0.0' Oct 15 13:49:23 openvpn 45622 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1) Oct 15 13:49:22 openvpn 45622 [server] Peer Connection Initiated with [AF_INET]213.152.161.9:443 Oct 15 13:49:22 openvpn 45622 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA Oct 15 13:49:21 openvpn 45622 VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org Oct 15 13:49:21 openvpn 45622 VERIFY EKU OK Oct 15 13:49:21 openvpn 45622 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Oct 15 13:49:21 openvpn 45622 Validating certificate extended key usage Oct 15 13:49:21 openvpn 45622 VERIFY KU OK Oct 15 13:49:21 openvpn 45622 VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
Edit: After a reboot of the pfsense-server the single client vpn connection is working again
-
The OpenVPN issue after upgrading to 2.4 I did report turned out to be a simple misconfiguration issue: I have multi-WAN and 2 servers with CARP. To get the OpenVPN servers available on both WANs, I used to NAT to LAN. Now, I do NAT to localhost knowing that I could have OpenVPN listen on multiple interfaces also by now. In using NAT to LAN initially, I did copy an alias from the main server to the backup server. Then, the alias on the backup server did point to the CARP VIP in the main server which could not work.
-
I have some issues with openvpn clients on the firewall itself as well after upgrading to 2.4
The configuration I have is based on the 2.3 version of this guide (he has it now updated to 2.4): https://nguvu.org/pfsense/pfsense-multi-vpn-wan/
I use two client connections to AirVPN combined in a Gatewaygroup, and it was wording fine on 2.3
In 2.4 I can see the connection with AirVPN is setup ok, but it seems the creation of the interface is giving issues:/sbin/ifconfig ovpnc1 10.4.94.253 10.4.0.1 mtu 1500 netmask 255.255.0.0 up
ifconfig: ioctl (SIOCAIFADDR): File exists"Solved" it for this moment by disabling one of the clients, then it seems to work agin for that one client.
I found the solution for my problem :)
In the 2.3 version of the guide I mentioned there was a monitor IP configured for each VPN GW. Comparing them with the 2.4 version of the guide he published now, there was no GW monitor IP. After removing them both stay active.
It is either this or the fact I updated pfblockerng to the latest version because of the infamous 502 bad gateway issue, which I changed first before I changed the VPN GW configuration.