IP-list blocking

A MESA Lab monthly report states that adjustments to a VPN-detection module accumulated over 10,000 Psiphon3 server IPs and delayed a Psiphon3 client's ability to get online by at least 3 minutes in the researchers' test environment, an earlier-stage data point consistent with the much larger-scale (~70-73K IP) 'vpn-thwarting'/CyberNarrator Psiphon-harvesting pipeline documented elsewhere in this corpus.

MESA Lab group-meeting notes record parallel R&D on a whitelist-filtering module and a project to fingerprint cloud-hosted circumvention/proxy infrastructure at the IP-block (not single-IP) level, explicitly modeled on 2017/2019 academic 'Bulletproof-hosting IP block' research; the notes also mention local packet captures that found Psiphon IPs, the domain types/ratios Psiphon uses, and active-probing behavior with candidate detection countermeasures.

The same T1/NTC node config (ntcconf/t1conf/main.conf, K18/Astana/Kazakhtelecom) exposes concrete DPI enforcement toggles: a SYNACK_OR_RST switch and SEND_INJECT_PKT flag governing active TCP-response/packet-injection behavior; ASN- and IP-based blocklists (ASN_MAAT, IPD_DYN_MAAT, IPD_STATIC_MAAT) refreshed from MAAT/Redis on a 1-second effect interval; a dynamic blacklist with a 180s timeout; explicit protocol-blocking switches for BitTorrent (DHT/uTP) and eMule (Kad); and TLS metadata harvesting including certificate SAN fields (NTC_SSL_COLLECT, collect_san_sw=1) streamed to a Kafka topic.

A dedicated AppSketch/MAAT signature object named 'Psiphon-Volunteer-IP' (signature_id 4054) blocklists specific IPv4/IPv6 CIDR ranges by ip.dst regardless of port (192.122.190.0/24, 2001:48a8:687f:1::/64, 141.219.0.0/16, and more), i.e. Geedge maintains infrastructure-level blocking of known Psiphon volunteer-hosted proxy server ranges rather than relying solely on app/protocol fingerprinting.

A signature object dated 2024-10-28 and named 'VPN servers in Russia' (fqdn variant signature_id 6217, IP variant 6216) blocklists specific FQDNs (api.tap2free.net, vpnlocal.app) and a companion IP-address object, showing Geedge curates geography-scoped VPN-infrastructure collections by country rather than only per-app-brand signatures — i.e. any server identified as VPN infrastructure hosted in a given country can be swept into a blocklist independent of which client app uses it.

An exported IP-blocklist object with the literal header format 'IP[Single||/CIDR||-Range]#[Port]' and 5,511 entries, each a single IP with port range 0-65535 (i.e. full-IP block regardless of port), includes 185.220.101.77 — an address in the 185.220.101.0/24 block long associated with Tor exit-relay operators — suggesting at least part of this object targets Tor exit infrastructure by IP rather than by protocol fingerprint.

A second raw, unlabeled IP list (13,786 entries, no header/context) contains dense runs of adjacent addresses within a small number of /24-ish blocks (e.g. multiple 146.66.209.x and 102.129.227.x addresses), a pattern consistent with enumerating a hosting/VPS provider's allocated ranges rather than random targets. Format (flat one-IP-per-line) matches the kind of raw export MAAT's IP-rule policy objects are built from, but this file lacks the labeling seen in 788a452cfa86, so its specific purpose/target list is not independently confirmed from this artifact alone.

