Bypass never comes up after a reboot - and takes the bypass_networks exemptions down with it #168
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
After a machine reboot nothing rebuilds the bypass:
reconcile_bypassat service start only restores a bypass whose leftover cgroup survived (a fresh boot has none),service_recoveredin the gui only fires when the service restarts under a running gui, and no plain gui-startup path callsbypass(). The whole stack — cgroup, fwmark rule, table-11 default, andset_network_rules— stays down until the user happens to hit Apply in options.Confirmed live 2026-08-26: last 'Creating bypass' log line Aug 24 22:46, machine rebooted Aug 25 morning (resolved PID change), multiple gui launches and tunnel sessions since — zero rebuilds,
iptables-legacy -t mangle -Sshows noaqomui_bypass_netchain. Consequence, captured on the wire: with the tunnel up, gluetun's WireGuard endpoint traffic (172.18.7.0/24udp/51820, exactly the configuredbypass_networksentry) leaves viatun_aqomuiinstead ofenp5s0— the container VPN double-tunnels through the OpenVPN connection, carrying the full seeding load. That is the confirmed mechanism behind (at least the post-reboot share of) #118's tunnel UDP-loss windows.Fix shape, two independent halves:
set_network_rules, the fwmark rules and table-11 default) belong to service startup wheneverbypass=1— forwarded-traffic exemptions need no cgroup owner and shouldn't wait for one. The service already derives its own network facts (#89), andnetwork_changedcan re-assert them.bypass()on every startup, not only inservice_recovered— and note the early-call failure seen Aug 24 18:22 (polkit refusal of a caller mid-service-start, #162's vanished-caller case) has no retry, so even that path can silently leave the bypass down.🤖 Generated with Claude Code
Live-verified 2026-09-16 on the first aqomui start after a 2026-09-13 reboot (pristine state confirmed beforehand: no fwmark rule, no table 11, no chain). Service init applied ownerless routing, GUI start built the cgroup — no manual Apply.
ip ruleshows fwmark 0xb → table 11 (default via enp5s0), andiptables-legacy -t mangle -Sshows the aqomui_bypass_net mark rule for 172.18.7.0/24 udp/51820.