All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Masking home residential exit node tunnel signature (US -> EU) to beat strict DPI
Baobeiforever
Member
Hey everyone,
I'm working on a long-distance hardware routing configuration and need some high-level networking advice to defeat deep packet inspection (DPI) fingerprinting.
The Infrastructure:
- Server Side: A GL.iNet Brume 2 running as a residential gateway on a clean consumer broadband line in the states.
- Client Side: A remote user physically located in Europe, connecting back to the US base. We are testing via a GL.iNet travel router hardware tunnel, as well as mobile endpoints running Shadowrocket.
- Current Stack Tested: WireGuard, Tailscale, standalone Shadowsocks.
The Problem:
When verifying the connection against basic IP fraud/database checkers, the IP resolves flawlessly to a clean home ISP pool (no hosting or datacenter flags). However, when hitting strict threat intelligence platforms (like IPQS), the system successfully fingerprints the active tunnel over this long distance and flags "Proxy: True".
The endpoint client environment is fully hardened (hardware GPS disabled, local system time zone/region/language matched to the US server side, IPv6 off). This proves the signature leak is entirely happening at the network packet layer.
I’m looking for the ultimate solution to make this outbound long-distance traffic profile 100% indistinguishable from organic, standard consumer Wi-Fi web browsing.
Questions for the experts here:
1. Is WireGuard's default packet size or a lack of TCP MSS Clamping rules (1420 bytes vs standard 1500 consumer frames) a dead giveaway to DPI checkers? What specific OpenWrt iptables/nftables firewall rules can I apply to the Brume 2 to mask this?
2. If we need to abandon WireGuard/Tailscale to fix this signature leak, what transport layer protocol should we pivot to? I'm looking at wrapping the traffic in an Xray layer (VLESS with REALITY) or using a Trojan protocol to blend in with normal HTTPS traffic. Does anyone have a preferred setup for OpenWrt hardware gateways?
3. If there is a better hardware or software architecture entirely for this long-distance residential use case, please lay it out. I have the budget to acquire whatever hardware machines, flash alternative firmware, or download different client apps are needed to fix this footprint.
Appreciate any insights, custom scripts, or structural recommendations you guys can throw my way!
Comments
The overhead of TCP-over-TCP and its associated problems will probably cause more issues than those caused by UDP fragmentation.
MTU fragmentation is absolute digusting.
MTU is a giveaway that you are using a VPN yea.
Interesting. Well at least if i will ever voluntarily use TCP for tunneling, which i predict to be the case somewhat about never
Got it, no worries about the Brume 2! It's just an OpenWrt-based micro router, but I am absolutely not married to it. I have the budget to buy whatever hardware or server setup is necessary to make this work.
Since I want to take your advice and use a proper application-level proxy to blend in with standard HTTPS/TLS traffic, what is the ultimate setup you would recommend from scratch?
If you could build the perfect, bulletproof stealth proxy system using any hardware machine, OS, or protocol stack (like VLESS/REALITY, Trojan, Shadowsocks, etc.), what would that blueprint look like? I'm completely open to your recommendations!
Why don't you just install a computer in the states and remote into it?
Well, it's really not that relevant anyways. Your problem is pretty much all software.
I don't really know. Given you have Shadowsocks in the mix it seems you want to evade detection on the clientside too? If that isn't the case (i don't really see where you would need that outside of like ~3 countries) you could obviously drop it. Beyond that it's just a bunch of Linux installs with whatever works best for you, i guess.
Using a remote desktop/screen-share setup is a clever idea, but unfortunately, it won't work for my specific use case. I am doing social media content live streaming.
Remote desktop streams introduce way too much latency and heavy video compression, which completely destroys the high-definition visual quality and real-time responsiveness required for the media apps.
That's why I really need a pure network-layer solution (like the stealth proxies discussed) so the local device in my hand can handle the processing natively while routing through that clean residential line.
If you say your DPI has advanced fingerprinting, then this combo is likely to be detected anyway.
Reality's camouflage helps when you're establishing the connection. But it doesn't help masking what you transfer afterwards. Your DPI will notice it isn't google, microsoft, icloud, etc.
I didn't dig too deep into this, but looks like you need either VLESS + XHTTP or VLESS + XHTTP + Reality.
The latter is probably the best possible option for your situation. More complex to set up properly though.
I see what you mean! You're totally right that I'm not trying to bypass state-level censorship like the Great Firewall.
The reason I have Shadowsocks/Xray in the mix isn't to evade a government—it's to evade commercial fraud and risk-scoring engines (like IPQS). Modern app platforms use deep packet inspection that flags the rigid structural footprint of a standard WireGuard or OpenVPN handshake instantly, even if the residential IP itself is 100% clean.
So while I'm not in one of those 3 countries, I'm fighting the exact same packet-signature battle to make the tunnel look like ordinary, organic home Wi-Fi browsing to these strict platform filters.
I don't think Shadowsocks (and friends?) is really concerned with detection on the receiving end. It just obfuscates packets between the client and the VPN server. I might be wrong though.
Edit: Your problem is likely 90% MTU and like 10% network stack fingerprint, which (especially in a proxy case) would come out as Linux and might mismatch a WIndows OS claimed by the browser. Chances are it won't really be checked though and the detection is kinda clumsy anyways. I've seen Linux boxes behind a mixed BSD/Linux environment be detected as Android. Hardly anything to use for actual scoring.
thank you for this insight! That makes perfect sense about REALITY handling the initial handshake camouflage, but falling short on the persistent data flow signatures afterward. I hadn't considered how the continuous traffic profiling would look to strict engines.
Since you mentioned VLESS + XHTTP + REALITY is likely the best possible option to beat this level of inspection, I'd love to try deploying it.
Given that my server backend is a GL.iNet Brume 2 (running OpenWrt) and my client app is Shadowrocket, how difficult is this combo to set up? Do you know if standard Xray/Sing-box plugins on OpenWrt support XHTTP yet, or is there a specific guide/template you recommend I follow to configure it properly?
Try IPIP/GRE/L2TPv3 to fix your MTU first?
Do you know how to fix the MTU on brume 2 and MT-3000 travel router?
I have no idea. Conceptually you need to set the DF bit to zero on the GRETAP interface.
config interface 'gretap_lan'
option proto 'gretap'
option peeraddr 'X.X.X.X'
option tunlink 'wan'
option df '0'
option mtu '1500'
You can always use a pair of small Mikrotik or Linux boxes if OpenWRT fails you.
I don't know you application, but you might be overthinking this. If your application will accept external video input, just stream the video to a device in the states.
My experience with Openwrt is quite limited, never tried anything like this on it.
Brume 2 specs look good, should be doable I believe.
Talk to modern routers' enthusiasts, they manage to install some crazy stuff from time to time. There should be people running such layered VPN setups.
So > @Baobeiforever said:
Just to clarify my exact setup: The main source hosting the connection in the US is running on a Brume 2 (GL-MT2500) gateway. On my client side, I'm using the mobile app WireGuard instead of my travel router GL-MT3000.
I just re-ran the Obfuscate.com (VPN & proxy test, timing tests), and the score came back at 0% delay. Because the packet pacing and timing are completely natural now, I don't think an MTU fragmentation leak is what's triggering the flags anymore.
However, here is the current puzzle: On IPQS.com, my results show VPN: False, but Proxy: True.
If the packet timing is perfect (0%) and the cryptographic signature of the VPN is hidden well enough to pass the VPN check, what exactly is triggering the Proxy: True flag on IPQS? Is this purely an IP reputation/database issue with the residential provider, or is there another hidden leak (like a WebRTC, DNS, or TCP/IP fingerprint mismatch) that IPQS is sniffing out? How can I clear this final proxy flag?"
On the client side do you think it's better to run the wireguard app though the travel router GL-MT3000 or on the wireguard mobile app > @Baobeiforever said:
On the client side do you think it's better to run the wireguard app though the travel router GL-MT3000 or on the wireguard mobile app
In my opinion @OP is heavily overengineering this. I'd just get 2 old thinclients (either with 2 network interfaces out of the box or some pci/pcie/m2 slot to add a second interface/wifi card - probably about ~10-20€ each with a little searching around on ebay), install Linux and play with the settings until detection fails. In the end it doesn't really matter what the actual interface MTU is (well, it does matter but not on its own). It's the software running the show.
Forcing some MTU on the interface without correct adjustment to whatever VPN software is used will either not help due to the VPN interface still being limited thereby limiting the whole path or straight up break the connection due to, well... wrong MTU.
I'd start as simple as possible: VPN software of choice + nothing else. All the client <=> VPN server obfuscation likely just complicates the setup without gaining anything.
Edit: Watch for DNS leaks. Those are sometimes also used for evaluation. I'd personally just run unbound on the VPN server (no idea if that's good or bad in terms of VPN detection) but you could probably also just run dnsmasq and point it towards 1.1.1.1/8.8.8.8. In theory using one of the big public DNS servers on the client should also plug any possible data leak on that front though. Just don't have your local ISP do the resolving.