OpenVPN network table missing data after upgrade from 2.6.0 to 2.7.2

viragomann · Feb 20, 2024, 5:15 PM

@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.

stephenw10 · Feb 20, 2024, 5:30 PM

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.

enrilor · Feb 20, 2024, 6:40 PM

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

enrilor · Feb 20, 2024, 6:50 PM

@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

enrilor · Feb 20, 2024, 6:58 PM

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

viragomann · Feb 20, 2024, 6:57 PM

@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.

enrilor · Feb 20, 2024, 7:04 PM

@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

stephenw10 · Feb 20, 2024, 7:05 PM

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?

enrilor · Feb 20, 2024, 7:08 PM

@stephenw10
Sorry I misstype 24

enrilor · Feb 20, 2024, 7:10 PM

I changed in Ipsec an old tunnel that is deactiveted

the remote subnet from 192.168.7.0/24 to 192.168.12.0/24

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

Other Openvpn obviously not

stephenw10 · Feb 20, 2024, 7:11 PM

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?

enrilor · Feb 20, 2024, 7:19 PM

@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.

stephenw10 · Feb 20, 2024, 7:22 PM

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.

viragomann · Feb 20, 2024, 11:01 PM

@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.