qubes-nmhook should update DNS DNAT rules after a VPN disconnects

[mattmccutchen]

Qubes OS version:

R4.0

Affected component(s):

qubes-core-agent-network-manager

---

Steps to reproduce the behavior:

1. In the NetVM, use NetworkManager to connect to a VPN that specifies its own DNS servers.
2. Disconnect from the VPN.
3. Try to browse to a web site from an AppVM.

Expected behavior:

In step 2, qubes-nmhook calls qubes-setup-dnat-to-ns to change the DNAT rules back to the non-VPN DNS servers, and step 3 succeeds.

Actual behavior:

In step 2, qubes-nmhook does not call qubes-setup-dnat-to-ns, and step 3 tries to use the VPN's DNS servers, which may fail.

General notes:

The following sequence of calls was made to qubes-nmhook when I connected and disconnected my VPN:

vpn0 vpn-up
vpn0 up
vpn0 vpn-down
vpn0 down

So maybe it would be sufficient to check for an action of up or vpn-down.

A workaround is to disconnect and reconnect the underlying network interface.

---

Related issues:

#3135

[tasket]

Note:

It appears the disconnection behavior for qubes-core-agent-network-manager hasn't been considered until now, because there is no scripted down action.

In contrast, qubes-tunnel and related VPN handlers are written with the expectation that any transition to a 'down' state must leave all traffic blocked. In this configuration the solution for an appVM that moves between clearnet and tunnel (not advisable in many use cases) is to change the appVM's netvm setting as needed.

Suggest keeping this in mind when the Network Manager 'down' action is implemented, as its probably best to remain consistent and block traffic on 'down' for security reasons... at least as the default behavior.

[tasket]

Note:

It appears the disconnection behavior for qubes-core-agent-network-manager hasn't been considered until now, because there is no scripted down action.

In contrast, qubes-tunnel and related VPN handlers are written with the expectation that any transition to a 'down' state must leave all traffic blocked. In this configuration the solution for an appVM that moves between clearnet and tunnel (not advisable in many use cases) is to change the appVM's netvm setting as needed.

Suggest keeping this in mind when the Network Manager 'down' action is implemented, as its probably best to remain consistent and block traffic on 'down' for security reasons... at least as the default behavior.