I'm working on a hardware-to-hardware routing configuration across a long distance using official GL.iNet gear and am running into a deep packet inspection hurdle.
The Setup:
Server Side (The Source): A GL.iNet Brume 2 running on a clean, US residential broadband connection.
Client Side (The Receiver): An endpoint 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 direct software connections using mobile apps like Shadowrocket.
The Problem:
When verifying the connection against basic IP database checkers, the IP perfectly resolves to our clean US residential ISP pool with zero hosting or datacenter flags. However, when tested against strict threat intelligence and fraud engines (specifically platforms like IPQS), the system successfully fingerprints the active tunnel over this long distance and flags "Proxy: True".
The endpoint environment is completely locked down (hardware GPS disabled, local system time zone/region/language matched to the US server side, IPv6 disabled). This indicates the network signature/packet structure itself is giving the active tunnel away.
I would love some insight on the following from the GL.iNet experts:
Is this typically a dead giveaway due to WireGuard's default MTU sizes or missing TCP MSS Clamping rules (1420 bytes vs standard 1500 consumer frames)? What specific OpenWrt firewall rules should be applied on the Brume 2 backend to mask this?
If we need to drop WireGuard/Tailscale entirely to bypass this level of deep packet inspection, what protocol layer would you recommend implementing over the Brume 2 (such as Trojan, or Xray with VLESS/REALITY)? Does GL.iNet firmware natively support these via plugins?
What is the current industry standard for making a long-distance, home-hosted remote tunnel look 100% indistinguishable from organic consumer Wi-Fi traffic?
Completely open to switching protocols, altering firmware, or tweaking any dashboard settings on either router. Thanks in advance for any advice!
I ran some tests with the IPQS web interface using SoftEther, my favorite VPN protocol for hiding VPN traffic, from halfway around the world back to the US. The first couple of times I tried it, the IPQS web site showed VPN, TOR, and Proxy all as False. After experimenting with it for a while, it started reporting my IP address as Proxy: True and raised the Fraud Score. I am wondering if part of its logic works as its own honeypot, watching for people who repeatedly use the tool. I will do more testing over the next couple of days, since my VPN server sits behind a Verizon 5G Home Internet connection that receives a new external IP address daily.
IPQS is probably also looking at latency, since mine is around 300 ms. Latency is not something you can hide, and is easy to check using java script. Your browser reports the estimated round trip time (rtt), and there are multiple java script techniques that can measure the approximate rtt, if you spoof the browser reporting.
Testing IPQS from another residential VPN I have at a different home, using WireGuard with an MTU of 1280, it immediately showed Proxy and VPN as True, so I think it is looking at MTU. SoftEther emulates Ethernet and uses full 1500 byte packets. It also uses HTTPS for its transport, so it gets through when many other protocols are blocked.
I do not think it is doing true deep packet inspection. MTU size, known packet markers used by Wireguard, and latency measurements do not require looking deep inside the packet.
All my tests were done with the Brave browser, in a private window, that were re-created for each test.
I had a bit of time to do some more testing on getting past IPQS tests for Proxy, TOR and VPN identification. With a new IP address issued by Verizon 5G Home at my home site, and using a sand-boxed new install of Chrome at my remote site, I am able to reliably pass all of the IPQS tests, and was given a Fraud Score of 0. My VPN software is SoftEther, using its native protocol with an MTU of 1500. The distance was around 10,000 KM between my VPN client and server.