I’m a bit confused. Did you say that you can’t see the connection with nmcli con show (I presume),
yet you were able to refer to that connection?
(One can use both name and UUID to refer to connection.)
Yes, the ipv4.never-default (and ipv6.never-default) affect whether NetworkManager does use the DHCP option “routers” to construct a default route (aka ‘gateway’). It is a positive surprise that NM can use that with OpenVPN too (as OpenVPN server usually hands config for the client). Intregration that converts nm-settings into openvpn settings?
The last time I’ve used openvpn, it was without NM. My openvpn server did not push “default-route” either.
With NetworkManager-openvpn installed, one can import an OpenVPN config file into Network Manager.
My VPN server is not pushing the unwanted default route – it’s NetworkManager that is inventing it.
The latest OpenVPN packages for Rocky 8 don’t include any service files – the only way I found to start it, other than a basic script, is to use NetworkManager.
The results of “nmcli con show” are interesting:
nmcli con show
NAME UUID TYPE DEVICE
untrusted 9b8215f6-a0ee-4f0c-b9c5-e6bfccd67489 vpn ens3
ens3 47118d83-e869-43bc-80b1-6a1a160f2b13 ethernet ens3
tun0 6e39e2c0-bd5b-4e47-aab5-a2c15a364160 tun tun0
tun0 6b5ba2be-f13c-476a-81d6-efbc16795f7b tun –
I don’t know where the second “tun0” has come from. It remains there even if I shut down the “untrusted” VPN connection.
The new problem is that the “untrusted” VPN connection doesn’t come up automatically after a reboot, despite it being configured to do so:
nmcli con show untrusted | grep auto
connection.autoconnect: yes
connection.autoconnect-priority: 0
connection.autoconnect-retries: -1 (default)
connection.autoconnect-slaves: -1 (default)
ipv4.method: auto
ipv4.ignore-auto-routes: no
ipv4.ignore-auto-dns: no
ipv6.method: auto
ipv6.ignore-auto-routes: no
ipv6.ignore-auto-dns: no
ipv6.mtu: auto
I wonder if I need to also set one of the “tun0” interfaces to also come up automatically?