shadowsocks-rust: outbound_bind_interface does not work on Windows 10

Hi!

I am trying to set up Wireguard with ShadowSocks and facing the following issue.

sslocal version 1.15.4msvc shadowsocks-v1.15.4.x86_64-pc-windows-msvc.zip

I need sslocal to be bound to my primary Windows connection (named WiFi), as otherwise once Wireguard starts, sslocal starts using its interface to send packages to ssserver via it.

But when I set "outbound_bind_interface":"WiFi" in my config, I get the following error. Same happens if I use “outbound_bind_interface”:“Intel® Dual Band Wireless-AC 8265” instead:

2023-08-09T23:44:27.025505400+04:00 ERROR [19256:23028] [shadowsocks::net::sys::windows] if_nametoindex WiFi fails
2023-08-09T23:44:27.026593300+04:00 ERROR [19256:23028] [shadowsocks_service::local::net::udp::association] udp relay 127.0.0.1:51820 -> 127.0.0.1:51820 (proxied) with 148 bytes, error: invalid interface name

The only workaround I was able to use is setting a static route in Windows: route -p add <server_ip> MASK 255.255.255.255 192.168.50.1

Here are my logs and configs:

  1. sslocal config:
{
    "server":"<server_ip>",
    "server_port":8388,
    "password":"<password>",
    "method":"aes-256-gcm",
    "fast_open": false,
    "outbound_bind_interface":"WiFi",
    "locals": [
        {
            "mode":"udp_only",
            "protocol":"tunnel",
            "forward_address":"127.0.0.1",
            "forward_port":51820,
            "local_address":"0.0.0.0",
            "local_port":1080
        }
    ]
}
  1. Interfaces
PS C:\Users\v_iushmanov> wmic nic get name, index, NetConnectionID
Index  Name                                         NetConnectionID
0      Microsoft Kernel Debug Network Adapter
1      Hyper-V Virtual Switch Extension Adapter
2      Hyper-V Virtual Ethernet Adapter             vEthernet (Default Switch)
3      Hyper-V Virtual Switch Extension Adapter
4      Kaspersky Security Data Escort Adapter       Ethernet 3
5      Wintun Userspace Tunnel                      OpenVPN Wintun
6      TAP-Windows Adapter V9                       Local Area Connection
7      Intel(R) Dual Band Wireless-AC 8265          WiFi
8      Realtek PCIe GBE Family Controller           Ethernet
9      Microsoft Wi-Fi Direct Virtual Adapter
10     WAN Miniport (SSTP)
11     WAN Miniport (IKEv2)
12     WAN Miniport (L2TP)
13     WAN Miniport (PPTP)
14     WAN Miniport (PPPOE)
15     WAN Miniport (IP)
16     WAN Miniport (IPv6)
17     WAN Miniport (Network Monitor)
18     Microsoft Wi-Fi Direct Virtual Adapter #2    Local Area Connection* 10
19     TAP-ProtonVPN Windows Adapter V9             Local Area Connection 2
20     Bluetooth Device (Personal Area Network) #2  Bluetooth Network Connection 2
21     ProtonVPN Tunnel                             ProtonVPN TUN
22     VirtualBox Host-Only Ethernet Adapter        VirtualBox Host-Only Network
23     Hyper-V Virtual Ethernet Adapter #2          vEthernet (WSL)
24     RAS Async Adapter
26     TAP-Windows Adapter V9 for OpenVPN Connect   Local Area Connection 3

On my Ubuntu desktop, “outbound_bind_interface” works perfectly fine with the same config (another interface name, obviously) and solves the problem with traffic routing.

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 27

Commits related to this issue

Most upvoted comments

Yey, you did it! It now works like a charm 😃

image

So, yeah, only after your comments and adding the htonl() convertion, I finally inderstand what they meant here:

The input value for setting this option is a 4-byte IPv4 address in network byte order. This DWORD parameter must be an interface index in network byte order. Any IP address in the 0.x.x.x block (first octet of 0) except IPv4 address 0.0.0.0 is treated as an interface index. An interface index is a 24-bit number, and the 0.0.0.0/8 IPv4 address block is not used (this range is reserved).

This is indeed ridiculous API, classic MS bs.

Thank you so much for your time and persistence 😃

// Interface index is in network byte order for IPPROTO_IP.

// Interface index is in host byte order for IPPROTO_IPV6.

This is the most stupid API I have seen in my life.

https://github.com/microsoft/ctsTraffic/blob/4fe77d045fd69573d7f4056fe7ac73182b802fb1/ctsTraffic/ctsConfig.cpp#L4085-L4100

I just found a reference implementation… The index have to be in network endian!!!