TCP RST injection

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 internal MESA Lab research note directly measures and compares China's ('CN') HTTP censorship middlebox against Russia, India and an unlabeled 'HZ' system, plus open-source Snort2/Snort3/Suricata: China is characterized as inspecting Host- and keyword-based triggers (example trigger given: a request containing the parameter 'q=ultrasurf') across ALL ports rather than just 80/443, responding with a triple RST or an extra RST+ACK; an 8-technique HTTP-request-mangling evasion comparison table credits China's middlebox as vulnerable only to request-line whitespace insertion and HTTP-version tampering, fewer categories than the other three systems tested.

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 live tsg_master engine config file exposes a [RESET] section with concrete TCP-RST-injection parameters (NUM=1, SEED1=65535, SEED2=13, FLAGS=20, DIR=3, REMEDY=0), a [TRAFFIC_MIRROR] section confirming mirror-tap deployment (NIC_NAME="eth_vf_mirr"), a [MAAT] section wiring tsg_master directly to MAAT's subscriber-ID tables (TSG_OBJ_SUBSCRIBER_ID/TSG_DYN_SUBSCRIBER_IP), and a device tag "BeiJing-XXG" confirming this specific instance is a domestic Beijing deployment. A plaintext Kafka SASL credential (SASL_PASSWD="galaxy2019") is also exposed, and "galaxy" recurs as an internal project codename elsewhere in this batch (docker service path /home/galaxy, APP_BRIDGE_NAME).

The same SAPP manual documents mrzcpd's inline (串联) packet-re-injection subcomponent mrtunnat, configured at /opt/mrzcpd/etc/mrtunnat.conf: use_recent_tunnel=1 allows it to inject a packet with no prior session record, and use_link_info_table=1 makes it validate outer MAC, link_id, link_dir, and inner MAC against a live link-state table at /run/mrzcpd/mrmonit.tunnat before re-injecting a censor-forged packet onto the correct physical link.

An internal SAPP platform training/reference manual (marked "Geedge Networks Confidential And Proprietary") gives SAPP's full name as "Stream Analyse Process Platform" and documents its three-tier plugin architecture (platform / protocol-parsing / business layers, each loaded via dlopen), inline and mirror deployment modes at a stated 10-40 Gbps per box, tunnel-protocol support (GRE/MPLS/IPIP/IPv6-over-IPv4/Teredo), and the MESA_kill_tcp() plugin API that forges and sends RST packets to sever a monitored TCP connection, with the manual noting it was "originally used in mirror mode to send RST packets to block a TCP connection" and auto-retries until the connection is confirmed dead.

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.

Geedge Networks' official 'Confidential and Proprietary' sapp developer manual documents sapp's platform-provided packet-injection API available to any business plugin: MESA_kill_tcp (crafts and sends a TCP RST matching the current flow's 4-tuple/sequence to force-terminate a TCP stream), MESA_kill_tcp_synack (sends a forged SYN/ACK in response to a client's SYN so the client cannot complete a handshake with the real server), and MESA_inject_pkt (injects arbitrary application-layer data into either side of an established flow).

The AppSketch/MAAT signature system contains a systematically dated, patch-versioned catalog of FQDN-based detection signatures for dozens of individually named commercial VPN apps (e.g. V2VPN, V2Netvpn, Turbo VPN, LetsVPN, AdGuard VPN, Avira Phantom VPN, TouchVPN, FinchVPN, Opera VPN, Ultrasurf VPN, GoFly VPN), each modeled as an 'app' object in category 'networking' / subcategory 'tunnels' whose default deny_action drops the flow while sending both an ICMP-unreachable and a TCP RST to the client. At least 35 such distinct VPN-app signature objects appear in this batch alone, dated July-November 2024, with repeated 'Patch0N' revisions to the same app as its domains rotate.

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.

The same sapp.toml exposes the RST-injection engine's tunable parameters directly: [stream.tcp.inject.rst] sets auto_remedy=1, number=1 (RST packets per kill), signature_enabled=1, and two numeric seeds (signature_seed1=65535, signature_seed2=13) that presumably drive an identifying pattern embedded in the injected RST packets themselves — i.e. the operator's synthetic RSTs are deliberately marked with a configurable signature, not raw/generic resets.

The same change document's post-deploy validation step explicitly checks that "spoofed packets and RST packets" are generated normally with no volume anomaly as routine production behavior, and the release separately adds a feature to retain full email body content (not just metadata) on business-user request, running on Kylin Linux Advanced Server V10.

