WireGuard bypass tunnel #216

New issue

Closed

opened 2026-08-30 13:46:20 -04:00 by mysticalsoap · 0 comments

mysticalsoap commented

2026-08-30 13:46:20 -04:00

Owner

The last WireGuard capability gap after #176: the bypass's second tunnel is OpenVPN-only (TUNNEL_BYPASS, refused at WireGuard construction). Nothing protocol-level rules it out - kernel WireGuard never inherits the inner packet's fwmark, so the outer packets stay unmarked and consult the main table like any other tunnel's.

Shape (building on the #176 seams):

WireGuard.roles grows "bypass" → device wg_aqomui_b (already reserved in config.WG_DEVICES); TUNNEL_BYPASS["WireGuard"] flips, which alone lifts the gui gate.
Routing: endpoint pin in the main table only (unmarked outer - unlike OpenVPN-DCO's marked data, which needs both tables), no def1, and the table-11 default installed by the tunnel thread - ip route replace default dev wg_aqomui_b table 11, the WireGuard analogue of bypass_up.sh (dev-only route is fine: wg is always tun-like, no tap case - this leg needs no $route_vpn_gateway).
wg() becomes role-aware: bypass suffix on statuses, role state on "bypass", and no resolved entry (#59's rule) - the service's dnsmasq upstream switching already keys on the bypass role's state.
Service constructs/tears down a bypass-role protocol object (self.bypass_protocol), mirroring the hop one from #214.
Handshake gate: the ping -I nudge can't route through table 11; nudge via a temporary TEST-NET-1 host route into the device instead (the reply is irrelevant, only the outbound attempt triggers the handshake).

Also retires the aspiration blocker noted on bypass_up.sh: once a WG bypass routes from Python, the OpenVPN bypass hook is the only script left for its own reasons (tap/subnet gateway, soft-restart re-runs).

The last WireGuard capability gap after #176: the bypass's second tunnel is OpenVPN-only (`TUNNEL_BYPASS`, refused at `WireGuard` construction). Nothing protocol-level rules it out - kernel WireGuard never inherits the inner packet's fwmark, so the outer packets stay unmarked and consult the main table like any other tunnel's. Shape (building on the #176 seams): - `WireGuard.roles` grows "bypass" → device `wg_aqomui_b` (already reserved in `config.WG_DEVICES`); `TUNNEL_BYPASS["WireGuard"]` flips, which alone lifts the gui gate. - Routing: endpoint pin in the main table only (unmarked outer - unlike OpenVPN-DCO's marked data, which needs both tables), no def1, and the table-11 default installed by the tunnel thread - `ip route replace default dev wg_aqomui_b table 11`, the WireGuard analogue of bypass_up.sh (dev-only route is fine: wg is always tun-like, no tap case - this leg needs no $route_vpn_gateway). - `wg()` becomes role-aware: bypass suffix on statuses, role state on "bypass", and no resolved entry (#59's rule) - the service's dnsmasq upstream switching already keys on the bypass role's state. - Service constructs/tears down a bypass-role protocol object (`self.bypass_protocol`), mirroring the hop one from #214. - Handshake gate: the `ping -I` nudge can't route through table 11; nudge via a temporary TEST-NET-1 host route into the device instead (the reply is irrelevant, only the outbound attempt triggers the handshake). Also retires the aspiration blocker noted on bypass_up.sh: once a WG bypass routes from Python, the OpenVPN bypass hook is the only script left for its own reasons (tap/subnet gateway, soft-restart re-runs).

mysticalsoap referenced this issue from a commit

2026-08-30 13:51:36 -04:00

add: WireGuard bypass tunnel

mysticalsoap referenced this issue from a pull request that will close it,

2026-08-30 13:51:52 -04:00

add: WireGuard bypass tunnel #217

mysticalsoap referenced this issue from a commit

2026-09-16 20:50:51 -04:00

add: WireGuard bypass tunnel

mysticalsoap referenced this issue from a commit

2026-09-16 21:26:52 -04:00

add: WireGuard bypass tunnel