amnezia-vpn/amnezia-client

Fork 0

mirror of https://github.com/amnezia-vpn/amnezia-client.git synced 2026-10-15 05:42:07 +00:00

infinite "Connection" status — while same server works perfectly with Windscribe's Kill Switch #1436

New issue

Open

opened 2026-10-13 20:42:28 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-13 20:42:28 +00:00

Owner

Originally created by @nkubisoftacc2000 on GitHub (Aug 31, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3098

Problem Description

When Kill Switch is effectively ON:

AllowedIPs = 0.0.0.0/0
ping 8.8.8.8 returns "General failure" (not "Request timed out")
Browsers show ERR_NETWORK_ACCESS_DENIED / "Your Internet access is blocked" on some websites and fail to load entirely
No DNS leaks, but the connection is completely broken

When Kill Switch is effectively OFF (config manually edited):

AllowedIPs changes to 0.0.0.0/1, 128.0.0.0/1
Connection works perfectly, good speed, all websites load
However, DNS leak tests (dnsleaktest.com, ipleak.net) show my real ISP DNS servers

Expected Behavior

Kill Switch ON should block all untunneled traffic via WFP firewall rules while maintaining a working tunnel (no "General failure")

Comparison with Windscribe

I tested the exact same server by importing the WireGuard config into Windscribe, which also has a Kill Switch / Firewall mode:

Feature	AmneziaWG VPN Client	Windscribe	AmneziaWG Client for Windows
Kill Switch ON	❌ General failure, no internet	✅ Works perfectly	Some websites blocked
DNS Leak protection	✅ No leak (but no internet)	✅ No leak	No leak (but some website not working)
Speed	❌ N/A (broken)	✅ Full speed	✅ Full speed
All Websites load	❌ No	✅ Yes	❌ No

This confirms the server-side configuration is correct (NAT, IP forwarding, firewall rules all verified). The issue is strictly in how the AmneziaWG Windows client enforces the Kill Switch at the OS level.

Questions

Why does the Kill Switch cause General failure and broken routing, while Windscribe's WFP-based implementation works flawlessly on the same machine?
Is there a way to achieve both a working connection and zero DNS leaks with the current client?

Originally created by @nkubisoftacc2000 on GitHub (Aug 31, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3098 ## Problem Description ### When Kill Switch is effectively ON: 1. `AllowedIPs = 0.0.0.0/0` 2. `ping 8.8.8.8` returns **"General failure"** (not "Request timed out") 3. Browsers show `ERR_NETWORK_ACCESS_DENIED` / *"Your Internet access is blocked"* on some websites and fail to load entirely 4. No DNS leaks, but the connection is completely broken ### When Kill Switch is effectively OFF (config manually edited): 1. `AllowedIPs` changes to `0.0.0.0/1, 128.0.0.0/1` 2. Connection works perfectly, good speed, all websites load 3. However, DNS leak tests ([dnsleaktest.com](https://dnsleaktest.com), [ipleak.net](https://ipleak.net)) show my real ISP DNS servers --- ## Expected Behavior - Kill Switch **ON** should block all untunneled traffic via WFP firewall rules **while maintaining a working tunnel** (no "General failure") --- ## Comparison with Windscribe I tested the exact same server by importing the WireGuard config into **Windscribe**, which also has a Kill Switch / Firewall mode: | Feature | AmneziaWG VPN Client | Windscribe | AmneziaWG Client for Windows | |---|:---:|:---:|---:| | Kill Switch ON | ❌ General failure, no internet | ✅ Works perfectly | Some websites blocked | | DNS Leak protection | ✅ No leak (but no internet) | ✅ No leak | No leak (but some website not working) | | Speed | ❌ N/A (broken) | ✅ Full speed | ✅ Full speed | | All Websites load | ❌ No | ✅ Yes | ❌ No | This confirms the **server-side configuration is correct** (NAT, IP forwarding, firewall rules all verified). The issue is strictly in how the AmneziaWG Windows client enforces the Kill Switch at the OS level. --- ## Questions 1. Why does the Kill Switch cause `General failure` and broken routing, while Windscribe's WFP-based implementation works flawlessly on the same machine? 2. Is there a way to achieve **both** a working connection **and** zero DNS leaks with the current client?

bsakaguchi commented

2026-10-13 20:42:29 +00:00

Author

Owner

@DimitriiKorol commented on GitHub (Sep 1, 2026):

Can you add in title that KillSwitch can cause infinite "Connection" status? Cause I was looking for it and didn't find, end up reporting similar issue with kill switch

@DimitriiKorol commented on GitHub (Sep 1, 2026): Can you add in title that KillSwitch can cause infinite "Connection" status? Cause I was looking for it and didn't find, end up reporting similar issue with kill switch

bsakaguchi commented

2026-10-13 20:42:29 +00:00

Author

Owner

@lookingglass commented on GitHub (Sep 2, 2026):

Broken feature on Linux. Causes long connection to AWG 3.1 / 2.0 containers

@lookingglass commented on GitHub (Sep 2, 2026): Broken feature on Linux. Causes long connection to AWG 3.1 / 2.0 containers

bsakaguchi commented

2026-10-13 20:42:30 +00:00

Author

Owner

@HeisLuka commented on GitHub (Sep 9, 2026):

I checked this against the exact 5.0.1.5 Windows code and current dev.

I think the 0.0.0.0/0 vs 0.0.0.0/1 + 128.0.0.0/1 observation is especially useful, but it points to a routing/WFP interaction rather than simply “the Kill Switch implementation blocks the VPN”.

There are also separate source-confirmed bugs in the Windows WFP DNS filters.

1. `AllowedIPs` is not the Kill Switch switch in Amnezia

The desktop WireGuard/AWG activation path passes these independently:

allowedIPAddressRanges
killSwitchOption

LocalSocketController::activate() builds the route prefixes from AllowedIPs, while separately passing:

json.insert(
    amnezia::configKey::killSwitchOption,
    rawConfig.value(amnezia::configKey::killSwitchOption));

So changing:

0.0.0.0/0

to:

0.0.0.0/1
128.0.0.0/1

changes the routing topology.

It does not, by itself, disable Amnezia's WFP Kill Switch.

This distinction matters because the exact routing difference provides a strong clue to the failure.

2. `/0` and `/1 + /1` behave very differently in the Windows route table

For:

AllowedIPs = 0.0.0.0/0

Amnezia manually installs a Windows route through the AWG interface with:

entry->InterfaceLuid.Value = m_luid;
entry->Metric = 0;

That sounds like the VPN route must win, but MIB_IPFORWARD_ROW2::Metric is only the route metric offset.

Windows route preference uses the route metric together with the associated interface metric.

Therefore the actual comparison can be:

AWG:
route metric     = 0
interface metric = N
total            = N

physical NIC:
route metric     = X
interface metric = Y
total            = X + Y

For two /0 routes, the physical route can win if:

X + Y < N

This is important because Amnezia does not currently establish the normal full-tunnel interface-metric invariant during initial AWG startup.

3. Amnezia removes the Peer before starting the Windows tunnel service

WireguardUtilsWindows::addInterface() generates the configuration and explicitly does:

extraConfig["Table"] = "off";

...

qsizetype peerStart =
    configString.indexOf("[Peer]", 0, Qt::CaseSensitive);

if (peerStart >= 0) {
    configString.truncate(peerStart);
}

Only later does updatePeer() send through UAPI:

replace_allowed_ips=true
allowed_ip=0.0.0.0/0

The AWG Windows implementation normally detects a default AllowedIP during interface configuration:

foundDefault4 := false

for _, peer := range conf.Peers {
    for _, allowedip := range peer.AllowedIPs {
        if allowedip.Cidr == 0 {
            foundDefault4 = true
        }
    }
}

and then:

if foundDefault4 {
    ipif.UseAutomaticMetric = false
    ipif.Metric = 0
}

But the configuration initially supplied by Amnezia contains no [Peer].

Therefore at initial interface configuration:

conf.Peers = empty
foundDefault4 = false

and that full-tunnel interface metric setup is not performed.

Amnezia later installs the route itself with route metric 0, but that is not equivalent to setting the interface metric to 0.

4. This gives a direct explanation for why `/1 + /1` fixes the connection

Consider an ordinary physical default route:

0.0.0.0/0 -> Ethernet/Wi-Fi

With the Amnezia config:

0.0.0.0/0 -> AWG

both candidates have the same prefix length.

Windows must then choose between them using route/interface preference.

But if the config is changed to:

0.0.0.0/1     -> AWG
128.0.0.0/1   -> AWG

every ordinary public IPv4 address matches an AWG /1 and the physical interface only has /0.

Longest-prefix routing wins before the default-route metric competition matters:

AWG /1
beats
physical /0

This makes the reported A/B result very significant:

0/0        -> broken
/1 + /1    -> works

It is exactly what I would expect if the AWG /0 is losing a same-prefix route competition on that machine.

5. The Kill Switch then turns the routing bug from fail-open into fail-closed

The Windows AWG path enables the firewall with the actual VPN interface index:

m_firewall->allowAllTraffic();
m_firewall->enableInterface(ifindex);

The firewall creates an explicit permit for the VPN interface:

FWPM_CONDITION_INTERFACE_INDEX == vpnAdapterIndex
-> PERMIT

and enablePeerTraffic() creates block rules covering the configured VPN ranges.

For a full-tunnel configuration that includes:

0.0.0.0/0

the intended model is effectively:

traffic routed through VPN adapter
    -> permitted

traffic to VPN-covered destinations
through another adapter
    -> blocked

Now combine that with the route selection above.

Without enforcement:

Windows chooses physical /0
    ↓
packet escapes through ISP

With Kill Switch:

Windows chooses physical /0
    ↓
packet does not use permitted AWG interface
    ↓
WFP blocks it locally
    ↓
General failure / ERR_NETWORK_ACCESS_DENIED

So the Kill Switch may be exposing the underlying routing failure rather than causing it.

This also explains a common diagnostic pattern:

Kill Switch OFF:
Internet appears to work
but traffic/DNS can leak

Kill Switch ON:
same incorrect physical route
is now blocked
so Internet stops completely

That is preferable to silently leaking, but the underlying route selection still has to be fixed.

6. One runtime snapshot can confirm this on the affected machine

While connected with the failing 0.0.0.0/0 configuration:

Get-NetIPInterface -AddressFamily IPv4 |
    Sort-Object InterfaceMetric

Get-NetRoute -AddressFamily IPv4 |
    Where-Object DestinationPrefix -eq "0.0.0.0/0"

Find-NetRoute -RemoteIPAddress 8.8.8.8

The useful values are:

AWG interface index
AWG InterfaceMetric
AWG /0 RouteMetric

physical interface index
physical InterfaceMetric
physical /0 RouteMetric

winning route/interface for 8.8.8.8

If the AWG /0 exists but:

Find-NetRoute 8.8.8.8

selects Ethernet/Wi-Fi, this report is runtime-confirmed.

An especially useful A/B test is:

configuration A:
0.0.0.0/0

configuration B:
0.0.0.0/1 + 128.0.0.0/1

and compare only:

Find-NetRoute -RemoteIPAddress 8.8.8.8

If A chooses the physical adapter while B chooses AWG, the /0 metric competition is isolated.

7. There is also an independent source-confirmed WFP DNS bug

While looking at the Kill Switch implementation I found a separate deterministic problem.

The helper used to permit the configured DNS server on port 53 builds one WFP filter containing:

conds[0]:
    FWPM_CONDITION_IP_PROTOCOL == IPPROTO_UDP

conds[1]:
    FWPM_CONDITION_IP_PROTOCOL == IPPROTO_TCP

conds[2]:
    FWPM_CONDITION_IP_REMOTE_PORT == 53

conds[3]:
    FWPM_CONDITION_IP_REMOTE_ADDRESS == DNS_SERVER

and then:

filter.numFilterConditions = 4;

WFP filter conditions are conjunctive.

Therefore this filter requires one connection to be simultaneously:

UDP
AND
TCP
AND
port 53
AND
the configured DNS address

which can never happen.

So the intended high-priority rule:

Allow DNS-Server

cannot match either UDP DNS or TCP DNS.

There is also a small type inconsistency:

conds[1].conditionValue.type = FWP_UINT8;
conds[1].conditionValue.uint16 = IPPROTO_TCP;

although the larger logical problem is already the contradictory protocol conditions.

8. `blockTrafficOnPort()` contains the same protocol-condition mistake

The generic:

Block all DNS

helper creates:

conds[0]:
    protocol == UDP

conds[1]:
    protocol == TCP

conds[2]:
    remote port == 53

inside one filter.

So that rule is also unsatisfiable as written.

This means both sides of the intended explicit DNS policy are malformed:

explicit port-53 permit
and
explicit port-53 block

Both should instead create separate TCP and UDP filters.

For example, conceptually:

filter 1:
protocol = UDP
remote port = 53
...

filter 2:
protocol = TCP
remote port = 53
...

not:

protocol = UDP AND protocol = TCP

This is present in the reported 5.0.1.5 source and remains unchanged in current dev.

I would treat this as a separate source-confirmed defect exposed while investigating #3098; it is not sufficient by itself to explain ping 8.8.8.8 -> General failure.

9. The routing fix should establish a postcondition, not just add another route

For Windows full tunnel, the important invariant is:

AllowedIPs contains 0.0.0.0/0
    =>
best route to an ordinary non-excluded public IPv4
uses the AWG LUID

Before reporting the tunnel healthy, something equivalent to:

GetBestRoute2(public destination)

should confirm that the result uses the AWG interface.

The endpoint itself is the deliberate exception:

VPN server endpoint
    -> physical underlay

while:

ordinary public destination
    -> AWG

should always hold.

For the current Windows AWG implementation, explicitly establishing:

UseAutomaticMetric = false
InterfaceMetric = 0

for a full-tunnel interface would restore the same interface invariant that amneziawg-windows normally applies when it sees a default AllowedIP in its initial configuration.

Alternatively, preserve enough default-route intent in the startup configuration for amneziawg-windows to perform its normal setup, while continuing to keep route ownership in Amnezia if Table=off is required.

10. Suggested regression matrix

Routing

physical default = /0
AWG AllowedIPs   = /0

Expected:

public best route = AWG

Test with:

Ethernet
Wi-Fi
PPP/PPPoE
multiple adapters
low physical interface metric

`/0` vs `/1`

Both:

0.0.0.0/0

and:

0.0.0.0/1
128.0.0.0/1

must result in the same intended full-tunnel data plane.

The /1 workaround should not be required to overcome interface metric selection.

Kill Switch

With Kill Switch OFF:

ordinary public traffic must still use AWG

With Kill Switch ON:

ordinary public traffic must still use AWG
and physical leakage must be blocked

Kill Switch must not be the component compensating for a wrong route winner.

DNS

Test separately:

UDP/53 to configured DNS
TCP/53 to configured DNS
UDP/53 to non-approved DNS
TCP/53 to non-approved DNS

and verify the actual WFP filters match those flows.

Failure mode

Deliberately make the physical /0 more attractive than the AWG /0.

Expected:

activation corrects/rejects the route state

Forbidden:

Kill Switch OFF -> silent ISP leak
Kill Switch ON  -> General failure

Classification

I would classify the source defects as confirmed on current dev.

For this reporter specifically, I would call the /0 metric path highly consistent but requiring one Find-NetRoute snapshot for final runtime confirmation.

The key distinction is:

Kill Switch ON is probably not destroying an otherwise-correct tunnel. The 0.0.0.0/0 route can lose to the physical Windows default route because Amnezia sets only the route metric while its peerless startup prevents the normal AWG full-tunnel interface-metric setup. WFP then correctly blocks that wrongly selected physical path, turning a potential leak into General failure.

The /1 + /1 workaround avoids the metric competition because those routes are more specific than the physical /0.

Separately, the Windows WFP DNS permit/block helpers contain impossible UDP AND TCP conditions and should be fixed independently.

@HeisLuka commented on GitHub (Sep 9, 2026): I checked this against the exact `5.0.1.5` Windows code and current `dev`. I think the `0.0.0.0/0` vs `0.0.0.0/1 + 128.0.0.0/1` observation is especially useful, but it points to a routing/WFP interaction rather than simply “the Kill Switch implementation blocks the VPN”. There are also separate source-confirmed bugs in the Windows WFP DNS filters. ### 1. `AllowedIPs` is not the Kill Switch switch in Amnezia The desktop WireGuard/AWG activation path passes these independently: ```text allowedIPAddressRanges killSwitchOption ``` `LocalSocketController::activate()` builds the route prefixes from `AllowedIPs`, while separately passing: ```cpp json.insert( amnezia::configKey::killSwitchOption, rawConfig.value(amnezia::configKey::killSwitchOption)); ``` So changing: ```text 0.0.0.0/0 ``` to: ```text 0.0.0.0/1 128.0.0.0/1 ``` changes the routing topology. It does not, by itself, disable Amnezia's WFP Kill Switch. This distinction matters because the exact routing difference provides a strong clue to the failure. ### 2. `/0` and `/1 + /1` behave very differently in the Windows route table For: ```text AllowedIPs = 0.0.0.0/0 ``` Amnezia manually installs a Windows route through the AWG interface with: ```cpp entry->InterfaceLuid.Value = m_luid; entry->Metric = 0; ``` That sounds like the VPN route must win, but `MIB_IPFORWARD_ROW2::Metric` is only the route metric offset. Windows route preference uses the route metric together with the associated interface metric. Therefore the actual comparison can be: ```text AWG: route metric = 0 interface metric = N total = N physical NIC: route metric = X interface metric = Y total = X + Y ``` For two `/0` routes, the physical route can win if: ```text X + Y < N ``` This is important because Amnezia does not currently establish the normal full-tunnel interface-metric invariant during initial AWG startup. ### 3. Amnezia removes the Peer before starting the Windows tunnel service `WireguardUtilsWindows::addInterface()` generates the configuration and explicitly does: ```cpp extraConfig["Table"] = "off"; ... qsizetype peerStart = configString.indexOf("[Peer]", 0, Qt::CaseSensitive); if (peerStart >= 0) { configString.truncate(peerStart); } ``` Only later does `updatePeer()` send through UAPI: ```text replace_allowed_ips=true allowed_ip=0.0.0.0/0 ``` The AWG Windows implementation normally detects a default AllowedIP during interface configuration: ```go foundDefault4 := false for _, peer := range conf.Peers { for _, allowedip := range peer.AllowedIPs { if allowedip.Cidr == 0 { foundDefault4 = true } } } ``` and then: ```go if foundDefault4 { ipif.UseAutomaticMetric = false ipif.Metric = 0 } ``` But the configuration initially supplied by Amnezia contains no `[Peer]`. Therefore at initial interface configuration: ```text conf.Peers = empty foundDefault4 = false ``` and that full-tunnel interface metric setup is not performed. Amnezia later installs the route itself with route metric `0`, but that is not equivalent to setting the interface metric to `0`. ### 4. This gives a direct explanation for why `/1 + /1` fixes the connection Consider an ordinary physical default route: ```text 0.0.0.0/0 -> Ethernet/Wi-Fi ``` With the Amnezia config: ```text 0.0.0.0/0 -> AWG ``` both candidates have the same prefix length. Windows must then choose between them using route/interface preference. But if the config is changed to: ```text 0.0.0.0/1 -> AWG 128.0.0.0/1 -> AWG ``` every ordinary public IPv4 address matches an AWG `/1` and the physical interface only has `/0`. Longest-prefix routing wins before the default-route metric competition matters: ```text AWG /1 beats physical /0 ``` This makes the reported A/B result very significant: ```text 0/0 -> broken /1 + /1 -> works ``` It is exactly what I would expect if the AWG `/0` is losing a same-prefix route competition on that machine. ### 5. The Kill Switch then turns the routing bug from fail-open into fail-closed The Windows AWG path enables the firewall with the actual VPN interface index: ```cpp m_firewall->allowAllTraffic(); m_firewall->enableInterface(ifindex); ``` The firewall creates an explicit permit for the VPN interface: ```text FWPM_CONDITION_INTERFACE_INDEX == vpnAdapterIndex -> PERMIT ``` and `enablePeerTraffic()` creates block rules covering the configured VPN ranges. For a full-tunnel configuration that includes: ```text 0.0.0.0/0 ``` the intended model is effectively: ```text traffic routed through VPN adapter -> permitted traffic to VPN-covered destinations through another adapter -> blocked ``` Now combine that with the route selection above. Without enforcement: ```text Windows chooses physical /0 ↓ packet escapes through ISP ``` With Kill Switch: ```text Windows chooses physical /0 ↓ packet does not use permitted AWG interface ↓ WFP blocks it locally ↓ General failure / ERR_NETWORK_ACCESS_DENIED ``` So the Kill Switch may be exposing the underlying routing failure rather than causing it. This also explains a common diagnostic pattern: ```text Kill Switch OFF: Internet appears to work but traffic/DNS can leak Kill Switch ON: same incorrect physical route is now blocked so Internet stops completely ``` That is preferable to silently leaking, but the underlying route selection still has to be fixed. ### 6. One runtime snapshot can confirm this on the affected machine While connected with the failing `0.0.0.0/0` configuration: ```powershell Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -eq "0.0.0.0/0" Find-NetRoute -RemoteIPAddress 8.8.8.8 ``` The useful values are: ```text AWG interface index AWG InterfaceMetric AWG /0 RouteMetric physical interface index physical InterfaceMetric physical /0 RouteMetric winning route/interface for 8.8.8.8 ``` If the AWG `/0` exists but: ```text Find-NetRoute 8.8.8.8 ``` selects Ethernet/Wi-Fi, this report is runtime-confirmed. An especially useful A/B test is: ```text configuration A: 0.0.0.0/0 configuration B: 0.0.0.0/1 + 128.0.0.0/1 ``` and compare only: ```powershell Find-NetRoute -RemoteIPAddress 8.8.8.8 ``` If A chooses the physical adapter while B chooses AWG, the `/0` metric competition is isolated. ### 7. There is also an independent source-confirmed WFP DNS bug While looking at the Kill Switch implementation I found a separate deterministic problem. The helper used to permit the configured DNS server on port 53 builds one WFP filter containing: ```cpp conds[0]: FWPM_CONDITION_IP_PROTOCOL == IPPROTO_UDP conds[1]: FWPM_CONDITION_IP_PROTOCOL == IPPROTO_TCP conds[2]: FWPM_CONDITION_IP_REMOTE_PORT == 53 conds[3]: FWPM_CONDITION_IP_REMOTE_ADDRESS == DNS_SERVER ``` and then: ```cpp filter.numFilterConditions = 4; ``` WFP filter conditions are conjunctive. Therefore this filter requires one connection to be simultaneously: ```text UDP AND TCP AND port 53 AND the configured DNS address ``` which can never happen. So the intended high-priority rule: ```text Allow DNS-Server ``` cannot match either UDP DNS or TCP DNS. There is also a small type inconsistency: ```cpp conds[1].conditionValue.type = FWP_UINT8; conds[1].conditionValue.uint16 = IPPROTO_TCP; ``` although the larger logical problem is already the contradictory protocol conditions. ### 8. `blockTrafficOnPort()` contains the same protocol-condition mistake The generic: ```text Block all DNS ``` helper creates: ```cpp conds[0]: protocol == UDP conds[1]: protocol == TCP conds[2]: remote port == 53 ``` inside one filter. So that rule is also unsatisfiable as written. This means both sides of the intended explicit DNS policy are malformed: ```text explicit port-53 permit and explicit port-53 block ``` Both should instead create separate TCP and UDP filters. For example, conceptually: ```text filter 1: protocol = UDP remote port = 53 ... filter 2: protocol = TCP remote port = 53 ... ``` not: ```text protocol = UDP AND protocol = TCP ``` This is present in the reported `5.0.1.5` source and remains unchanged in current `dev`. I would treat this as a separate source-confirmed defect exposed while investigating #3098; it is not sufficient by itself to explain `ping 8.8.8.8 -> General failure`. ### 9. The routing fix should establish a postcondition, not just add another route For Windows full tunnel, the important invariant is: ```text AllowedIPs contains 0.0.0.0/0 => best route to an ordinary non-excluded public IPv4 uses the AWG LUID ``` Before reporting the tunnel healthy, something equivalent to: ```text GetBestRoute2(public destination) ``` should confirm that the result uses the AWG interface. The endpoint itself is the deliberate exception: ```text VPN server endpoint -> physical underlay ``` while: ```text ordinary public destination -> AWG ``` should always hold. For the current Windows AWG implementation, explicitly establishing: ```text UseAutomaticMetric = false InterfaceMetric = 0 ``` for a full-tunnel interface would restore the same interface invariant that `amneziawg-windows` normally applies when it sees a default AllowedIP in its initial configuration. Alternatively, preserve enough default-route intent in the startup configuration for `amneziawg-windows` to perform its normal setup, while continuing to keep route ownership in Amnezia if `Table=off` is required. ### 10. Suggested regression matrix #### Routing ```text physical default = /0 AWG AllowedIPs = /0 ``` Expected: ```text public best route = AWG ``` Test with: ```text Ethernet Wi-Fi PPP/PPPoE multiple adapters low physical interface metric ``` #### `/0` vs `/1` Both: ```text 0.0.0.0/0 ``` and: ```text 0.0.0.0/1 128.0.0.0/1 ``` must result in the same intended full-tunnel data plane. The `/1` workaround should not be required to overcome interface metric selection. #### Kill Switch With Kill Switch OFF: ```text ordinary public traffic must still use AWG ``` With Kill Switch ON: ```text ordinary public traffic must still use AWG and physical leakage must be blocked ``` Kill Switch must not be the component compensating for a wrong route winner. #### DNS Test separately: ```text UDP/53 to configured DNS TCP/53 to configured DNS UDP/53 to non-approved DNS TCP/53 to non-approved DNS ``` and verify the actual WFP filters match those flows. #### Failure mode Deliberately make the physical `/0` more attractive than the AWG `/0`. Expected: ```text activation corrects/rejects the route state ``` Forbidden: ```text Kill Switch OFF -> silent ISP leak Kill Switch ON -> General failure ``` ### Classification I would classify the source defects as confirmed on current `dev`. For this reporter specifically, I would call the `/0` metric path **highly consistent but requiring one `Find-NetRoute` snapshot for final runtime confirmation**. The key distinction is: **Kill Switch ON is probably not destroying an otherwise-correct tunnel. The `0.0.0.0/0` route can lose to the physical Windows default route because Amnezia sets only the route metric while its peerless startup prevents the normal AWG full-tunnel interface-metric setup. WFP then correctly blocks that wrongly selected physical path, turning a potential leak into `General failure`.** The `/1 + /1` workaround avoids the metric competition because those routes are more specific than the physical `/0`. Separately, the Windows WFP DNS permit/block helpers contain impossible `UDP AND TCP` conditions and should be fixed independently.

bsakaguchi referenced this issue

2026-10-13 21:21:10 +00:00

[PR #1436] [MERGED] bugfix: fixed mobile controllers initialization #2349

No labels

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

amnezia-vpn/amnezia-client#1436

No description provided.

Rows
Columns

[GH-ISSUE #3098] Kill Switch causes "General failure" / ERR_NETWORK_ACCESS_DENIED / infinite "Connection" status — while same server works perfectly with Windscribe's Kill Switch #1436

Problem Description

When Kill Switch is effectively ON:

When Kill Switch is effectively OFF (config manually edited):

Expected Behavior

Comparison with Windscribe

Questions

1. AllowedIPs is not the Kill Switch switch in Amnezia

2. /0 and /1 + /1 behave very differently in the Windows route table

3. Amnezia removes the Peer before starting the Windows tunnel service

4. This gives a direct explanation for why /1 + /1 fixes the connection

5. The Kill Switch then turns the routing bug from fail-open into fail-closed

6. One runtime snapshot can confirm this on the affected machine

7. There is also an independent source-confirmed WFP DNS bug

8. blockTrafficOnPort() contains the same protocol-condition mistake

9. The routing fix should establish a postcondition, not just add another route

10. Suggested regression matrix

Routing

/0 vs /1

Kill Switch

DNS

Failure mode

Classification

1. `AllowedIPs` is not the Kill Switch switch in Amnezia

2. `/0` and `/1 + /1` behave very differently in the Windows route table

4. This gives a direct explanation for why `/1 + /1` fixes the connection

8. `blockTrafficOnPort()` contains the same protocol-condition mistake

`/0` vs `/1`