Bypass tab: per-entry destination (physical link vs bypass server), exclude/include framing #223

New issue

Open

opened 2026-09-16 23:03:06 -04:00 by mysticalsoap · 0 comments

mysticalsoap commented

2026-09-16 23:03:06 -04:00

Owner

Where things stand after #222: bypassed apps use the bypass server when one is up and the physical link otherwise; bypass networks always use the physical link. That is one fixed policy per kind, and the two legitimate desires it has to serve pull in opposite directions:

Total exclusion: this traffic must never enter any VPN. A container running its own VPN (gluetun, #168) - double-tunnelling it is the bug. Today only achievable by not connecting a bypass server at all.
Via the bypass server (the "reverse bypass"): main tunnel connected, and a specific app - a non-containerised qbittorrent - opts in to a second VPN through the bypass server. Today this is what apps get implicitly, and networks cannot get at all.

Both desires apply to both kinds. A LAN client using this host as a gateway may want the bypass server; an app may want total exclusion while another app uses the bypass server. The clean model is a per-entry destination - physical link or bypass server - for apps and networks alike, rather than one policy per kind.

The UI is the hard part. The bypass tab is already dense, and this adds a dimension. ProtonVPN's split-tunneling framing is the reference: a mode switch (Exclude - selected apps skip the VPN; Include - only selected apps use it) over one app list. aqomui already has the include half as "connect to a server only via bypass"; the per-entry destination is what would let one list express exclude, include and the mixed case without three separate controls. This belongs to the broader UI cleanup (#70, #153) rather than a bolt-on checkbox - design it there, not scheduled on its own.

Where things stand after #222: bypassed **apps** use the bypass server when one is up and the physical link otherwise; bypass **networks** always use the physical link. That is one fixed policy per kind, and the two legitimate desires it has to serve pull in opposite directions: - **Total exclusion**: this traffic must never enter any VPN. A container running its own VPN (gluetun, #168) - double-tunnelling it is the bug. Today only achievable by not connecting a bypass server at all. - **Via the bypass server** (the "reverse bypass"): main tunnel connected, and a specific app - a non-containerised qbittorrent - opts *in* to a second VPN through the bypass server. Today this is what apps get implicitly, and networks cannot get at all. Both desires apply to both kinds. A LAN client using this host as a gateway may want the bypass server; an app may want total exclusion while another app uses the bypass server. The clean model is a **per-entry destination** - physical link or bypass server - for apps and networks alike, rather than one policy per kind. The UI is the hard part. The bypass tab is already dense, and this adds a dimension. ProtonVPN's split-tunneling framing is the reference: a mode switch (*Exclude* - selected apps skip the VPN; *Include* - only selected apps use it) over one app list. aqomui already has the include half as "connect to a server only via bypass"; the per-entry destination is what would let one list express exclude, include and the mixed case without three separate controls. This belongs to the broader UI cleanup (#70, #153) rather than a bolt-on checkbox - design it there, not scheduled on its own.

mysticalsoap added the

label

2026-09-16 23:03:06 -04:00

mysticalsoap referenced this issue

2026-09-16 23:56:39 -04:00

fix: keep bypass network entries on the physical link #222