WireGuard parity: alt_dns policy and teardown status #193

Merged

mysticalsoap merged 2 commits from wg-parity into trunk

2026-08-28 15:18:22 -04:00

mysticalsoap commented

2026-08-28 15:06:37 -04:00

Owner

Problem

Two parity gaps in the WireGuard path, both found in the first live blip test (network change while connected to a ProtonVPN WG server):

Split horizon broken: wg() always applied the conf's DNS = line and never consulted alt_dns, so every query went to the provider's resolver — which knows no local names. The user's own resolver, the reason alt_dns exists, never became primary. (The bug even blocked pushing this branch: with WG up, the forge's split-horizon name resolved to its public IP.)
Ghost "connected": OpenVPN's tunnel_terminated status comes from its dying process's monitor thread. A WG teardown has no process, so the network-change teardown (#111) removed the link silently — tray and status page kept claiming a connection until autoconnect's own kill() repainted.

Fix

wg() follows the openvpn path's DNS policy: alt_dns servers outrank the conf's, dns_off leaves DNS alone (same rules dns_updown_disabled + alt_dns_pair encode for openvpn).
The service emits tunnel_terminated on the protocol branch of disconnect("main"). The openvpn branch stays silent — its process monitor already reports, and a second signal would be a duplicate. Gui-initiated disconnects tolerate the extra signal by design (tunnel_active is already 0, same as a stale server-switch termination).

Verification

5 new tests: TestWgDns (conf DNS by default, alt_dns outranks, dns_off silent), TestDisconnectMain (protocol teardown announces, openvpn teardown stays silent). Full suite 469 passed.
Live check wanted: connect to the WG server with alt-DNS set, confirm local names resolve; then blip the link and confirm the gui shows disconnected during the down window.

## Problem Two parity gaps in the WireGuard path, both found in the first live blip test (network change while connected to a ProtonVPN WG server): 1. **Split horizon broken**: `wg()` always applied the conf's `DNS =` line and never consulted `alt_dns`, so every query went to the provider's resolver — which knows no local names. The user's own resolver, the reason `alt_dns` exists, never became primary. (The bug even blocked pushing this branch: with WG up, the forge's split-horizon name resolved to its public IP.) 2. **Ghost "connected"**: OpenVPN's `tunnel_terminated` status comes from its dying process's monitor thread. A WG teardown has no process, so the network-change teardown (#111) removed the link silently — tray and status page kept claiming a connection until autoconnect's own `kill()` repainted. ## Fix - `wg()` follows the openvpn path's DNS policy: `alt_dns` servers outrank the conf's, `dns_off` leaves DNS alone (same rules `dns_updown_disabled` + `alt_dns_pair` encode for openvpn). - The service emits `tunnel_terminated` on the protocol branch of `disconnect("main")`. The openvpn branch stays silent — its process monitor already reports, and a second signal would be a duplicate. Gui-initiated disconnects tolerate the extra signal by design (`tunnel_active` is already 0, same as a stale server-switch termination). ## Verification - 5 new tests: `TestWgDns` (conf DNS by default, alt_dns outranks, dns_off silent), `TestDisconnectMain` (protocol teardown announces, openvpn teardown stays silent). Full suite 469 passed. - Live check wanted: connect to the WG server with alt-DNS set, confirm local names resolve; then blip the link and confirm the gui shows disconnected during the down window.

mysticalsoap added 2 commits

2026-08-28 15:06:37 -04:00

fix: the wg path honours alt_dns like the openvpn path (#152 ) e94c0ff3cd

wg() always applied the conf's DNS line and never consulted the
alt_dns setting, so a WireGuard connection handed every query to the
provider's resolver -- for a split-horizon setup that silently breaks
all local names, since the user's own resolver (the reason alt_dns is
set) never becomes primary. The openvpn path has had this policy all
along via dns_updown_disabled + alt_dns_pair.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

fix: a protocol teardown announces tunnel_terminated (#152 )

ci / test (pull_request) Successful in 24s

Details

5de0831c30

OpenVPN's death reaches the clients through its dying process's
monitor thread. A WireGuard teardown has no process, so a network
change (#111) removed the link silently and the gui kept claiming a
connection -- tray icon and status page both -- until autoconnect's
own kill() happened to repaint. The service now emits the status
itself on the protocol branch of disconnect("main"); the openvpn
branch stays silent since its process monitor already reports.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

mysticalsoap merged commit 18ace238d8 into trunk

2026-08-28 15:18:22 -04:00

mysticalsoap deleted branch wg-parity

2026-08-28 15:18:22 -04:00

mysticalsoap referenced this pull request

2026-08-28 15:19:14 -04:00

Extract the connect/reconnect decision into a Qt-free module #123

mysticalsoap referenced this pull request

2026-08-28 15:19:14 -04:00

ProtonVPN WireGuard support #152