VPN Stays connected but Stops Routing after DoH Change

[CaptnDanLKW]

Post title says it all. I have an established OpenVPN Client connection to a remote location, and I have a VM set to use this connection.

Works great, I'll occasionally check 'whats my IP address' to verify it's still up.

I was troubleshooting a suspected issues due to using AdGuard DNS servers, so I was changing DNS providers a couple times, which restarts stubby.

I just discovered that once I made DNS change it breaks VPN routing. The quirky part is, VPN is still connected but the IP exposed is my ISP's IP.

Stopping and restarting the VPN Connection fixes, but that's definitely not a real solution.

Can someone else determine if this is repeatable on their system? Wondering if it's a real bug or something specific to my setup.

Thanks

 

[Viktor Jaep]

Post title says it all. I have an established OpenVPN Client connection to a remote location, and I have a VM set to use this connection.

Works great, I'll occasionally check 'whats my IP address' to verify it's still up.

I was troubleshooting a suspected issues due to using AdGuard DNS servers, so I was changing DNS providers a couple times, which restarts stubby.

I just discovered that once I made DNS change it breaks VPN routing. The quirky part is, VPN is still connected but the IP exposed is my ISP's IP.

View attachment 59784
Stopping and restarting the VPN Connection fixes, but that's definitely not a real solution.

Can someone else determine if this is repeatable on their system? Wondering if it's a real bug or something specific to my setup.

Thanks

After a major networking change while connected to VPN, you would need to issue a restart to the routing service:

service restart_vpnrouting0

 

[eibgrad]

Seems that many users believe you can just make changes willy-nilly and the router will automatically adjust itself to the new configuration. Unfortunately, it rarely works that way. Many subsystems assume a static/fixed state for their various dependencies, be it the routing tables, firewall, DNS server(s), etc. Few subsystems are smart enough to even recognize a change has occurred underneath them, let alone determine how it affects them and reconfigure themselves appropriately.

That's why, in general, users should NOT be fiddling w/ a running system (or if you must, a reboot is probably warranted). Once configured and rebooted, it should pretty much be left alone, *even* if the GUI would seem to suggest you can make changes w/ impunity (i.e., it doesn't prevent you, and provides no warning of the consequences). Otherwise, expect problems.