The autoSystemWfpBlockLeak value that blocks an IP version not routed to
the TUN, as asked in review; "misconfig" was never released.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
autoSystemWfpBlockLeak now takes ["dns", "misconfig"] instead of true:
"dns" keeps DNS inside the TUN, and "misconfig" blocks an IP version
that no route leads to the TUN, the leak of a configuration that routes
only one of them. Either can be used alone, e.g. ["dns"] to block DNS
leaks while an IP version stays out of the TUN on purpose. Unknown
values are rejected. The config field becomes a repeated string with
the same number; it was never released.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Without an IPv4 address in gateway, the system DNS now points at the
first IPv6 gateway plus one (e.g. fc00::1/64 -> fc00::2) instead of
nothing, and the routing check before the takeover accepts IPv6
addresses for it.
The README also says what each system does without gateway: Xray
assigns no address on Linux, Windows gives the TUN link-local ones
itself, and macOS and FreeBSD use 169.254.10.1/30.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
autoSystemWfpBlockLeak blocked IPv6 when the TUN had no IPv6 address or
no IPv6 route, and IPv4 never: with only IPv6 routed to the TUN, IPv4
went around it. Now each IP version is blocked when no route of it leads
to the TUN, except for loopback, DHCP, IPv6 neighbor and multicast
listener discovery, and Xray itself.
Addresses no longer count: without one of a version in gateway, Windows
gives the TUN a link-local one itself (fe80:: at once, 169.254.x.x after
some seconds), and what is routed to the TUN goes through it with that,
so a TUN with IPv6 routes but no IPv6 address had its IPv6 blocked for
nothing.
Tested on Windows 11, elevated: with only IPv6 routed, other programs'
IPv4 is denied, while loopback, a DHCP renew of Wi-Fi and Xray still
work; without gateway, IPv4 and IPv6 routed to the TUN enter it from
169.254.x.x and fe80::.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
autoSystemWFP becomes autoSystemWfpBlockLeak, saying that the WFP filters
block leaks, and autoSystemDNS becomes autoSystemDnsToGateway, saying
where it points the system DNS, so that pointing the system DNS at the
gateway on Windows later would fit the same name. Their config fields
keep their numbers; neither was released.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
It only turns on the Windows Filtering Platform filters, along with Xray
resolving its own lookups while they restrict DNS, so it is named after
what it sets up in the system, like autoSystemRoutingTable and
autoSystemDNS. The config field becomes auto_system_wfp, with the same
number; strictRoute was never released.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With strictRoute, only port 53 was kept inside the TUN. But Windows' DNS
Client service sends the queries for an interface's DNS servers out
through that interface, whatever the routes say, and since Windows 11
and Server 2022 it may send them over HTTPS or TLS, when that is set up
for the interface (as Windows Settings does) or for the server. Those
left through the physical link.
On those versions, the DNS Client service may now only connect through
the TUN, except for its mDNS and LLMNR. The filters recognize the
service by its SID in the token of its process, as Windows Firewall's
own rules for it do. Earlier versions only query port 53, and may run
the service in one process with others, so they get no such filters.
The port 53 rule stays, for the programs that query a resolver on the
local network themselves, and for those earlier versions.
Tested on Windows 11, elevated: with DoH set on Wi-Fi per adapter, per
network profile or by global auto-upgrade, none of the DNS Client's
connections left through Wi-Fi (WFP logged the drops by the new filter),
names still resolved through the TUN, mDNS and LLMNR still went out, and
other programs were unaffected, also in a real Xray run.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Like sing-box's strict_route, strictRoute is now false by default, so the
Windows Filtering Platform filters are only added when it is set to true
(together with autoSystemRoutingTable). With unset meaning false,
strict_route becomes a plain bool field.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Windows sends name queries to the DNS servers of all interfaces, and a
resolver on the local network (e.g. 192.168.1.1 from DHCP) is reached
through its more specific LAN route instead of the TUN, so DNS leaks
past it. IPv6 bypasses a TUN that cannot carry it.
With autoSystemRoutingTable set, the Windows TUN now adds Windows
Filtering Platform filters, all in one transaction and in a dynamic
session, so that they are removed when Xray exits, even if it crashes:
- DNS (port 53) only goes through the TUN, in both directions: its local
address, and the interface it leaves or arrives by, must be the TUN's.
- IPv6 is blocked in both directions when the TUN has no IPv6 address or
no IPv6 route, except loopback, neighbor and multicast listener
discovery, and DHCPv6.
- Xray's own traffic is exempt: its connections out with a hard permit,
which Windows Firewall rules do not override (like sing-box's
strict_route), connections to its inbounds with an ordinary one.
If the filters cannot be added, the TUN does not start on Windows 10 and
later (only a warning on 7/8). The new `strictRoute` option (true by
default) turns them off.
Also on Windows:
- A warning for `dns` servers outside gateway and autoSystemRoutingTable,
as queries to them cannot go through the TUN and are blocked.
- While DNS is restricted and autoOutboundsInterface is in use, Xray
resolves the names it would ask Windows for itself (Go's resolver on
its own sockets). Those lookups and the `localhost` DNS server skip the
TUN's DNS servers, unless another interface uses them too, instead of
looping back into the TUN.
- The DNS cache is flushed when the TUN starts and stops, and DNS
registration is turned off on the TUN (through netsh before Windows 10
1809).
- Close no longer panics when registering the route or interface change
callbacks failed.
The README's Windows section describes all of it.
Tested on Windows 11, elevated, amd64 and 386: the filters, DNS arriving
through a real Wintun adapter and blocked outside it, the IPv6 block,
Windows Firewall rules, and a real Xray run. Windows 7/8 and Windows 10
before 1809 are untested.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
