At a Pakistan site (P19/MSH), Geedge identified that TCP RST-injection for a Deny action fails on asymmetric ('unidirectional') flows because the synthetic RST packet lacks GRE callid/routing context only present when both directions transit the same node. Two fixes are in progress: a dedicated third-layer packet-injection route, or a cluster-wide coordination mechanism ('SwarmKV') that syncs which policy a session matched across nodes so each node can independently inject its own side's interference packet.
由于GRE上下行的callid不同，当命中策略的会话为单向流时，构造反方向...数据包（如RST）时缺乏callid信息，会出现构造失败的错误日志...通过SwarmKV在集群内同步单向流会话命中的策略ID
Defense implications
- Designs relying on asymmetric routing to defeat RST injection should not assume this gap is permanent -- Geedge is actively engineering a distributed-coordination fix (SwarmKV) specifically to close it.
- Until that fix is deployed, deny currently degrades from TCP RST injection to a silent drop for unidirectional flows -- worth confirming which behavior is observed empirically in a given deployment.
Related findings
An internal TSG operations/troubleshooting manual lays out TSG's full traffic pipeline (NIC -> mrzcpd/marsio capture driver -> sapp DPI engine -> firewall/proxy(KNI->TFE)/active-defense/WAN-NAT policy branches) and shows engineers using maat_redis_tool to pull the live Redis-synced blocking policy tables (TSG_SECURITY_COMPILE, TSG_OBJ_IP_ADDR, TSG_OBJ_APP_ID) and filter them by numeric policy/object ID to debug why a block rule isn't firing.
An internal TSG functional-requirements spec ('加密协议JG') defines device support for identifying and blocking ECH, ESNI and QUIC traffic via per-connection SNI/region-matching tables (e.g. DF_QUIC_REGION), plus a companion 'FD报文全流程感知' feature that both passively monitors and actively injects synthetic verification traffic end-to-end through the network path to compute a live per-rule 'CT率' (breakthrough/penetration rate) — the system self-measures how often its own QUIC/ESNI/ECH blocks fail to take effect, and separately throttles logging/blocking detail for rule IDs receiving unusually high hit counts (DF_ATTACK_PROTECTION, 'targeted attack detection').
An 'ADC Hardware Installation and Configuration Guide' (v21.11) describes a modular chassis (Switch Sled, CPU Sled) matching taxonomy's Pakistan/WMS-UTR 'ADC hardware' reference, confirming ADC is a distinct deployed hardware line -- not just a site nickname -- with its own installation documentation separate from the TSG-X/TSG-7400 line.
A thesis-project assignment for hidden-service (VPN/Proxy/Tor) identification via heterogeneous graph neural networks on flow logs sources its one day of training data from a database explicitly named 'tsg_galaxy_p19' — tying the internal TSG naming convention to the taxonomy's P19/WMS-UTR Pakistan site codename — accessed over an internal 'Information Harbor' (信息港) VPN, with ground-truth hidden-service IP labels supplied by the commercial IP-intelligence service spur.us.
A production feature spec ("加密协议JG") requires detection-and-control capability for QUIC, ESNI, and ECH, with a per-connection log field c_encrypt_type explicitly distinguishing ClientHello encryption (0=unencrypted, 1=ESNI, 2=ECH) and a DF_QUIC_REGION rule table matching QUIC by SNI. The system computes a per-rule "CT" (穿透/penetration) rate from paired mirror-vs-functional RST-packet logs (TF-RST-LOG / TF-MIRROR-RST-LOG) to grade each block rule's effectiveness, and runs continuous active-verification probes against its own rules, deliberately varying the probe 4-tuple each run "to ensure it doesn't hit the blacklist" so the verification traffic itself reaches the target.
A log-stream double-write Flink program (galaxy/tsg_olap/log-stream-doublewrite) was purpose-built and repeatedly updated for "P19" -- the internal codename for the Pakistan (WMS-UTR) TSG deployment -- replicating TSG session-record logs to a secondary sink, evidencing dedicated engineering investment in the Pakistan customer's log pipeline distinct from the base product.