[Bug] IPv6 link-local with zone causes packet re-entry loop #503
Description
Verify steps
- Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.
- I have searched on the issue tracker for a related issue.
Version
v2.6.0
What OS are you seeing the problem on?
Windows
Description
When sending a TCP request to an IPv6 link-local destination (e.g. fe80::/10) while specifying a zone that points to the wintun interface, the packet is picked up by tun2socks again and loops indefinitely.
After debugging, I traced this to the dialer’s setSocketOptions logic. The code checks IsGlobalUnicast and returns early for fe80::/10 addresses, which means we never bind the socket to the intended interface. As a result, the OS routes the packet out through the wintun adapter itself, and tun2socks re-captures it—creating an infinite loop.
CLI or Config
tun2socks -device wintun -proxy socks5://127.0.0.1:7890 -interface "WLAN 2"
Logs
2025-11-10T16:03:19.778+0800 INFO engine/engine.go:122 [DIALER] bind to interface: WLAN 2
2025/11/10 16:03:19 Using existing driver 0.14
2025/11/10 16:03:19 Creating adapter
2025-11-10T16:03:20.198+0800 INFO engine/engine.go:237 [STACK] tun://wintun <-> socks5://127.0.0.1:7890
2025-11-10T16:03:27.924+0800 INFO tunnel/udp.go:47 [UDP] 192.168.123.1:137 <-> 192.168.123.255:137
2025-11-10T16:03:27.924+0800 DEBUG tunnel/udp.go:64 [UDP] copy data for origin->remote: write udp [::]:50336->127.0.0.1:7890: wsasendto: The requested address is not valid in its context.
2025-11-10T16:03:51.502+0800 INFO tunnel/tcp.go:42 [TCP] [fe80::b3a5:48a:7ef6:48e1]:28962 <-> [fe80::e2bb:9eff:fe39:8933]:80
2025-11-10T16:03:51.509+0800 INFO tunnel/tcp.go:42 [TCP] [fe80::b3a5:48a:7ef6:48e1]:28964 <-> [fe80::e2bb:9eff:fe39:8933]:80
2025-11-10T16:03:51.512+0800 INFO tunnel/tcp.go:42 [TCP] [fe80::b3a5:48a:7ef6:48e1]:28966 <-> [fe80::e2bb:9eff:fe39:8933]:80
2025-11-10T16:03:51.514+0800 INFO tunnel/tcp.go:42 [TCP] [fe80::b3a5:48a:7ef6:48e1]:28968 <-> [fe80::e2bb:9eff:fe39:8933]:80
2025-11-10T16:03:51.515+0800 INFO tunnel/tcp.go:42 [TCP] [fe80::b3a5:48a:7ef6:48e1]:28970 <-> [fe80::e2bb:9eff:fe39:8933]:80
2025-11-10T16:03:51.517+0800 INFO tunnel/tcp.go:42 [TCP] [fe80::b3a5:48a:7ef6:48e1]:28972 <-> [fe80::e2bb:9eff:fe39:8933]:80
2025-11-10T16:03:51.519+0800 INFO tunnel/tcp.go:42 [TCP] [fe80::b3a5:48a:7ef6:48e1]:28974 <-> [fe80::e2bb:9eff:fe39:8933]:80
2025-11-10T16:03:51.520+0800 INFO tunnel/tcp.go:42 [TCP] [fe80::b3a5:48a:7ef6:48e1]:28976 <-> [fe80::e2bb:9eff:fe39:8933]:80
2025-11-10T16:03:51.522+0800 INFO tunnel/tcp.go:42 [TCP] [fe80::b3a5:48a:7ef6:48e1]:28978 <-> [fe80::e2bb:9eff:fe39:8933]:80
2025-11-10T16:03:51.523+0800 INFO tunnel/tcp.go:42 [TCP] [fe80::b3a5:48a:7ef6:48e1]:28980 <-> [fe80::e2bb:9eff:fe39:8933]:80
2025-11-10T16:03:51.525+0800 INFO tunnel/tcp.go:42 [TCP] [fe80::b3a5:48a:7ef6:48e1]:28982 <-> [fe80::e2bb:9eff:fe39:8933]:80
2025-11-10T16:03:51.526+0800 INFO tunnel/tcp.go:42 [TCP] [fe80::b3a5:48a:7ef6:48e1]:28984 <-> [fe80::e2bb:9eff:fe39:8933]:80
2025-11-10T16:03:51.527+0800 INFO tunnel/tcp.go:42 [TCP] [fe80::b3a5:48a:7ef6:48e1]:28986 <-> [fe80::e2bb:9eff:fe39:8933]:80
2025-11-10T16:03:51.529+0800 INFO tunnel/tcp.go:42 [TCP] [fe80::b3a5:48a:7ef6:48e1]:28988 <-> [fe80::e2bb:9eff:fe39:8933]:80
2025-11-10T16:03:51.530+0800 INFO tunnel/tcp.go:42 [TCP] [fe80::b3a5:48a:7ef6:48e1]:28990 <-> [fe80::e2bb:9eff:fe39:8933]:80
2025-11-10T16:03:51.531+0800 INFO tunnel/tcp.go:42 [TCP] [fe80::b3a5:48a:7ef6:48e1]:28992 <-> [fe80::e2bb:9eff:fe39:8933]:80
2025-11-10T16:03:51.533+0800 INFO tunnel/tcp.go:42 [TCP] [fe80::b3a5:48a:7ef6:48e1]:28994 <-> [fe80::e2bb:9eff:fe39:8933]:80
2025-11-10T16:03:51.534+0800 INFO tunnel/tcp.go:42 [TCP] [fe80::b3a5:48a:7ef6:48e1]:28996 <-> [fe80::e2bb:9eff:fe39:8933]:80
......How to Reproduce
- Run tun2socks on Windows with a wintun adapter.
- From the host, send a request to a link-local IPv6 address while specifying the wintun zone (interface index): curl -v http://[fe80::e2bb:9eff:fe39:8933%<wintun_ifindex>]:80/
- Observe the repeated TCP connections in tun2socks logs; the packet re-enters via wintun and loops.