A MAAT/AppSketch signature literally named "Psiphon-Server-IP" blocks by destination IP against a list of 1,300+ IPs (the extracted text is truncated at ~200KB so the true list is likely larger, consistent with the taxonomy's cybernarrator/vpn-thwarting note of ~70-73K harvested Psiphon IPs), directly corroborating that the CyberNarrator/vpn-thwarting Psiphon3 IP-harvesting pipeline feeds its output straight into a production MAAT/AppSketch blocking signature.

The batch contains 200+ individual MAAT/AppSketch signature JSON files, most defining FQDN- and/or destination-IP-based blocking rules for a single named commercial/consumer VPN app each (LetsVPN, TurboVPN, QuarkVPN, PandaVPN, StarkVPNReloaded, VPNTurkey, BitdefenderVPN, SnapVPN, SuperSpeedVPNProxy, SuperUnlimitedVPN, CafeVPN, and dozens more), each carrying a build date — the dated files span June 2024 through November 2024 — showing a large, actively and continuously maintained per-app VPN signature catalog rather than a static blocklist.

A MAAT/AppSketch signature named "WARP on CF Edge" identifies Cloudflare WARP by matching destination IP against Cloudflare's published WARP anycast CIDR ranges (both IPv4, e.g. 162.159.192.0/24, and IPv6, e.g. 2606:4700:d0::/48) AND IP protocol UDP (ip.proto=17), while explicitly excluding destination port 443 (not_flag on a dstport=443 condition) — implying a separate rule is needed to catch WARP traffic that uses port 443.

An internal measurement-study report documents researchers live-testing the public DPYProxy TLS/SNI record-fragmentation tool against the GFW from inside China, against a control run from a German VPS. On a GFW IP-blocklisted Wikipedia IP, SNI fragmentation of any tested size (1/5/10/20 bytes) still ended in a server-side RST (though 1-5 byte fragments reached ServerHello before RST vs. 10-20 byte fragments RSTing right after ClientHello); on a non-blocklisted IP for the same domain, SNI fragmentation fully bypassed SNI-based blocking and returned a normal HTTP 200 response, matching the Germany baseline. The same report notes that testing Psiphon triggered roughly 5-10 minutes of residual censorship that also blocked other, unrelated circumvention tools from the same vantage point.

MESA Lab internal debugging notes give the concrete sapp/MAAT config paths and JSON rule schema used for IP-based blocking: /home/mesasoft/sapp_run/TF_conf/TF_tableinfo.conf defines an IP_REGION_INFO table type (ip_plus) with a do_blacklist flag, matched against src/dst IP+port ranges.

A weekly 涉诈APP (fraud-suspected app) disposition report for Nov 5 covers 20 apps (12 with overseas servers); alongside genuine scam-lottery domain clusters (玖富彩票) it lists mainstream, non-fraud consumer apps -- Shopee (major Southeast Asian e-commerce platform) and Trust Wallet (widely-used cryptocurrency wallet) -- each with extracted domains/IPs/API paths and a disposition of 系统处置情况：新增拦截处置 (newly added to blocking), showing the anti-fraud program blocks broadly-used legitimate commercial/financial apps under the same infrastructure and process used against actual scam operations.

A weekly operational report documents newly-added blocking rules for 25 mobile apps (18 hosted overseas, mostly on Hong Kong-region Azure/Alibaba/Tencent cloud IPs), where analysts extract each app's domains, IPs, and distinctive URL paths (e.g. '/tigase/getLastChatList', '/user/getUserMoney') and log 'system disposition: newly added blocking action' for every one; matching raw keyword-object exports using the identical URL-path style confirm these hand-extracted paths are loaded directly as live filter-list entries in production.

Commit history for the K18 (Kazakhstan) argus-ntc console reveals its concrete feature set: a scheduled "网页关键字定时器" (webpage-keyword timer/scheduler) for keyword filtering, ASN/IP block-list configuration pages, a "BGP泛收" (BGP wide-collection) page, an SSL-interception config toggle, a file-scanning results page with MALWARE TYPE/MALWARE NAME columns, app-identification entries including a WhatsApp rename, and a VoIP business-config approval workflow, with blocking actions relabeled from "阻断" (block) to "封堵(丢弃)" (interdict/drop).

TSG/CM ships with pre-built, first-class 'Learning Object' entries specifically for Freegate (Object ID 18) and Psiphon3 (Object ID 19), plus a generic 'Top Server IP' object (ID 20) -- default product features, not customer-commissioned custom signatures. The Psiphon3 object auto-learns and dynamically updates a live blocklist that reached roughly 70,000 IPs at one deployment before a database issue temporarily dropped it to ~50,000.

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).

A companion recurring report family, "Tiangou Secure Gateway — Server IP and Location of Overseas APP", automatically compiles TOP10/TOP50 server-IP-and-geolocation tables per major Western platform (BBC, Discord, Facebook, Gmail, Google, Hulu, ESPN, Messenger, etc.), i.e. an automated pipeline for building IP-block target lists against specific foreign services from observed traffic, generated on a similar recurring cadence.

A Geedge internal automation service (wangwei/cn-object-scheduler, package com.geedge, CnPolicySchedulerApplication with FqdnScheduler/IpScheduler) periodically pushes named VPN-service objects into TSG's blocking policy store; commit history explicitly names Psiphon3, Windscribe VPN, and Ivacy VPN server-name objects being added or corrected, and one commit changes FQDN matching from exact to substring match.

