BUG: Impact of proxied traffic on non-proxied traffic in TUN mode

[SPIRIT-00]

Describe the problem

When TUN turned on some traffic can have impact on non-proxy traffic (or it core/program logic/tun-interface trouble idk). At now it's problem been noticed by some users, include my friend. The reproduction cases are not obvious, so far I only have one stable reproduction from a friend.

Actual behavior:

• Default outbound is direct
• TUN mode on
• Routing settings: proccess_name - Discord.exe - proxy, rule_set - discord_SITE - proxy
• VLESS + TCP + TLS
• xudp - on
• mux - disabled
• Strict Route - on
• Stack - gvisor
• MTU - 1500
• last version of NekoBox (anyway work on any version, pobably, and on other forks)

When proxyfied traffic get stuck or package lost, or connection troubles, not proxied traffic stops or something like that. Mean if Discord's stream drop packets game that use direct connection have troubles like hi ping (1-3k) on few sec.

How to reproduce

• Use proxyfied Discord
• Use game like CS or Dota with ingame ping monitoring that not proxied

If use only voice all is ok.

• Start stream and wait connection trouble on stream. When stream have trouble game in 90% case have high ping. After off stream all be ok.

I've discuss about it in vpn chat, some has similar trouble. By info from chats disabling "internal TUN" helps. In this fork this setting not exist.

Unfortunately i can't test it on my laptop, because not have any games with network activity. But if need test with feedback maybe a found it, i hope...

log

--

[Mahdi-zarei]

First of all, you can use system DNS to handle discord filtering in Iran. Second, what you describe is clearly a bandwidth exhaustion case, you start sharing your screen, your max bandwidth is less than what is needed for the stream, you get a high ping, same as when people start downloading on the same network that you are playing and the network gets congested. This has nothing to do with the VPN, it would also happen even if you were sharing your screen using something like skype that is not filtered as well.

[SPIRIT-00]

Thanks for response. I not from Iran. But Discord also blocked in country.

About second part, i think it is not, because if in parallel to watch any twitch or youtube video without any problem even 2-4k. If use bypass methods like GoodByeDPI problem not exist.

Also, by info from chat disabling "internal TUN" option also helps. (but i can't approve at now)

I understand how it looks, but until I saw it with my own eyes (on stream demonstration with Discord + TUN and game and Discord + GoodByeDPI and game) I didn't believe it either, because at the moment I don't understand the logic of how the problem of proxied traffic is connected with the direct traffic of other applications. Can there be any assumptions? That the lack of response inside the tunnel suspends some processes in the program/core?

[Mahdi-zarei]

I can't exactly say whether this can be possible or not, but if it is, it is a problem with sing-box and not nekoray. Nekoray simply builds the config and passes it to the sing-box core. I can suggest one thing though, test if your upload speed is high enough without Tun mode. There is also a rare possibility that your entire connection gets throttled when you upload too much data using certain methods (caused by your country's DPI system). But I cannot say anything for sure. If you have more evidence, I suggest you submit and issue in sing-box's repo with enough information.

[SPIRIT-00]

Anyway thanks for response!

[Mahdi-zarei]

If you are using windows I suggest you set discord_SITE ruleset in hijack settings and use system DNS to bypass discord censorship without the need to use TUN over the entire network.

[SPIRIT-00]

It works, but voice not work without TUN. It also cause why we start use TUN. Before we use default port listening.

[Mahdi-zarei]

Then it seems the filtering is different than that of iran, in iran the IPs where RTC connects to are not filtered, but the domains are.

[SPIRIT-00]

Yep, they also blocks IPs. For most cases ports listening or system DNS works perfect. But if application use udp it not work because, idk why, udp still try go direct even if use socks5 proxy in browser, or hijack. Only TUN can fix it. My knowledge is not sufficient to find another solution. But thanks for responces about it!

[SPIRIT-00]

For info if anyone interested how I avoided this trouble without TUN:

1. I make custom inbound in NekoBox, that listen 2079 port and have "force_proxy" tag.
2. I created rule that force proxyfied inbound with "force_proxy" tag.
3. I use ProxiFyre to catch apps activity in network stack and redirect it trafic into 2079 port.

Works perfect. And default inbound NekoBox i use for browser with route rules on 2080 port. ProxiFyre also works as system service and starts with system. If i nedd update config i just edit app-config.json file and restart service via bat file. Bat file placed near proxifyre.exe.

Discord voice also works.

Custom inbound:

{
    "inbounds": [
        {
            "domain_strategy": "prefer_ipv4",
            "listen": "127.0.0.1",
            "listen_port": 2079,
            "set_system_proxy": false,
            "sniff": true,
            "sniff_override_destination": false,
            "sniff_timeout": "300ms",
            "tag": "force_proxy",
            "tcp_fast_open": false,
            "tcp_multi_path": false,
            "type": "mixed",
            "udp_disable_domain_unmapping": false,
            "udp_fragment": false,
            "udp_timeout": "5m",
            "users": [
            ]
        }
    ]
}

Rule:

{
    "inbound": [
        "force_proxy"
    ],
    "outbound": "proxy"
}

ProxiFyre config:

{
    "logLevel": "None",
    "proxies": [
        {
            "appNames": [
                "Discord.exe",
                "notepad++.exe",
                "GUP.exe",
                "GitHubDesktop.exe",
                "git-remote-https.exe",
                "C:\\Users\\MyUser\\AppData\\Local\\GitHubDesktop\\Update.exe"
            ],
            "socks5ProxyEndpoint": "127.0.0.1:2079",
            "supportedProtocols": [
                "TCP",
                "UDP"
            ]
        }
    ]
}

Bat file for restart ProxiFyre as system service:

cd /d "%~dp0"
ProxiFyre.exe stop
timeout 10
ProxiFyre.exe start