Multi-week TSG engineering investigation of iTOP VPN (requested by an Ethiopia deployment, cross-tested in a Myanmar environment) found blocking only takes effect for VPN sessions established AFTER a detection policy is pushed; a VPN already connected before the policy loads is never blocked or logged, regardless of signature type (SNI or server-IP).
先策略生效，再打开应用，windows、苹果和安卓客户端策略均有效果且有策略命中日志生成；先打开应用，后生效策略，windows、苹果和安卓客户端策略均无效果且无策略命中日志和会话日志产生。
Defense implications
- Policy evaluation appears to be per-new-connection at handshake time, not applied retroactively to already-established sessions. A client that establishes and holds a persistent tunnel before a new signature/IP-list update is deployed evades that specific update entirely.
- Same ticket shows SNI-based signatures broke once the app's Google Play build changed (v1.0.0) and required re-extraction, and that once SNI failed, the team fell back to server-IP blocking — confirms SNI rotation/spoofing forces a slower, IP-based fallback.
Related findings
Geedge's own engineer explicitly documented that FQDN+JA3-based blocking of Panda VPN at the M22 (Myanmar) site was incomplete ("阻断并不完全还是会有穿透的数据流") and that the surviving traffic showed no identifiable signature, forcing a fallback to static server-IP blocklisting (216 IPs extracted across free/VIP nodes, tested on Android/iOS/Windows).
Ethiopia (E21) customer specifically tested Melon VPN and Ultrasurf against TSG; Ultrasurf's frequently-rotating IPs required an updated signature (successfully blocked after update), while Melon VPN's connection succeeded but was non-functional for other reasons (not attributed to TSG blocking).
Under the internal "M22" project (deployment site "YGN-MYTEL" confirms this is Myanmar, at the Mytel carrier), Geedge runs a continuous, individually-tracked signature-extraction pipeline against named commercial VPN apps (Super Unlimited VPN, NotVPN, Avira Phantom, Bitdefender VPN, Thunder VPN, Panda VPN, Mouse VPN, HaloVPN, GoFly VPN, Kiwi/Kuto/Greennet/Gulf Super/Hatunnel+ VPN, and a customer-provided list of 141 more): active probing of app refresh/connect behavior (including automated UI-driving scripts) extracts server IP/FQDN lists, separately for free vs. paid tiers and Android vs. iOS, which are then loaded as blocklist objects and validated against a false-positive ("CT"/穿透) test pass in a separate demo environment before deployment.
Geedge runs an ongoing, systematically-numbered VPN/app fingerprinting program for the M22 (Myanmar) deployment — a tracked "M22-VPN List" with 188+ sequentially numbered entries, and a separate non-VPN app catalog past entry 550 — with weekly-cadence re-testing (e.g. Quark VPN patches issued repeatedly through late 2024 as the target app's own infrastructure changed).
Ethiopia customer (E21/E-site) explicitly requested TSG blocking be extended beyond the baseline (Psiphon 3) to a named list of commercial VPNs: Freegate, CyberGhost, Torguard, NordVPN, IPVanish, VPN Unlimited, ExpressVPN, Surfshark, Windscribe, Hotspot Shield, Ivacy, Atlas VPN, PureVPN, ProtonVPN, Norton Secure VPN. Engineering confirmed delivery of NordVPN and Hotspot Shield signatures with successful field tests.
Root-caused an Ethiopia SNI-block-failure incident to the detection mechanism itself: APP_SKETCH's FQDN-scanning module -- which exists specifically to identify Psiphon3 and Freegate via top-N SNI matching -- was CPU-expensive enough to saturate cores, triggering sapp's fail-open DDoS bypass and letting some target connections through uninspected. A signature-structure fix roughly doubled throughput (33K/s to 73K/s new connections) and disabling the fail-open bypass restored reliable blocking.