Conversation
Match non-loopback traffic in the IPv6 address-family WFP block so local services remain reachable without allowing external IPv6. Keep the existing DNS filters and other WFP policies in effect. Add opt-in Windows integration coverage with a separate client executable to avoid the TUN owner's application-ID exemption.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a Windows TUN uses
AutoRouteandStrictRoutewithout an IPv6 address, itsblock ipv6WFP filter also blocks connections to::1. This breaks local services such as Unreal Engine's Zen DDC even though no traffic needs to leave the host.Exclude loopback traffic from that address-family block using
FWPM_CONDITION_FLAGS,FWP_MATCH_FLAGS_NONE_SET, andFWP_CONDITION_FLAG_IS_LOOPBACK. This narrows the existing block instead of installing a higher-priority permit: the separate DNS filters and other WFP policies still apply. No configuration option, process allowlist, filter priority, or IPv4 behavior is changed.Microsoft documents the loopback condition at ALE_AUTH_CONNECT_V6 and the flags-none-set match type.
Reproduction
Reproduced on Windows 11 Pro 25H2, build 26200.9168, using the official rolling Alpha available on 2026-09-09:
The downloaded
mihomo-windows-amd64-compatible-alpha-d5f57a5.zipmatched the release's SHA-256 checksum:d35f1104d9b10707a3fe12815b0bc4b64c5d27f6ec8f12da9a26fb2b66a89ee5.python -m http.server 18559 --bind ::1 --directory <empty-test-directory>.curl.exe --noproxy "*" --max-time 3 http://[::1]:18559/succeeds.mihomo.exe -d <test-directory> -f repro.yaml, using the configuration below.WSAEACCES(10013). The patched build returns HTTP 200. Stop the test core and the original connection works again.The limited route and separate address range keep the test from taking over the default IPv4 route; the bug is in WFP filtering, not traffic routed through the test TUN. No subscription, remote proxy, DNS lookup, or UE installation is required.
Validation
The new opt-in integration test exercises the actual Windows TUN/WFP implementation. It launches the socket client from a different executable path, because the TUN owner's application ID is already exempt and testing from that same executable would produce a false positive. It verifies working loopback before filter installation and after cleanup.
Run in an elevated PowerShell on a test host, without another TUN's IPv6 block:
The test installs temporary system-wide WFP filters and an IPv4 test adapter, so it is skipped unless explicitly enabled. It closes the adapter/session and removes the copied client on completion.
2001:db8::1)::1, through the complete Mihomo buildThe integration test was first run against unmodified
0810e156517643a725978af03a48356382255d5eand failed on the IPv6 TCP/UDP loopback cases; the same test passed with this fix. End-to-end checks also used Mihomod5f57a5e290eafd77a2b28d8db36e3bd70071398built with Go 1.26.8 andwith_gvisor, replacing only the sing-tun module with0810e15or0810e15plus this fix. Both the official binary and the locally built unpatched control reproduced the failure.Other checks:
go build .,go build -tags with_gvisor .,go vet ., andgo test -v .passed (Go 1.24.5; normal test invocation skips the opt-in test).go build .cross-compilation passed; runtime testing was amd64 only.gofmt,gofumptandgit diff --checkpassed for the changed files.go test ./...is not green on this Windows host. An unmodified parent worktree reproduces the existing Darwin-only internal-package build failures andinternal/winipcfgtest%wvet errors; the host's normal IPv6 block also causes existing ping tests to time out. These are outside this patch.Test-host limitation: an existing Clash instance remained running to preserve connectivity, with only its own
strict-routetemporarily disabled during each isolated test and restored afterward. Its configuration was not used by the tested core. These are controlled before/during/after checks, not a clean-machine test or a comprehensive IPv6 leak audit. An external UDPsendreturning successfully was not treated as evidence of delivery or allowed egress.Official Alpha: complete stdout and stderr
Patched Mihomo: complete stdout and stderr
Integration regression: before the production fix
Integration regression: after the production fix