mirror of
https://github.com/XTLS/Xray-core.git
synced 2026-10-01 05:25:43 +00:00
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>