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

    General pfSense Questions
    3
    19
    905
    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.
    • V
      viragomann @enrilor
      last edited by

      @enrilor
      Is the server configured as "peer to peer"?

      If so and you don't see the 191.168.24.0/24 in the routing table, I'd assume that there went something wrong, when adding the routes.
      Restart the server and check the OpenVPN log then for regarding entries.

      For the CSO, pfSense provides the "remote network" field to enter the client sides networks. This does the proper iroute for you then.

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

        There seem to be some mismatches there. Your post shows the tunnel subnet as 192.168.12.0/22 with the router (server?) at 192.168.12.253.

        That conflicts with the CSO.

        And yes you shouldn't need to add an iroute as a custom config line like that. You already have it as a remote network.

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

          @viragomann
          Yes Peer to Peer SSL/TLS
          I tried to restart vpn. Deactive, reactivate, delete, add CSO, but not working.

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

            @stephenw10
            192.168.12.0 is 24 not 22. Doesn't confict with 192.168.8.0/22.
            I repeat this configuration works for 26 month correctly with 2.6.0, till I update to 2.7.2

            1 Reply Last reply Reply Quote 0
            • 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.