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>
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>
* Proxy: Implement tun raw network interface inbound support for Linux
* Proxy: Tun. Include "android" as build condition for build of tun_default implementation
* Proxy: Tun. Add .Close() cleanup calls to Handler.Init() where needed
* Proxy: Add Tun for Android
* Proxy: Tun. Implement Windows support
---------
Co-authored-by: yuhan6665 <1588741+yuhan6665@users.noreply.github.com>