A 69-entry all-port IP blocklist ("/32#0-65535", i.e. block every port on the exact address) targets specific IPs on Cloudflare (104.16.x/104.18.x/104.21.x), Microsoft Azure (13.x/20.x/40.x/ 52.x/65.52.x), and Alibaba/Tencent-adjacent cloud ranges (47.x, 8.210.x) — i.e. individually pinpointed IP-level blocking against specific hosts on major CDN/cloud infrastructure rather than blanket ASN blocking, consistent with targeting specific circumvention-service endpoints hosted on shared cloud IP space without collateral-blocking the whole provider.

A harvested JSON dataset matches Windscribe VPN's own internal server-list API format exactly (dns_hostname on windscribe.com, node hostnames on whiskergalaxy.com, WireGuard public keys per node, OpenVPN x509 certificate names, and per-node latency-probe ping_host URLs) — i.e. a commercial VPN provider's full server infrastructure (IPs, WireGuard pubkeys, ping/latency endpoints) has been scraped/harvested wholesale, the same pattern documented for the CyberNarrator/ vpn-thwarting Psiphon3 pipeline but applied to a different provider (Windscribe).

An internal "business log loading interface" spec enumerates the platform's full censorship/surveillance taxonomy as three parallel log streams (管控/blocking, 监测/monitoring, and 一般/general) each covering the same roughly 13 categories -- IP blacklist, DNS spoofing, URL, website, specific-certificate, webpage-keyword, email-keyword, FTP-keyword, search-term, email, VPN, instant-messaging, and social-app -- fed via HTTP POST/Avro to a "front-end big data platform," with source/destination geolocation fields explicitly keyed to a carrier-supplied "疆外" (outside-Xinjiang) IP-location database.

A TSG/sapp signature bundle dated 2024-06-17 defines a single 'Express VPN_Patch01' application (app_id 15190) matched by three independently OR'd signature layers -- an FQDN blocklist (expressvpn.com and ~7 domain variants), a destination-IP blocklist of roughly 150 addresses, and a raw UDP payload byte-pattern match anchored by offset/depth against ExpressVPN's Lightway protocol handshake bytes -- tied to an explicit enforcement action of dropping matched traffic.

A customer technical Q&A document specifies capacity requirements for a front-end traffic-shunting device sitting ahead of TSG: rule capacity above 10,000 masked/wildcard rules and above 1,000,000 exact-match rules, distributed across multiple X86 boards by rule-category (>16 categories), a rule-load speed above 100,000 rules/second, and sub-1ms rule-effective time, supporting IP/port-based drop, forward, mirror, and loopback actions on innermost addresses under nested MPLS/VLAN/IPv4-v6 encapsulation.

Beyond ExpressVPN, TSG/sapp's signature pipeline maintains individually dated, continuously-updated detection rules (IP, FQDN, and in some cases WireGuard-specific payload signatures) for dozens of distinct named commercial VPN products spanning mid- through late-2024 -- including FlyVPN, VPNHero, RapidVPN, JourneyVPN, quarkVPN, AwardVPN, VPNLite, AdGuardVPN, WolfVPN, DelightVPN, VPNlat, VPNBrazil, NotVPN, VPNTurkey, jumpjumpVPN, BetternetVPN (with a dedicated WireGuard variant), TurboVPN, Psiphon 3, CyberGhost (WireGuard-specific), NordVPN, VPN Unlimited, and SuperUnlimitedVPN -- indicating a long-tail, actively-maintained blocklist covering niche/regional VPN apps, not just a handful of major providers.

A hands-on MESA lab experiment testing TLS-record/TCP fragmentation (via the DPYProxy tool, replicating the public "Circumventing the GFW with TLS Record Fragmentation" technique) against live GFW found SNI fragmentation reliably bypasses GFW's SNI-based blocking of a non-blocklisted wikipedia.org IP, but has zero effect on GFW's separate IP blocklist: for an already-blocklisted IP, every fragment size tested still failed, with GFW tearing down the connection via <RST,ACK> immediately after ClientHello for larger fragments, or after the server's Hello for very small (1-5 byte) fragments.

