Services blocked by the Russian web watchdog Roskomnadzor (WhatsApp, Telegram, Instagram, X, and foreign media outlets) occasionally become accessible without using a VPN. Our readers report this regularly.

Since the introduction of the so-called “sovereign internet” law, the key censorship tool in Russia has been the Technical Means of Countering Threats (TSPU). In the networks we study, their operation manifests as interference with traffic flow at the ISP infrastructure level. However, external measurements do not allow for reliably determining the physical topology or the exact insertion point of the filtering components.

The TSPU operates using Deep Packet Inspection (DPI) technologies. Filtering is implemented across multiple layers: DNS interception, IP blocking (IP blackholing), connection resets based on SNI signatures (DPI RST injection), and protocol signatures (for example, blocking VPN protocols such as WireGuard and Shadowsocks).

When these services “come back to life,” ordinary users tend to treat it as a technical glitch. For researchers and developers of circumvention tools, however, the value lies not in the temporary availability itself, but in understanding how exactly the filtering system fails at the network level (DNS, L4 TCP, L7 TLS/SNI).

We set out to investigate the technical nature of these TSPU “failures” and, using network probing techniques, to look under the hood of the TSPU. We are going to analyse the layers that make up the blocking system and determine why this wall regularly develops holes.

Methodology of our testing

For testing, we wrote a Bash script that emulates the behavior of a user client. We took measurements simultaneously from an uncensored control node (direct access from the EU) and a censored node in Russia (a home ISP in St. Petersburg).

To get a broad picture, we split our targets into groups: messaging apps (WhatsApp, Signal, Telegram), media outlets (Meduza, the BBC, Novaya Gazeta Europe), VPN service and anti-censorship project websites, and a control group of companies whose resources currently aren’t blocked (Nvidia and Microsoft), as well as companies whose resources are formally open but are being throttled, or blocked in test mode for specific ISPs (YouTube and Apple).

We tested availability along four vectors:

1. DNS Resolution: We queried Google DNS and Yandex DNS to detect spoofed responses (DNS spoofing). In parallel, we obtained the real IP via Cloudflare DoH (DNS over HTTPS).
2. L4 TCP Handshake: We checked whether a connection could be established on port 443 to the real IP address.
3. L7 CURL Test: Sending an HTTPS request pinned to the IP address (bypassing the local DNS cache).
4. L7 Cross-SNI Test (our key methodology): We sent a request to a known clean, unblocked IP address (1.1.1.1), but specified a blocked domain in the SNI field of the Client Hello (for example, web.whatsapp.com).
   – How it works: If the network is unrestricted, the server at 1.1.1.1 will simply return an SSL error (since it has no certificate for WhatsApp). But if the TSPU (Russia’s mandatory DPI/traffic-filtering equipment, deployed under the “sovereign internet” law) sits on the path, it reads the SNI, triggers on the blocked keyword, and silently drops the packet (we get a timeout instead). This lets us conclude with high confidence that DPI filtering is at work, regardless of where the traffic is actually headed.

Mechanics

The structure of the TSPU

Log analysis showed that the TSPU doesn’t just block a “site” outright. It uses a multi-layered system that varies from service to service.

• Layer 1. Full IP blocking (L4 blackholing). Example: Telegram. For web.telegram.org, DNS returns the correct address (149.154.167.99) on every node. But from St. Petersburg, the TCP connection attempt times out, and the traceroute cuts off at the fifth hop. This is a hard block at the routing level: the server is completely unreachable by IP at the network layer.
• Layer 2. Surgical SNI-based dropping (L7 DPI). Example: WhatsApp and ProtonVPN. With web.whatsapp.com and protonvpn.com, the picture is more interesting. The TCP connection to their IP addresses succeeds (the handshake completes). But as soon as the client sends a Client Hello packet naming these domains, the connection just hangs (a timeout of more than 10 seconds). Our Cross-SNI test against 1.1.1.1 confirmed this: TSPU reads the header and kills the session purely based on the domain signature, while leaving the IP address itself reachable.
• Layer 3. Tampered DNS (DNS spoofing). Example: Meduza, Novaya Gazeta, and Teplitsa. For independent media outlets, and even for our own project, the most aggressive mix applies. ISP-provided DNS, and even public DNS resolvers (8.8.8.8, intercepted over UDP/53), return IP addresses like 8.47.69.6 or 8.6.112.6 instead of the real Cloudflare addresses. These are known Roskomnadzor (Russia’s communications regulator) stub addresses. And if a client uses DoH and learns the real IP, the SNI filter (Layer 2) will still kill the connection.

TSPU’s decision chain (the pipeline)