sapp's plugin API exposes explicit enforcement primitives -- MESA_kill_tcp()/MESA_rst_tcp() to inject a single RST, and MESA_set_stream_opt() with MSO_TCP_RST_REMEDY/MSO_DROP_STREAM to make RST-injection or packet-dropping persist for the remaining lifetime of a flow -- with a global sapp.toml auto_remedy toggle and a per-stream option controlling whether a lone RST is reinforced repeatedly for as long as the flow keeps sending data.

sapp's internal architecture guide documents three deployment topologies (mirror/passive-tap, inline, dual-arm transparent) and four distinct methods for injecting blocking packets back onto the wire, including a MAC-in-MAC scheme that extracts device/link IDs from mirrored traffic's source MAC field to route an injected packet to the correct physically separate inline device over VXLAN when multiple injection points exist.

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.

The AV/frag_monitor tool (headers AV_kill_connection.h + Maat_rule.h/Maat_command.h, i.e. a MAAT-integrated flow classifier with active connection-termination capability) ships per-deployment JSON templates including frag_monitor_k_online.json — explicitly defaulted to "K project" per a 2018-12 commit, matching taxonomy's K18/Kazakhstan site codename — plus a dedicated frag_monitor_k_online_youtube.json template and a "zhongxin" (中信)-named template, indicating per-target (YouTube) and per-site blocking profiles built on top of an active kill-connection primitive.

The same operations manual's troubleshooting section confirms the blocking system operationally injects forged RST and "spoofed" (欺骗) packets onto mirrored/passive-tap links via network devices — validated by test-injecting a packet via tcpreplay to an external VPS and confirming arrival with tcpdump — runs the sapp process under supervisor scripts with live status/config-version files (TF_maat.status, RESTART.log), and distinguishes a national "GF" system from separate provincial-gateway ("省口") deployments when localizing which egress point a given block should have taken effect at.

A MESA lab measurement of national censorship middleware (China, Russia, an unnamed "HZ" censor, and India) finds China's GFW performs both Host-header-based and keyword-based filtering across ALL ports, not just HTTP/HTTPS 80/443, and blocks matching connections with 3x injected RST packets or an additional RST,ACK -- a broader and more aggressive posture than the other three censors measured, none of which monitor all ports.

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.

A "精管流量初步分析报告" (2021-07-26) documents a live paired-sapp TLS-interception testbed: sapp instance A captures raw ciphertext via mrzcpd/PAG while sapp instance B ingests plaintext from a third-party decryption platform over a Unix domain socket. The report measures decryption latency (mean 1.82ms), completeness (only 44% of connections flagged decryptable via an SSL/TLS ClientHello-based "user legitimacy" check were actually decrypted, and 88% of eligible users), and confirms RST-based blocking triggered from the decrypted side reaches the client in a median ~0.5ms and successfully blocked live access to Facebook, Wikipedia, Twitter, the New York Times, and Google (BBC was the one tested site that evaded blocking). The decrypted side also resolves each session to a persistent per-user ID via the ciphertext side's four-tuple lookup.

An internal sapp platform developer manual reveals sapp's full name ("Stream Analyse Process Platform") and documents a stream.tcp.inject.signature_enabled config option that embeds an identifiable pattern into TSG/sapp-injected TCP RST packets via the ip_id, ip_ttl, and tcp_win fields, explicitly so that RST packets originating from sapp can be verified with Wireshark or a standalone tool. The same section documents the platform's default RST-injection count ("first 3, then 1" per blocked connection).

