The GFW of china does do HTTP SNI DPI Detection of the softetherVPN protocol and actively probe and block them
So here's my question:
1.If Softether VPN project adds a function to hide as SNI/http client hello handshakes in the softether vpn protocol using a plugin in the software,then even if the DPI scanner of the firewall do active probing,but because there's no identical handshakes or SNI parterns for them to block and do tcp blocking,this make it harder for DPI firewalls like in china & iran to stop the softether vpn protocol
2.Just like the project v2ray shadowsocks,it implements obfuscation and customize strings and keys for client/server encryption,but softether seems using the old AES-128 at all times,if the DPI just scans the header of the http/s get/post string and the client hello data,it can block the connection in real time,so what if softether also implements such custom strings and keys function into the software itself in the future?
3.Note that currently it's impossible for a DPI firewall to stop a connection based on shadowsocks/v2ray in a real scenario,all traffic just like a normal https session but all identical information are obfuscated and cannot read in a readable ASCII form of text,the DPI firewall now only block ip address very rudely based on IP CIDR range and AS Number,notice the word RUDELY,because it's neither AI or machine learning to do the blocking,the method behind the tcp and ip blackholing is just very rudely implemented
The GFW of china does do HTTP SNI DPI Detection of the softetherVPN protocol and actively probe and block them
-
oscar
- Posts: 51
- Joined: Tue Oct 21, 2025 1:34 am
-
solo
- Posts: 1747
- Joined: Sun Feb 14, 2021 10:31 am
Re: The GFW of china does do HTTP SNI DPI Detection of the softetherVPN protocol and actively probe and block them
In the context of SoftEther's VPN Gate project, all counter-detection features are completely useless because the servers' IPs are openly available on the website.
If you need an undetectable SoftEther then simply use its "Connect via SOCKS Proxy Server" option to a local Shadowsocks which in turn connects to a Shadowsocks server on a VPS somewhere else.
Btw SoftEther works very well with "tor expert bundle" on localhost:9050
If you need an undetectable SoftEther then simply use its "Connect via SOCKS Proxy Server" option to a local Shadowsocks which in turn connects to a Shadowsocks server on a VPS somewhere else.
Btw SoftEther works very well with "tor expert bundle" on localhost:9050
-
oscar
- Posts: 51
- Joined: Tue Oct 21, 2025 1:34 am
Re: The GFW of china does do HTTP SNI DPI Detection of the softetherVPN protocol and actively probe and block them
The DPI firewall just because unable to block https protocol data,it choose to brutally TCP-Cut-OFF the connection nationally wide instead,this isn't about DPI firewall it just brutally TCP-Cuf-OFF an IP address without even having the need to do DPI at the first placesolo wrote: ↑Sun Nov 16, 2025 1:49 pmIn the context of SoftEther's VPN Gate project, all counter-detection features are completely useless because the servers' IPs are openly available on the website.
If you need an undetectable SoftEther then simply use its "Connect via SOCKS Proxy Server" option to a local Shadowsocks which in turn connects to a Shadowsocks server on a VPS somewhere else.
Btw SoftEther works very well with "tor expert bundle" on localhost:9050
-
oscar
- Posts: 51
- Joined: Tue Oct 21, 2025 1:34 am
Re: The GFW of china does do HTTP SNI DPI Detection of the softetherVPN protocol and actively probe and block them
Connect via SOCKS Proxy Server just unnecessarily adds another RTT+1 to the server,this is nothing as it's equal to connect using v2ray or some 3rd party clients,so i mean if softether implement a v2ray-like protocol for the version "SoftEther DPI Enchanced v6"in the session tcp level,then softether can works the same just as v2ray or some 3rd party apps does,this is a architecture change for the entire softether protocol,and currectly i don't think official developer can accept it,i can write such plugin-s but however as if it's widespread it can still detected by national wide DPI's,so simply put it works as only if it's widespread in the developers circles of people not web-wide public list addresses books like vpngate.net didsolo wrote: ↑Sun Nov 16, 2025 1:49 pmIn the context of SoftEther's VPN Gate project, all counter-detection features are completely useless because the servers' IPs are openly available on the website.
If you need an undetectable SoftEther then simply use its "Connect via SOCKS Proxy Server" option to a local Shadowsocks which in turn connects to a Shadowsocks server on a VPS somewhere else.
Btw SoftEther works very well with "tor expert bundle" on localhost:9050
-
oscar
- Posts: 51
- Joined: Tue Oct 21, 2025 1:34 am
Re: The GFW of china does do HTTP SNI DPI Detection of the softetherVPN protocol and actively probe and block them
NAT-T and UDP hole punching do works all the times,but there's a big disadvantage of using the client without having the option to manaully forcefully turn NAT-T on enabled=True,UDP turned on enabled=True,just because DPI firewalls unlikely to have stun.nextcloud.com and stun.cloudflare.com domains being blocked/DNS poisoned.
Of course the authors of softether already knows how everything just works,but they choose not to implement the feature to forcefully turn NAT-T on enabled=True with an GUI on client regardless NAT-T is registered on softether.net DDNS or not,it doesn't metter at all,so does the same UDP hole punching feature does.
I can have them forcefully turned on=True,but this is only working under a controlled lab environment not the public TCP/IP environment,so it do work in my lab,but doesn't works for people staying outside the public TCP/IP network
Of course the authors of softether already knows how everything just works,but they choose not to implement the feature to forcefully turn NAT-T on enabled=True with an GUI on client regardless NAT-T is registered on softether.net DDNS or not,it doesn't metter at all,so does the same UDP hole punching feature does.
I can have them forcefully turned on=True,but this is only working under a controlled lab environment not the public TCP/IP environment,so it do work in my lab,but doesn't works for people staying outside the public TCP/IP network
