Site-based split tunneling does not bypass VPN on Windows with VLESS/Xray

[yupic]

Describe the bug
On Windows, site-based split tunneling in VPN for all sites except selected IPs/sites mode may add excluded routes with the wrong interface when using Xray/VLESS.

The route destination and gateway are correct, but the route is bound to the Xray TUN interface (10.33.0.2) instead of the physical LAN/Wi-Fi interface (192.168.0.x). As a result, traffic that should bypass the VPN still goes through the VPN tunnel.

This also affects local network access. For example, even if 192.168.0.1 is excluded from VPN routing, access to the local router may still be routed through the VPN and become unavailable.

To Reproduce
Steps to reproduce the behavior:

1. Use AmneziaVPN on Windows with an Xray/VLESS connection.
2. Enable site-based split tunneling.
3. Select the mode VPN for all sites except selected IPs/sites.
4. Add a local network IP or subnet to exclusions, for example:
   • 192.168.0.1/24
   • or another IP/subnet that should go directly through the LAN gateway.
5. Connect to VPN.
6. Check the Windows routing table with:

   route print

7. Observe that the excluded route may have the correct gateway but the wrong interface.

Example of broken route:

Network Destination        Netmask          Gateway       Interface  Metric
     192.168.0.0    255.255.225.0      192.168.0.1      10.33.0.2      6

The gateway is the physical router, but the interface is the Xray TUN address.

Expected behavior
Excluded IPs/sites should be routed through the physical network interface, not through the Xray TUN interface.

Expected route example:

Network Destination        Netmask          Gateway       Interface  Metric
     192.168.0.0    255.255.225.0      192.168.0.1      192.168.0.5      6

Traffic to excluded IPs, including local router addresses such as 192.168.0.1, should bypass VPN completely.

Log files

Not necessary.

Screenshots

Not necessary.

Desktop (please complete the following information):

• OS: Microsoft Windows 11 Home Single Language
• OS version: 10.0.26200.8246, Build 26200, 25H2
• Architecture: x64
• AmneziaVPN Version: 4.8.14.5 or 4.8.15.4
• AmneziaVPN Service Version: 4.8.14.5 or 4.8.15.4
• Protocol: VLESS

Smartphone (please complete the following information):

Not applicable.

Server (please complete the following information):

Not applicable / Xray/VLESS connection profile.

Additional context

The issue is likely in:

service/server/router_win.cpp, RouterWin::routeAddList()

In version 4.8.14.5, lines 82-87:

// Set iface for route
IPAddr dwGwAddr = inet_addr(gw.toStdString().c_str());
if (GetBestInterface(dwGwAddr, &ipfrow.dwForwardIfIndex) != NO_ERROR) {
    qDebug() << "Router::routeAddList : GetBestInterface failed";
    return false;
}

The route interface is selected with GetBestInterface(gw). When Xray/VLESS TUN is already active, Windows may return the Xray TUN interface (10.33.0.2) as the best interface for the gateway. This creates routes where the gateway is correct, but the interface is wrong.

A possible fix is to resolve the interface by matching the requested gateway against adapter gateways from GetAdaptersAddresses(..., GAA_FLAG_INCLUDE_GATEWAYS, ...), and only fall back to GetBestInterface() if no matching adapter is found.