Analyzing TSPU’s traffic reveals a sequential pipeline: DNS query ➔ TCP handshake (SYN) ➔ TLS ClientHello (SNI) ➔ HTTP traffic.

The logs show that different services “die” at different stages of this pipeline:

• Telegram: Dies at the TCP stage. DPI doesn’t even come into play, since the route to the server is already dropped.
• WhatsApp / ProtonVPN: Get through TCP, but die at the TLS ClientHello stage.
• Signal: Our logs show a paradox: DNS spoofing is active, but if we use the real IP (via DoH), TCP succeeds, TLS succeeds, and we get an HTTP 200. This proves that the DNS-spoofing module and the DPI analyzer work independently of each other.

Why blocked services intermittently become accessible

We don’t yet know the exact mechanisms at play. Based on what we’ve observed, we can put together some hypotheses.

• Hypothesis 1: Layer desynchronization and fail-open mode. The block relies on a patchwork of DNS and SNI checks. If an app (say, mobile Signal or WhatsApp) uses its own encrypted DoH, it easily bypasses Layer 3 (DNS spoofing). DPI then takes over. But TSPU appliances occasionally become overloaded or reboots when updating its signatures. To avoid taking down the ISP’s entire internet connection, TSPU switches into a mode that passes traffic through without inspection (fail-open). We caught this happening directly in our logs: a curl request to signal.org from St. Petersburg succeeded (HTTP 200), even though our test clearly indicated the domain should be blocked. The equipment let the packet through.
• Hypothesis 2: IP rotation on CDNs. Many resources (the BBC, for one) use dynamic load balancers on global CDNs (Fastly, Cloudflare). Their IP addresses change constantly. If TSPU tries to use IP blocking as a backup for DPI, it simply can’t keep up with the address rotation. For a while, traffic flows freely, until the SNI filter catches up with it.
• Hypothesis 3: Asynchronous database updates (eventual consistency). TSPU is a distributed system made up of thousands of nodes across the country. Updating them all instantly isn’t possible. Our logs show that different DNS resolvers (Google and Yandex) return different answers for the same blocked domain: one returns a stub address, the other the real IP. This means regional TSPU nodes update their blocklists out of sync with each other. While one node is blocking traffic, a neighboring one might keep letting it through for several more hours.
• Hypothesis 4: Asymmetric routing (BGP). On the internet, traffic isn’t required to return by the same route it left on. TSPU, though, is a system that keeps track of a user’s previous interactions (sessions). Each new request draws on data from past sessions, and the system needs to see both the request and the response to reconstruct a session. If dynamic BGP route changes send the request through a node with TSPU, but the server’s response comes back over a different link with no filtering, DPI lets the traffic through. To the user, this looks like “WhatsApp suddenly started working.”

Recommendations for developers

Understanding how DPI works also lets developers build specific circumvention methods. For example, knowing that TSPU looks for the domain in the ClientHello packet (Layer 2), tools like GoodbyeDPI split that packet into fragments, making it “invisible” to the censor.

One caveat: we haven’t yet run large-scale tests of these tools on our own setups, but at the level of network theory, circumventing DPI relies on the following weaknesses:

• Attacking packet reassembly (TCP segmentation): Since TSPU needs to read the domain name inside the ClientHello packet, the logical move is to fragment that packet at the TCP level (for example, splitting the string web.whatsapp.com across different segments). Historically, DPI systems avoided packet reassembly because of the enormous memory load it puts on backbone-speed links, and preferred to just let such traffic through. Popular tools like GoodbyeDPI and Zapret are built on this principle, although TSPU developers keep adapting their algorithms to counter them.
• Blind spots in topology awareness (TTL spoofing): A desynchronization method: a fake packet with the blocked SNI is sent, but with an artificially low time-to-live (TTL). The idea is for that packet to die right after it passes through TSPU (at the third or fourth hop), before it reaches the real server. A genuine packet follows, which DPI may ignore, treating the session as already handled.
• Encrypting metadata (ECH — Encrypted Client Hello): If Layer 2 depends on a plaintext SNI, the fix is to encrypt it. The TLS 1.3 standard, with the ECH extension, hides the actual destination domain (replacing it with a neutral one, such as cloudflare-ech.com). In theory, this completely neutralizes DPI. In practice, it has turned into a classic cat-and-mouse game: the regulator adapts and periodically resets any connection where it detects the mere presence of the ECH extension.

TSPU isn’t a monolithic concrete wall — it’s more like a multi-layered sieve. When a service becomes reachable without a VPN, that’s usually the result of a temporary desync between these layers, DPI overload, or a lucky IP rotation on the CDN side — not a sign that censorship is easing.