Two exported IP/CIDR filter-list objects (762 and 5,631 rows respectively, each spanning all ports 0-65535) consist almost entirely of recognizable DigitalOcean (138.68.x, 143.198.x, 159.89.x, 164.90.x, 188.226.128.0/17, etc.) and OVH SAS (51.15.x, 51.83.x, 54.36.x) cloud-hosting CIDR ranges respectively, indicating the platform blocks entire commercial VPS/cloud-hosting provider address space wholesale rather than only individually-identified circumvention-server IPs.

At a 'WMS-UTR' project deployment, Huawei DPI equipment operating alongside Geedge TSG at sites abbreviated TWA/PCAP/MSH independently applies a SIP-protocol Deny policy with IP allowlisting -- confirming TSG is deployed in a multi-vendor stack alongside Huawei DPI hardware at the same customer site, not as the sole detection layer.

A 2018-2019 IIE-authored repo (IPReuse/vpn_cgi) implements a Django CGI service ("VPN_CGI") with a Redis-backed IP-statistics module (stat_ip_redis.py), built by a team explicitly named "IPReuse" — early (pre-2020) tooling for tracking/managing VPN-associated IP addresses, structurally similar in purpose to the later-documented CyberNarrator 'vpn-thwarting' IP-harvesting/blocklist pipeline, though not confirmed to be the same lineage.

The GitLab group itself is named "K18_NTCS_WEB" (K18 = Kazakhstan), and its "nfs" web app implements per-protocol keyword-filter configuration classes (App/FTP/Mail/P2P/SSL keyword configs), an OpenVPN IP-list config, RADIUS-based logging/reporting entities, MAAT rule-sync beans, and an explicit "IP spoofing" business feature with its own "PXY仿冒地址池" (proxy spoofed-address pool) and dedicated policy-log support -- the single strongest piece of evidence in this batch tying named keyword-filtering plus IP-spoofing capabilities directly to the Kazakhstan deployment.

Geedge's MAAT/AppSketch signature system contains a dedicated, dated ruleset naming Lantern by product: signature_id 7312 "Lantern_fqdn_20241104" matches common.server_fqdn against the literal keyword "$lantern.io", and a companion signature_id 7240 "Lantern_ip_20241104" matches ip.dst against a static list of 1,604 individual IPv4 addresses, both dated 2024-11-04. The same signature file appears twice in the leak at two different artifact paths (identical content, not independent corroboration). Independent whois verification of all 1,604 IPs (not itself present in the leak document -- done by the extracting analyst against current registry data) found they collapse into only 38 distinct /16 ranges, of which ranges totaling 86.7% of the IPs return an explicit Oracle Corporation whois org record (netnames like OC-195, OC-260, ORACLE-4, ORACLE-MY, ORACLE-SE, OPC1); the remaining 13.3% are unattributed legacy RIPE/APNIC-ERX blocks with no other org found, consistent with the same historical-Oracle-lease pattern as the confirmed ranges. The individual IPs are a stale point-in-time snapshot given Lantern's IP rotation, but the provider concentration is the durable signal: this enumeration was effectively a sweep of Oracle Cloud Infrastructure's address space, not a list of arbitrarily-located relays.

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.

Internal MAAT engineering specification (v3.1.20, MESA Lab, revision history spanning 2014-2021) documents the config schema underlying sapp's rule-matching engine: per-rule action types (0=block/阻断, 1=monitor/监测, 2=whitelist/白名单), string/regex/IP/numeric/digest match types, and a geographic+ISP "tag" targeting system that lets the identical rule set be selectively activated per city district and carrier (e.g. Beijing/Chaoyang + China Telecom vs. Shanghai/Pudong), enabling narrowly-scoped rule rollout/testing before wider deployment.

A MESA-affiliated researcher's experiment log documents live testing of Psiphon and a TLS-fragmentation SNI-evasion tool (DPYProxy) against the real Great Firewall from inside mainland China. Fragmenting the TLS ClientHello/TCP stream into very small (1-5 byte) segments bypassed GFW SNI-based blocking of a non-blocklisted Wikipedia IP, while larger fragments (10-20 bytes) did not; a separately IP-blocklisted Wikipedia IP still failed regardless of fragmentation. Testing Psiphon also appeared to trigger a ~5-10 minute window in which the researcher's own unrelated circumvention tool stopped working.

MESA Lab built a P4 data-plane Bloom filter (p4src/bloom_filter.p4, Barefoot-Runtime bfrt_python, PTF test harness) with SYN-packet membership tests (send_exist.py/send_not_exist.py/send_syn.py) -- R&D into line-rate, switch-level set-membership matching (e.g. blocklist/existing-flow checks) independent of the sapp/MAAT software DPI path.

