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

    OpenVPN network table missing data after upgrade from 2.6.0 to 2.7.2

    Scheduled Pinned Locked Moved General pfSense Questions
    19 Posts 3 Posters 1.4k Views
    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.
    • E
      enrilor
      last edited by enrilor

      PFSENSE3.PNG

      Same problem, after update from 2.6.0 to 2.7.0 vpn_network_table lose all openvpn CSO

      I also get this error after upgrade

      PHP_errors.log.TXT

      pfsense4.PNG

      1 Reply Last reply Reply Quote 0
      • V
        viragomann @enrilor
        last edited by

        @enrilor
        I didn't say, that restarting the server would magically solve your issue.
        The goal is, that OpenVPN adds the routes to the systems routing table on startup, and there are any problems a record in the OpenVPN log would be added with details. This could help to narrow down the issue.

        E 1 Reply Last reply Reply Quote 0
        • E
          enrilor @viragomann
          last edited by

          @viragomann
          Feb 20 19:56:08 openvpn 8555 canneto-mikrotik/x.x.x.x:53913 MULTI: Learn: 192.168.12.31 -> canneto-mikrotik/x.x.x.x:53913
          Feb 20 19:56:05 openvpn 8555 canneto-mikrotik/x.x.x.x:53913 MULTI: Learn: 192.168.12.32 -> canneto-mikrotik/x.x.x.x:53913
          Feb 20 19:56:05 openvpn 8555 canneto-mikrotik/x.x.x.x:53913 Timers: ping 10, ping-restart 120
          Feb 20 19:56:05 openvpn 8555 canneto-mikrotik/x.x.x.x:53913 Data Channel: cipher 'AES-256-CBC', auth 'SHA1'
          Feb 20 19:56:04 openvpn 8555 canneto-mikrotik/x.x.x.x:53913 SENT CONTROL [canneto-mikrotik]: 'PUSH_REPLY,route 192.168.8.0 255.255.252.0,route-gateway 10.0.28.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.0.28.2 255.255.255.0' (status=1)
          Feb 20 19:56:04 openvpn 8555 canneto-mikrotik/x.x.x.x:53913 PUSH: Received control message: 'PUSH_REQUEST'
          Feb 20 19:56:04 openvpn 8555 canneto-mikrotik/x.x.x.x:53913 Incoming Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication
          Feb 20 19:56:04 openvpn 8555 canneto-mikrotik/x.x.x.x:53913 Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
          Feb 20 19:56:04 openvpn 8555 canneto-mikrotik/x.x.x.x:53913 Outgoing Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication
          Feb 20 19:56:04 openvpn 8555 canneto-mikrotik/x.x.x.x:53913 Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
          Feb 20 19:56:04 openvpn 8555 canneto-mikrotik/x.x.x.x:53913 Data Channel MTU parms [ mss_fix:1363 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
          Feb 20 19:56:04 openvpn 8555 canneto-mikrotik/x.x.x.x:53913 MULTI: Learn: 192.168.12.0/24 -> canneto-mikrotik/x.x.x.x:53913
          Feb 20 19:56:04 openvpn 8555 canneto-mikrotik/x.x.x.x:53913 MULTI: internal route 192.168.12.0/24 -> canneto-mikrotik/x.x.x.x:53913
          Feb 20 19:56:04 openvpn 8555 canneto-mikrotik/x.x.x.x:53913 MULTI: primary virtual IP for canneto-mikrotik/x.x.x.x:53913: 10.0.28.2
          Feb 20 19:56:04 openvpn 8555 canneto-mikrotik/x.x.x.x:53913 MULTI: Learn: 10.0.28.2 -> canneto-mikrotik/x.x.x.x:53913
          Feb 20 19:56:04 openvpn 8555 canneto-mikrotik/x.x.x.x:53913 OPTIONS IMPORT: reading client specific options from: /var/etc/openvpn/server16/csc/canneto-mikrotik
          Feb 20 19:56:04 openvpn 8555 canneto-mikrotik/x.x.x.x:53913 MULTI_sva: pool returned IPv4=10.0.28.2, IPv6=(Not enabled)
          Feb 20 19:56:04 openvpn 8555 x.x.x.x:53913 [canneto-mikrotik] Peer Connection Initiated with [AF_INET]x.x.x.x:53913
          Feb 20 19:56:04 openvpn 8555 x.x.x.x:53913 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
          Feb 20 19:56:04 openvpn 8555 x.x.x.x:53913 TLS: tls_multi_process: initial untrusted session promoted to trusted
          Feb 20 19:56:04 openvpn 8555 x.x.x.x:53913 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
          Feb 20 19:56:04 openvpn 8555 x.x.x.x:53913 VERIFY OK: depth=0, CN=canneto-mikrotik, C=IT,
          Feb 20 19:56:04 openvpn 8555 x.x.x.x:53913 VERIFY SCRIPT OK: depth=0, CN=canneto-mikrotik,
          Feb 20 19:56:04 openvpn 8555 x.x.x.x:53913 VERIFY EKU OK
          Feb 20 19:56:04 openvpn 8555 x.x.x.x:53913 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication
          Feb 20 19:56:04 openvpn 8555 x.x.x.x:53913 Validating certificate extended key usage
          Feb 20 19:56:04 openvpn 8555 x.x.x.x:53913 VERIFY KU OK
          Feb 20 19:56:04 openvpn 8555 x.x.x.x:53913 VERIFY OK: depth=1,
          Feb 20 19:56:04 openvpn 8555 x.x.x.x:53913 VERIFY SCRIPT OK: de
          Feb 20 19:56:04 openvpn 8555 x.x.x.x:53913 VERIFY WARNING: depth=1, unable to get certificate CRL: CN=internal-ca, C=IT
          Feb 20 19:56:04 openvpn 8555 x.x.x.x:53913 VERIFY WARNING: depth=0, unable to get certificate CRL: CN=canneto-mikrotik, C=IT,

          that's the log I don't really see any error.
          I also added at the previus post the CSO route, and it seems ok. any remote device that open a connection with local device is correctly added

          V 1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            If you remove the php error report does it return at reboot?

            If it does it sounds like the upgrade did not complete correctly.

            @enrilor said in OpenVPN network table missing data after upgrade from 2.6.0 to 2.7.2:

            OPENVPN 192.168.12.0/22 ROUTER 192.168.12.253

            So that is incorrect?

            E 1 Reply Last reply Reply Quote 0
            • E
              enrilor @stephenw10
              last edited by

              @stephenw10
              Sorry I misstype 24

              1 Reply Last reply Reply Quote 0
              • E
                enrilor
                last edited by

                I changed in Ipsec an old tunnel that is deactiveted

                pfsense6.PNG

                the remote subnet from 192.168.7.0/24 to 192.168.12.0/24

                pfsense5.PNG

                this is the vpn_table and now it works for 192.168.12.0/24

                Other Openvpn obviously not

                1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator
                  last edited by

                  Ok so it looks like:
                  The tunnel subnet is 10.0.28.0/24
                  The subnet behind the client is 192.168.12.0/24
                  The subnet behind the server is 192.168.8.0/22

                  Is that correct?

                  So what exactly is failing here? What does still work?

                  E 1 Reply Last reply Reply Quote 0
                  • E
                    enrilor @stephenw10
                    last edited by

                    @stephenw10
                    Yes

                    The issue is that from 192.168.8.0/22 subnet I can't reach device on 192.168.12.0/24 but from 192.168.12.0 they can reach device on 192.168.8.0/24

                    If you check the VPN table on the first post the subnet 192.168.12.0/24 is not in table. If it's like the CSO didn't add it.

                    1 Reply Last reply Reply Quote 0
                    • stephenw10S
                      stephenw10 Netgate Administrator
                      last edited by

                      It shouldn't need to be in that table as long as it's in the main routing table.

                      Unless maybe your traffic from LAN behind pfSense is policy routed via a WAN gateway (or group) and needs the VPN networks populated to by-pass that.

                      1 Reply Last reply Reply Quote 0
                      • V
                        viragomann @enrilor
                        last edited by

                        @enrilor
                        Just noted that you need to set the servers verbosity level to 3 to log added routes.

                        And you have to restart the server as mentioned.
                        I'd expect to see a log line with the OpenVPN version, when the server is starting up. I'm missing this in your log snip.

                        The CSO is applied properly according the log. But remote networks, you've set there are is not reflected into the system routing table. This is only applied within OpenVPN.

                        As mentioned, it's the "Remote Networks" setting in the server configuration, which adds system routes. And the OpenVPN log should show this action.

                        1 Reply Last reply Reply Quote 0
                        • stephenw10S stephenw10 moved this topic from Problems Installing or Upgrading pfSense Software on
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.