Beeline mobile users in certain Russian regions observed complete IP-based whitelisting: non-whitelisted IPs were unreachable at the ICMP level (traceroutes returned empty), TCP SYN packets were delivered but TLS ClientHello was silently dropped, and any domain resolving to a non-whitelisted IP was inaccessible regardless of SNI value. Only a curated set of IPs (primarily .gov.ru domains plus selected commercial sites) remained reachable.

Non-whitelisted DNS resolvers — including 1.1.1.1, 9.9.9.9, and Yandex DNS — were blocked with ICMP also blocked, while Beeline's own UDP DNS and Google's 8.8.8.8 remained accessible and non-hijacked (verified via Akamai WHOIS). This selective resolver blocking constrains which DNS infrastructure circumvention tools can use for bootstrap.

Issue body (its0ka, Sep 7 2025) detection

SNI spoofing — sending a whitelisted domain (e.g., yandex.ru) in the ClientHello while connecting to a non-whitelisted IP — did not bypass the block: any SNI value worked when connecting to a whitelisted IP, but no SNI value worked when connecting to a non-whitelisted VPS IP. This confirms the enforcement is IP-based rather than SNI-based, and SNI spoofing provides no circumvention value in this regime.

Issue body (its0ka, Sep 7 2025) evaluation

The whitelist enforcement drops TLS ClientHello packets to non-whitelisted destination IPs while still accepting the TCP SYN, meaning the block occurs at or after the TCP handshake completes but before application-layer data is processed. This behavior is consistent with TSPU-level in-path interception rather than BGP null-routing.

Issue body (its0ka, Sep 7 2025) detection

Stunnel tunneling achieved temporary circumvention before being blocked, and the enforcement was observed consistently across Beeline and Tele2 in affected regions, suggesting centralized TSPU-level implementation rather than per-ISP configuration. The whitelist appeared in September 2025 following a period of mobile-network shutdowns in some Russian regions or cities.

Comments (Ximerixx, someone2037492034, Sep 2025) deployment

LetsVPN's exit is described as part of a broader pattern: a wave of 'airport' (proxy subscription service) outages across multiple providers in April 2026, documented in a companion article titled '2026年四月份各大机场断线详解,' indicating coordinated or systematic GFW blocking affecting the circumvention ecosystem broadly during this period.

2026-anon-letsvpn-vpn §协议写死，特征太明显 (reference to companion article) dpitls-fingerprintip-blocking

The article documents that large-scale 'one-click' commercial VPN providers with static protocol stacks have become effectively non-viable in China, while subscription-based proxy node services using open-source clients (Clash, Shadowrocket) with server-side rapid IP and datacenter switching demonstrate substantially greater resilience to GFW blocking waves.

2026-anon-letsvpn-vpn §为啥傻瓜式一键VPN越来越难活 & §应该怎么选替代方案 dpitls-fingerprintip-blocking

PCAP analysis from inside Russia confirmed the filter is fingerprint-based, not IP-based: every failed DTLS connection shared the same JA3/JA4 fingerprint, while a single connection with a different JA3/JA4 fingerprint succeeded and sustained full-speed data transfer, eliminating the hypothesis that censors had enumerated the large proxy IP space.

2026-wkrp-snowflake-targeted-dtls-filtering kad09 original report, Issue #422 comment (Apr 5 2026) tls-fingerprintip-blocking

Russia's mobile operators (MTS, Beeline, MegaFon, Yota) deployed a TCP connection-freezing technique in mid-2025 that silently halts packet delivery after approximately 15–20 KB of server-to-client data within a single TCP connection, without sending RST packets, causing clients to stall until timeout. The trigger requires: (1) TLS 1.3 or TLS 1.2 over TCP, (2) destination IP located in a foreign datacenter ASN (e.g., Hetzner, DigitalOcean), and (3) cumulative in-connection payload exceeding the threshold.

2025-hyperion-cs-censor-has-new Problem description dpitls-fingerprintip-blocking

Dominant failure modes differ systematically by country: China (AS45090) shows connect timeouts in 75% of DoT failures (IP-level blocking); Kazakhstan (AS48716) shows post-TLS-handshake timeouts in 72% of DoT failures (likely ACK or segment discard after handshake); Iran (AS197207) shows TLS handshake timeouts in 80% of DoT failures. Packet capture analysis confirmed that timeouts during and after the TLS handshake correspond to unacknowledged TCP segments, not connection resets.

2021-basso-measuring §V-F, §V-G, Table VIII ip-blockingtls-fingerprintmiddlebox-interference

In AS197207 (Iran, MCI), approximately 50% of DoT endpoints failed consistently — the only case across all tested ASN/protocol combinations where failure exceeded 20%. In Kazakhstan (AS48716) and China (AS45090), more than 80% of DoT and DoH endpoints were always reachable.

2021-basso-measuring §V-F, Table VII ip-blockingsni-blockingtls-fingerprint