Standard workflow (recurring across AdGuard, JumpJump, Hula, BigMama, and Ace VPN tickets) for adding a new VPN app to TSG's blocklist: capture traffic on iOS/Android/Windows in a dedicated test environment, extract SNI first, fall back to enumerating server IPs when SNI proves ineffective or the app rotates it, then re-verify weekly/periodically with automated 'dial testing' (拨测) that checks whether newly discovered IPs still connect ('未穿透' = not yet penetrated/blocked).

A security policy literally named "Lantern_vpn_test" was configured and actively enforced at the M22 (Myanmar) TSG deployment as of June 27 2024 — Lantern had a live, named blocking policy in production, not just a backlog research item.

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.

A crash/perf bug report reveals Geedge's MAAT rule engine (libmaatframe.so, using Intel Hyperscan for literal/regex matching) running with 545,441 FQDN blocking rules and 404,141 IP address blocking rules loaded in a single instance as of 2024; loading 500,000 new FQDN rules via the full Hyperscan path took ~95 minutes, addressed by an automatic fallback to a second engine ("Rulescan") above 50,000 rules.

TSG maintains a traffic-volume-ranked "Top SNI" / "Top Server IP" allowlist (Galaxy component, learned from live traffic, capped at top ~2000 SNIs / ~40000 server IPs per Nacos config) that is checked before a VPN/circumvention-tool deny policy (including a Psiphon3-specific policy) is enforced. Confirmed empirically: Psiphon3 client traffic whose destination SNI was in the Top SNI list passed through undenied, while traffic to the same client IPs with an SNI not yet in the list was blocked. A 2022-06 incident over-blocked TikTok/BBC/CNN/NYTimes because their SNIs were not yet in the learned allowlist at the time.

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).

A known Psiphon3 relay IP, already in the signature set, wasn't blocked because it used destination port 179 (BGP): TSG's switch/distribution board bypassed port-179 traffic without forwarding it to the compute board for inspection at all (confirmed at the E21/Ethiopia site). A separate domain-whitelist mechanism can also override deny actions. Fixed by routing port-179 to compute.

TSG runs an automated program named 'vpn-thwarting' that calls the CM management API hourly to push freshly-learned Psiphon3 server IPs into a live blocklist object (dynamic_psiphon_ip); at the time of this incident the object held roughly 70,000-73,000 IPs, sourced from a companion automated-learning system referred to as 'CN'.

Documents Geedge's standard operating procedure for building a new app-detection signature: collect a target's server IPs and FQDNs, create IP-match and SNI-match (ssl.handshake.extensions_server_name) feature objects, combine them via OR logic into a named custom "application", then validate via session-log reports filtered on that application label.

Geedge ran an ongoing, systematically-numbered program extracting detection fingerprints for individual VPN and non-VPN apps for the Myanmar (M22) deployment, tracked with weekly-cadence per-app tickets; methodology combined packet capture, DNS/domain analysis, and fixed-port protocol identification, validated in a live test environment before shipping, with results tracked as "CT" (successfully blocked) or not.

Geedge extracted and analyzed Betternet VPN's underlying protocols (WireGuard, a proprietary "Hydra" protocol using spoofed-domain TLS 1.2, and IKEv2), and found the Hydra protocol could be "completely blocked" via JA3 TLS fingerprinting; IKEv2 was blocked via UDP port 500/4500 policy, and thousands of VPN server IPs were extracted as a supplementary IP blocklist.

For 'VPN Turkey' app characterization, the signature-extraction team used Fiddler (a TLS-intercepting local proxy) to decrypt the VPN app's own control-channel traffic and read its server list directly, rather than only passively capturing live tunnel traffic. Repeated on a roughly weekly cadence over several months, each time recording how many new server IPs appeared.

Geedge extracted ProtonVPN server IPs using the app's own debug-log output to find its server-list API endpoint, directly querying it to harvest ~5,800 server IPs, then used automated repeated connection cycling to extract ~200 additional rotating IPs after the initial list was blocked; the app was subsequently reported fully blocked on Android, iOS, and Windows.

