Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    OpenVPN Gotchas for upgrade to 2.4?

    OpenVPN
    8
    13
    2.4k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J
      JimPhreak
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • M
        michaelschefczyk
        last edited by

        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]

        1 Reply Last reply Reply Quote 0
        • F
          fohdeesha
          last edited by

          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

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            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.

            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            1 Reply Last reply Reply Quote 0
            • JKnottJ
              JKnott
              last edited by

              FWIW, my VPN continues to work, but it was just a simple "road warrior" VPN, with nothing fancy.

              PfSense running on Qotom mini PC
              i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
              UniFi AC-Lite access point

              I haven't lost my mind. It's around here...somewhere...

              1 Reply Last reply Reply Quote 0
              • S
                sgorbach
                last edited by

                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

                1 Reply Last reply Reply Quote 0
                • DerelictD
                  Derelict LAYER 8 Netgate
                  last edited by

                  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.

                  Chattanooga, Tennessee, USA
                  A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                  DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                  Do Not Chat For Help! NO_WAN_EGRESS(TM)

                  1 Reply Last reply Reply Quote 0
                  • H
                    HeMaN
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 0
                    • DerelictD
                      Derelict LAYER 8 Netgate
                      last edited by

                      What is the ifconfig line logged from the other client when that happens?

                      Chattanooga, Tennessee, USA
                      A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                      DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                      Do Not Chat For Help! NO_WAN_EGRESS(TM)

                      1 Reply Last reply Reply Quote 0
                      • H
                        HeMaN
                        last edited by

                        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

                        1 Reply Last reply Reply Quote 0
                        • H
                          HeMaN
                          last edited by

                          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

                          1 Reply Last reply Reply Quote 0
                          • M
                            michaelschefczyk
                            last edited by

                            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.

                            1 Reply Last reply Reply Quote 0
                            • H
                              HeMaN
                              last edited by

                              @HeMaN:

                              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.

                              1 Reply Last reply Reply Quote 0
                              • First post
                                Last post
                              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.