An official "Geedge Networks Confidential And Proprietary" sapp/mrzcpd operations manual documents the packet-injection API (MESA_kill_tcp / MESA_inject_pkt) used for both out-of-band mirror-tap RST injection (relies on the local box's own IP routing table to send) and inline in-path injection (requires mrtunnat.conf tunnel-tracking state -- use_recent_tunnel, use_link_info_table -- keyed on outer/inner MAC and link_id/link_dir), plus the Marsio DPDK-based driver's I/O sub-modes (marsio4, marsio_vxlan, pag_marsio, agent_smith) and its role extracting VXLAN/GTP encapsulation metadata and stamping link/circuit identifiers into mirrored packets' MAC field for session-log correlation.

TSG's firewall 'Deny' security-policy action is confirmed implemented via three interchangeable mechanisms: TCP RST injection, forged HTTP 404 response-page injection, and DNS-redirect. Confirmed via commits to MESA_Platform/sapp and tsg/tsg-os-buildimage GitLab repos (git.mesalab.cn).

Geedge's TSG self-check test suite (run against firewall version v23.07.18-591aed7) enumerates the product's full interference capability set: SSL bypass/intercept (including handling of expired, self-signed, and untrusted-root certificates), HTTP/SSL proxy actions (redirect, block, replace, hijack, insert), three distinct firewall deny modes (silent drop, TCP RST, blockpage), and DNS deny modes (silent drop, A-record redirect, AAAA-record redirect, including TTL-range variants).

TSG's RST-injection blocking pipeline is architecturally split: mrzcpd (packet-mirror/capture agent) batches packets (config sz_buffer, packets-per-forward) before handing them to sapp (the inspection/policy engine) for match-and-RST. Under certain carrier/traffic conditions this batching introduced a 5-20ms delay between the real SYN and sapp's RST, letting the blocked connection's data through before the RST arrived -- a confirmed, reproducible bypass ('穿透') on specific Fujian ISP links, fixed only by setting sz_buffer to 0 (no batching).

SAPP evicts per-flow blocking state after a configurable TCP stream timeout (platform default 30s); a client that waits past that window before retrying a blocked connection bypasses the block entirely, confirmed reproducible over repeated tests before the timeout was manually extended. Separately, SAPP only emits a session log record when a flow exceeds both a packet-count and a payload-byte-count threshold (default: >3 packets AND >5 bytes TCP payload) -- flows below that are never logged at all.

TSG's T1 traffic-engine plugin framework (NTC_APP_PLUG, NTC_IP_COMM) tags every classified flow with a composite app-identification label (PROTO_ID/APP_ID/OS_ID/BS_ID-browser/WEB_ID/BEHAV_ID) drawn from a shared per-stream 'dpkt' classification struct, and streams it via Kafka/local log for every session. A disabled (#if 0) code path in NTC_APP_PLUG shows this exact label being matched against the MAAT rule engine (Maat_full_scan_string) to trigger MESA_kill_tcp (RST-based termination) when a block rule fires; NTC_IP_COMM separately logs a live 'stream_killed_flag' via an 'after_kill_switch' option, confirming the TCP-kill/track-after-kill mechanism is real in production even though this particular scan-and-kill call site is currently compiled out.

A multi-week investigation on Fujian Mobile's network found TSG's RST-injection blocking intermittently failed to reach the client even on a correctly-matched policy, traced to carrier-side loss/delay on the injected-RST path and TCP port-reuse/SYN-retransmission edge cases at one mobile site, with RST send rates up to 40,000-80,000/s during the anomaly.

The same feature spec adds a "定向攻击检测" (targeted-attack detection) mechanism: the front-end tracks per-rule (configID) hit counts against a threshold/interval, and once exceeded can throttle or fully suppress emission of RST/block packets and logs for that rule (action codes include "do not send block packets," "sample block packets") -- an explicit rate-limiting countermeasure against the operator's own RST-injection infrastructure being weaponized for reflection/availability attacks, the same attack class (Bock et al., "Weaponizing middleboxes"; "Your censor is my censor") cited in this same lab's own literature survey (see companion finding 2026-mesa-censorship-research-survey-f8c349).

SAPP's internal developer manual documents three generic "packet-send" interfaces exposed to every business plugin: MESA_kill_tcp (builds and sends a TCP RST matching the current flow's four-tuple/sequence numbers to forcibly terminate a connection), MESA_kill_tcp_synack (sends a forged SYN/ACK so the client can never complete a handshake with the real server), and MESA_inject_pkt (injects arbitrary application-layer payload toward either side of a flow). This confirms RST-injection and payload-injection are first-class, reusable platform primitives, not one-off code, and that mrzcpd is the mechanism that re-injects sapp-generated blocking packets into a mirrored/passive-tap link (consistent with taxonomy.yaml's mrzcpd note).

Primary-source MESA Lab wiki documentation confirms SAPP ("Stream Analyse Process Platform") is a plugin-based traffic-inspection engine achieving 10-40Gbps per hardware unit, deployable either inline (串联) or as a passive mirror tap (并联), and exposes core platform APIs available to any business-layer plugin for forging a TCP RST (MESA_kill_tcp), spoofing a fake SYN/ACK to block connection establishment (MESA_kill_tcp_synack), and injecting arbitrary application-layer data into an established flow (MESA_inject_pkt).

SAPP's documented API for business-layer plugins exposes explicit active-interference primitives as first-class, plugin-callable platform functions: MESA_kill_tcp (constructs and sends a correctly-sequenced TCP RST to forcibly terminate the current flow), MESA_kill_tcp_synack (sends a forged SYN/ACK in response to a client's SYN before the real server can respond, preventing the connection from ever completing), and MESA_inject_pkt (injects arbitrary application-layer payload into the live client/server exchange, addressed using the current flow's four-tuple and tunnel-encapsulation info).

The official SAPP platform manual ("Geedge Networks Confidential And Proprietary") documents an optional signature_enabled config flag that stamps sapp-injected TCP RST packets with a detectable pattern in the ip_id/ip_ttl/tcp_win fields so operators can later verify, via a Wireshark plugin or standalone tool, whether a given RST originated from a sapp instance -- the manual explicitly notes 100% recall but not guaranteed 100% precision. The manual separately documents that sapp supports three distinct wire-injection topologies (sys_route, vxlan_by_inline_device, raw_ethernet_single_gateway) and that its tcpdump_mesa debug tool has a dedicated "inject" packet class covering both TCP RST and forged DNS replies.

sapp's TCP RST-injection ('kill_tcp') subsystem is configurable per deployment with an auto-remedy retry count and a two-part numeric 'signature' embedded in injected RST packets (signature_seed1/signature_seed2), plus an option to have the reset instead issued via a separate inline device rather than from sapp itself. The low-level injection API (sapp_inject_pkt) explicitly supports excluding/including the IP header so a companion 'assistant' module can forge the TTL, IP ID, and TCP window to match the live flow before injection, and logs the exact spoofed ttl/ipid/checksum values it sent.

Commit history in the core sapp DPI engine repo (MESA_Platform/sapp) shows its RST-style blocking/injection path is internally called "欺骗包" (literally "deceptive/spoofed packet") injection, implemented via a sapp_inject_ctrl_pkt function that sends forged control packets to all devices opened through the marsio packet-I/O layer; ticket TSG-20317 documents active, ongoing optimization of "inject packet duplicate traffic detection" performance in this code path as of 2024.

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.

"stellar" (git.mesalab.cn / geedgenetworks.com) is a C++ core DPI packet-processing engine with protocol decoders (HTTP, FTP, mail, QUIC, RTP, SIP, DTLS, SSL, DNS, SOCKS, stratum) and a dedicated packet-injection module (src/stellar/inject.cpp) with an extensive TCP-RST-injection test suite covering injection timed after SYN, SYN-ACK, first C2S payload, and sub-ACK. It integrates the MAAT rule engine (security_enforcer.cpp / scanner_maat.c, "Security enforcer maat plugin table"), the Marsio packet-I/O framework (marsio_io.cpp), and glimpse_detector as an integrated decoder plugin ("integration glimpse_detector", "rename to lpi plugin").

The tango/tfe-kmod repo is a DKMS Linux kernel module that reconstructs live TCP connections from out-of-band control messages (CMSG), using the TCP_REPAIR_WINDOW socket option to set window state without a handshake and adding special-case handling for protocols such as SSH where the server sends the first packet -- kernel-level infrastructure letting a userspace process ("TFE") transparently take over or inject into an in-progress TCP flow.

Geedge's production inline-deployment container bundle (tango/tsg_container) wires mrzcpd (capture/inject), sapp (DPI via maat rules), and a third component "tfe" (traffic-forwarding engine) together via Docker Compose; tfe ships a dedicated doh.conf (DNS-over-HTTPS handling) and the firewall-mode container's sapp config includes a send_raw_pkt.conf, a KNI (kernel network interface) config, an "asymmetric_presence_layer.conf" for mirror/asymmetric-routing deployments, and a "pangu" proxy module (pangu_pxy.conf / pangu_http.json).

TSG's self-diagnostic suite (tsg/tsg-diagnose) imports the full badssl.com test-certificate corpus (superfish, eDellRoot, mitm-software, captive-portal, revoked, weak-key variants, etc.) to continuously validate its own TLS-interception logic in production, adds test cases for TLS ClientHello fragmentation handling by the intercept engine, and documents that firewall DENY blocking was changed from sending only a FIN to sending FIN-then-RST to close connections.

TSG's policy-API test suite (zhaokun/tsg_policy_api, 508 commits) enumerates the full deny-action taxonomy exercised against combinations of IP/SNI/APP/flag match conditions and negation: deny_alert (HTTP 200 with profile or text body), deny_block (403/404 with profile or text), deny_drop, deny_noreset, deny_redirect (DNS with 1-3 forged answers), and deny_rate_limit (high/low), plus "allow" and "shunt" (traffic-diversion) actions — a precise map of TSG's blocking/throttling/redirect action space.