Bypass Iran rules cause routing loop in Tun mode

[pulsarice]

Operating system

Windows

System version

11 25H2 10.0.26200.8117

Installation type

zip

Version

1.1.2

Description

I created a clean copy of Throne then added a socks proxy socks5://192.168.1.50:10808#Socks
The server is running on another host in my local network.
The only changes that were made are DNS: udp://8.8.8.8 and downloaded profile Bypass_Iran.
Then started throne in Tun mode.
accessing foreign servers are fine. but accessing any Iranian website causes massive routing loop and high cpu usage.
To test I issued a single request using this command:
curl --socks5-hostname 127.0.0.1:2080 https://myadd.ir

The log file is very large. please see from line 96 onwards.
Bypass_iran.log

Note that using Proxy mode has no issues, it only happens in Tun mode.

This is the looped part:

INFO[0005] [1930231768 0ms] inbound/mixed[mixed-in]: inbound connection from 127.0.0.1:51672
INFO[0005] [1930231768 0ms] inbound/mixed[mixed-in]: inbound connection to myadd.ir:443
INFO[0005] [1930231768 0ms] router: found process path: C:\Users\***\Software\Tools\curl\curl.exe
DEBUG[0005] [1930231768 0ms] router: match[4] inbound=[mixed-in tun-in] => sniff
DEBUG[0005] [1930231768 2ms] router: sniffed protocol: tls, domain: myadd.ir
DEBUG[0005] [1930231768 2ms] router: match[7] rule_set=[geoip-ir geosite-ir] => route(direct)
INFO[0005] [1930231768 2ms] outbound/direct[direct]: outbound connection to myadd.ir:443
DEBUG[0005] [1930231768 2ms] dns: lookup domain myadd.ir
DEBUG[0005] [1930231768 11ms] dns: exchanged myadd.ir NOERROR 0
DEBUG[0005] [1930231768 20ms] dns: exchanged myadd.ir NOERROR 30
DEBUG[0005] [1930231768 35ms] dns: exchanged A myadd.ir. 30 IN A 185.231.65.63
DEBUG[0005] [1930231768 35ms] dns: lookup succeed for myadd.ir: 185.231.65.63
INFO[0005] router: found process path: C:\Throne\ThroneCore.exe
INFO[0005] [3049139582 0ms] inbound/tun[tun-in]: inbound connection from 192.168.1.3:51673
INFO[0005] [3049139582 0ms] inbound/tun[tun-in]: inbound connection to 185.231.65.63:443
INFO[0005] [3049139582 0ms] router: found process path: C:\Throne\ThroneCore.exe
DEBUG[0005] [3049139582 0ms] router: match[3] process_path=C:\Throne\ThroneCore.exe => route(direct)
INFO[0005] [3049139582 0ms] outbound/direct[direct]: outbound connection to 185.231.65.63:443
INFO[0005] router: found process path: C:\Throne\ThroneCore.exe
INFO[0005] [1086738790 0ms] inbound/tun[tun-in]: inbound connection from 192.168.1.3:51674
INFO[0005] [1086738790 0ms] inbound/tun[tun-in]: inbound connection to 185.231.65.63:443
INFO[0005] [1086738790 0ms] router: found process path: C:\Throne\ThroneCore.exe
DEBUG[0005] [1086738790 0ms] router: match[3] process_path=C:\Throne\ThroneCore.exe => route(direct)
INFO[0005] [1086738790 0ms] outbound/direct[direct]: outbound connection to 185.231.65.63:443
INFO[0005] router: found process path: C:\Throne\ThroneCore.exe
INFO[0005] [3254445648 0ms] inbound/tun[tun-in]: inbound connection from 192.168.1.3:51675
INFO[0005] [3254445648 0ms] inbound/tun[tun-in]: inbound connection to 185.231.65.63:443
INFO[0005] [3254445648 0ms] router: found process path: C:\Throne\ThroneCore.exe
DEBUG[0005] [3254445648 0ms] router: match[3] process_path=C:\Throne\ThroneCore.exe => route(direct)
INFO[0005] [3254445648 0ms] outbound/direct[direct]: outbound connection to 185.231.65.63:443

Routing profile

[{
    "action": "hijack-dns",
    "protocol": "dns"
}
,{
    "action": "route",
    "ip_is_private": true,
    "outbound": "direct"
}
,{
    "action": "route",
    "outbound": "direct",
    "rule_set": [
        "geoip-ir",
        "geosite-ir"
    ]
}
]

Default outbound

proxy

URL list

https://myadd.ir - proxy

[pulsarice]

Enable Tun Routing fixes the issue but adds a large routing table and can potentially cause other problems.

Changing the Tun stack had no effect.

[AS7RIDENIED]

+1
Experiencing this since v1.1.0 but got too lazy to create an issue. It occurs only if you have Tun Routing on, Strict Route off and your routing profile have an processName or processPath rules (Enabling Strict route preventing it from happen)

It also crunches like 10% of my cpu when all connections fall to timeout, causing troubles sometime ;c

[pulsarice]

Mine happens with default settings (Strict route ON and Tun routing OFF)

[Mahdi-zarei]

I cannot reproduce it. The logs also show something very weird, as if the binding to interface function is not working at all. Are you using any other VPN clients at the same time on the same machine?

[pulsarice]

No, not at the same time.
I also tried disabling OpenVPN adapters and stopping its services and also warp service.
But it didn't help.
I also can confirm this issue started after recent versions.

But interestingly, I tried running the same version and configuration in Windows Sandbox (VM) and it didn't happen this time. So it might be some type of conflict in my system.

[pulsarice]

I exported the sing-box config, edited this part

            {
                "action": "route",
                "outbound": "direct",
                "process_path": "C:\\Throne\\sing-box.exe"
            }

and ran sing-box version 1.13.7 binary with that config. the same problem happens when accessing "Direct" domains. so it seems that it's not a Throne issue.

[Mahdi-zarei]

If it is reproducible with sing-box too, then I suggest you create an issue with detailed information on the sing-box repo. The logs also indicate that most likely it is the traffic going out from the direct outbound that is coming back again, which should not happen unless auto_detect_interface is broken on some environments.

[pulsarice]

Thank you for your time.
Is this line related to detecting the default interface via auto_detect_interface?

INFO[0000] network: updated default interface LAN, index 18

[Mahdi-zarei]

No not really, it is simply detecting it. the auto_detect_interface's functionality is to bind to the default interface on outgoing connections and prevent a loop when using auto_route, which apparently is not working here.

[pulsarice]

I ran these two commands and restarted Windows.
The problem is fixed now!

netsh int ip reset
netsh winsock reset