Myanmar deployment (M22) systematically reverse-engineered and blocked Orbot (Tor's official Android client) and ProtonMail, alongside numerous consumer VPN apps, via the AppSketch feature-extraction pipeline. Orbot: 287 server IPs extracted across multi-hop nodes, one connection mode fully blocked. ProtonMail: mail server IPs/FQDNs extracted, blocking verified as full service denial (cannot send, receive, download attachments, or create a new account) on Android and iOS.

M22 runs a large-scale automated pipeline against numerous commercial VPN apps: APK decompilation + HTTPS-proxy interception to extract servers/FQDNs, automated dial-testing at volume (one app: 17,554 dial-tests, 4,073 servers discovered, 94% 24-hour block rate), and OpenCV-based automated ad-dismissal to keep test automation running unattended.

The PanGu/pangu_valve repo implements MAAT's live blocking/throttling distribution layer: it consumes Redis-backed MAAT config tables (APP_DOMAIN, APP_POLICY, LIMIT_DOMAIN, APP_STATIC_SEV_IP, APP_DYN_SEV_IP_CB, LIMIT_DYN_IP_CB) and pushes reference-counted domain/IP block and rate-limit rules to inline ("串联设备") network devices, scoped per inline-device business ID.

A raw, verbatim capture of ProtonVPN's own "LogicalServers" API response (127 server entries with entry/exit IPs, WireGuard X25519 public keys, and country/city metadata) sits alongside a MAAT "ProtonVPN_ip"/"ProtonVPN_fqdn" signature in the same corpus, indicating the operator harvests VPN providers' own server-list APIs to seed IP/domain blocklists -- the same methodology documented for the Psiphon-IP-harvesting "vpn-thwarting" pipeline (CyberNarrator), here shown applied to a second, unrelated VPN provider (ProtonVPN).

A MAAT/AppSketch signature named Psiphon-QUIC-Payload (id 4203) flags Psiphon's QUIC transport by matching an exact UDP client-to-server first-packet payload length of 1252 bytes combined with an internal app_id and an extensive destination-IP CIDR allowlist covering hundreds of /22-/24 blocks -- i.e. Psiphon-over-QUIC is fingerprinted by a fixed early-packet length rather than by content.

On the E21 (Ethiopia/Safaricom) deployment, TSG blocked Psiphon3 via ~1.69M known server IPs; in one ~3.5hr window, 76,496 unique client IPs still attempted Psiphon3, which accounted for 14% of total bandwidth, 5.96% of sessions, and 1.32% of unique client IPs despite the active Deny policy.

sapp's packet_io configuration exposes three deployment topologies (mirror, inline, transparent) and, for non-mirror modes, four packet-injection paths for delivering blocked/modified traffic: default system routing, VXLAN encapsulation to an inline device over UDP, or raw Ethernet delivery to a single or multiple next-hop gateways (with configurable spoofed source/destination MAC). This confirms the same sapp codebase backs both passive-tap (RST-only) and fully in-line (drop-capable) TSG deployments.

The gdev_block sapp plugin decouples DPI classification from enforcement: once sapp identifies a stream it wants blocked, it dynamically loads /opt/MESA/lib/libc3client.so and sends a 5-tuple (src/dst IP, src/dst port, protocol) block rule with action GRULE_ACTION_ADD to an external 'c3' rule-distribution server over a licensed connection (auth_data license key from etc/gdev_block.conf), rather than dropping the packet itself. This is a distinct blocking path from sapp's own in-process RST injection, pushing enforcement out to a separate gateway device ('gdev').

For a domestic Fujian deployment, Geedge validated SNI-wildcard blocking (*.sohucs.com, *.sns.sohu.com) as technically effective against a specific Chinese social app ('Huyou'), but rejected it for production because the domain is shared with a third-party SDK platform and would cause false-positive blocking of unrelated services -- falling back to destination server-IP blocking, deployed inline via TCP RST injection.

A single MAAT-format signature named "tor_ip" enumerates at least 802 distinct IPv4 addresses matched against ip.dst, i.e. a dedicated, large-scale Tor relay/bridge IP blocklist maintained as a first-class detection signature alongside the commercial-VPN signatures in the same corpus.

Geedge runs an ongoing, weekly-cadence feature-extraction and blocking program against a customer-curated list of at least 282 named commercial VPN/circumvention apps (including Fly VPN, Secure VPN, NotVPN, letsVPN, VPN Hero, BeastVPN, Cafe VPN, Blockless VPN, BlackVPN, FinchVPN, Cisco Secure Client/ocserv, DelightVPN, NordVPN), plus separate systematic testing of 400+ non-VPN apps. The methodology extracts destination server-IP lists (hundreds to thousands of IPs per app) and app-specific FQDNs, tests each in staging for false positives before deploying, and for at least one target stood up their own clone of the target VPN server software to capture and analyze its real protocol handshake.

Geedge's AppSketch/MAAT signature store contains a large, actively-maintained catalog of per-app FQDN+IP blocking signatures for dozens of named consumer VPN apps (StartVPN, DotVPN, VPNLite, BullVPN, RapidVPN, QuarkVPN, AdGuardVPN, BulletVPN, NotVPN, LetsVPN, PandaVPN, ACE VPN, BetternetVPN, HulaVPN, ThunderVPN, TurboVPN, and more, patch-dated across 2024), each tagged category='networking'/subcategory='tunnels' (or similar) with a deny_action of packet drop (sometimes with TCP RST), and some apps additionally flagged characteristics='evasive' with elevated risk scores; several apps' FQDN lists show the same domain-generation pattern (random word + .xyz/.info) later seen automated in a companion detection script.

Geedge runs an ongoing, largely manual weekly signature-extraction program against commercial VPN apps (LetsVPN, Betternet, VPNLITE, and a ~80-app batch), combining server-IP lists, FQDN patterns, and payload/SNI/Host/User-Agent signatures, tested for blocking efficacy and false-positive rate before rollout. VPNLITE was fingerprinted via TCP direct-connect on ports 18000/3320/8099 plus TLS to randomized .xyz/.info subdomains on Cloudflare ranges (104.21.0.0/16, 172.67.0.0/16).

Live TSG session logs from an internal test bed (device 21426003 / XXG-TSG-BJ) show active Deny actions firing against named commercial VPN apps -- Super Unlimited VPN, BetternetVPN, TouchVPN, LetsVPN -- via dated signature patches (e.g. BetternetVPN_Patch01_20240812 through Patch06_20240920, SuperUnlimitedVPN_Patch05 through Patch10 within six weeks), and LetsVPN's block fires on a JA3 TLS fingerprint (LetsVPN_by_ja3) even when the SNI/Host is spoofed to www.bytedance.com.

Geedge's VPN-app signature-extraction methodology (M22/Myanmar project, run weekly per-app) is primarily IP-address-list-based rather than protocol-fingerprint-based: automated scripts enumerate each VPN app's server IPs (extraction runs cited pulling 7-200+ IPs per test cycle for apps like BigMama VPN, Giti VPN, JumpJumpVPN), which are then pushed as blocking signatures and validated against a live test environment plus a separate false-positive ('误封') test environment before deployment.

The corpus contains a locally-cached mirror of NordVPN's public server catalog (149+ entries visible before truncation, spanning 20 countries, with IP, hostname, and per-protocol support flags for IKEv2/OpenVPN/WireGuard/SOCKS) plus a separate harvested record pairing a country_code with a base64-encoded, ready-to-use OpenVPN client config — evidence of systematic collection of commercial VPN server IPs/configs for blocklist construction, beyond the previously-documented Psiphon3-specific CyberNarrator pipeline.

Three harvested datasets catalog full server-fleet inventories for multiple commercial VPN/proxy brands -- WaselPro/BVPN/SmokeTunnel/iWasel/BackboneVPN (with per-node CA certificate, IPsec PSK, and SSH private key captured), VyprVPN/GoldenFrog (per-location hostname/IP/coordinates), and tap2free (per-node IP with PRO/FREE tier flags) -- i.e. Geedge enumerates and archives entire commercial VPN provider bootstrap/config responses, not just individually observed connections.

A large set of individually-dated per-product signature files shows at least 31 distinct named commercial VPN apps under active, ongoing detection engineering (SecureVPN, LetsVPN, BetternetVPN, SuperUnlimitedVPN, TunnelBear, AtlasVPN, TurboVPN, UrbanVPN, GeckoVPN, VPNUnlimited, BitdefenderVPN, QuarkVPN, FlyVPN, HulaVPN, SurfVPN, BulletVPN, BeePassVPN, SnapVPN, WhitehatVPN, LunaVPN, SuperNetVPN, GitiVPN, CleanerAntivirusVPN, V2VPN/V2Netvpn, 7VPN, and country-branded VPNIndia/VPNCanada/VPNIndonesia/VPNKorea apps), each with multiple detection vectors per app (destination-IP ranges, FQDN, DNS QNAME, TLS cert issuer, JA3, WireGuard-protocol matching, ISAKMP/IKE matching, raw TCP payload); one file shows the resulting policy rule object wired directly to an explicit deny action.

Across dozens of individual signature-rule JSON files in this batch, at least 40 distinct named commercial VPN products carry dedicated detection signatures (by IP src/dst, FQDN, JA3 hash, or protocol-specific payload): BeePassVPN, BetternetVPN (separate isakmp/ja3/WireGuard sub- signatures), BigMamaVPN, BravePrivateVPN, ExpressVPN (JA3 + UDP-payload variants), FlyVPN, hidemevpn (OpenVPN UDP payload), JourneyVPN, JumpjumpVPN, LetsVPN (JA3), Psiphon3 ("psiphon3vpn_serverip"), QuarkVPN, SecureVPN, SuperUnlimitedVPN, TurboVPN, VPNHero, VPNTurkey, and others, each dated/versioned (e.g. "_20240812") indicating an ongoing signature-maintenance pipeline rather than a one-off ruleset.

Dozens of near-identical MAAT/AppSketch-style signature-definition files in this batch each target one named commercial VPN app/service (ProtonVPN, HotSpot VPN, SuperUnlimitedVPN, jumpjumpVPN, BetternetVPN, NotVPN, VPNLite, SymlexVPN, etc.), matched via FQDN suffix, destination IP list, and/or TLS JA3 hash. The same "SuperUnlimitedVPN" signature recurs with new signature_ids/dates roughly monthly (2024-06, -09, -10, -11), showing this is a continuously-maintained, actively-updated VPN-detection pipeline rather than a one-off snapshot.

Leaked per-app JSON signature-rule exports show the detection engine layers multiple independent signals per VPN product: Windscribe VPN is matched via fixed-offset hex-byte keywords inside the OpenVPN UDP handshake payload (offset 73/depth 78 and offset 81/depth 85); "Super Unlimited VPN" (the SuperUnlimitedVPN app) gets three parallel signatures — a JA3 TLS-fingerprint match, an FQDN match, and an OpenVPN c2s-payload-prefix/length match; Hide.me VPN is matched on OpenVPN UDP payload; FastVPN is matched purely by known source/destination IP; and "V2VPN" (Google Play com.v2ray.v2vpn, a V2Ray-based VPN app) has its own dedicated signature — evidencing a deliberately layered (protocol-fingerprint + TLS-fingerprint + FQDN + IP) detection strategy per circumvention product.

An internal MESA Lab survey of VPN/circumvention tools explicitly names Lantern alongside Psiphon as tools whose domain-fronting "can effectively resist detection," and separately reports a measurement result of 39,284 distinct "concealment" (circumvention/proxy) IPs accessed a cumulative 140 million times in one week, spanning 78 identified hidden services/platforms, with the top 10 including Psiphon3 VPN, Xvpn, Thunder VPN, generic Residential Proxy, Secure Android VPN, Proxymaster VPN, Tomato VPN, Foxyproxy VPN, Torch VPN, and Bunny [VPN].

Session-log exports from a Beijing test/demo TSG device ("XXG-TSG-BJ") show live "Deny" enforcement actions (security_rule_list "Deny_VPNHero", "deny_TowerVPN") against traffic the app-ID engine classified with nested app chains "VPNHero" and "OPENVPN.TowerVPN.Psiphon Provider.Psiphon-Server" -- i.e. TowerVPN is specifically tagged internally as riding on Psiphon infrastructure, and both it and VPNHero are actively blocked, not just logged, on this device.

A production Python pipeline queries the TSG session-log ClickHouse database roughly every 5 minutes for sessions matching either a fixed set of VPN-associated TCP ports (18000, 3320, 8099) or a domain-generation heuristic (FQDN = 10-14 lowercase letters + '.xyz' or '.info' TLD, hosted on Cloudflare IP ranges 104.21.0.0/16 or 172.67.0.0/16), and automatically inserts newly-observed matching IPs/FQDNs into the live 'VPNLite_ip'/'VPNLite_fqdn' blocking objects via a config-management API, with no human review step.

Two paired MAAT signatures, "warp_masque_m" and "warp_ip", detect Cloudflare WARP/MASQUE traffic: one matches destination IP 162.159.198.1 (a published Cloudflare WARP anycast address) combined with an internal app_id classification (140/15629), the other matches the same infrastructure via IP protocol number alone -- i.e. WARP is detected both by a fixed anycast IP and by an app-ID classifier layered on top of it.