At Gerus-lab, we build systems for clients across Web3, AI, and SaaS — and a recurring theme in our infrastructure conversations is network reliability in restricted environments. Recently, a piece of research from the Russian internet community caught our attention: a full technical teardown of how whitelist-based internet filtering actually works at the packet level. We read it. We rebuilt the mental model. And we thought the western dev community needed to hear this.
Because this isn't just a Russia story. It's a playbook that authoritarian governments worldwide are copying — and understanding it makes you a better infrastructure engineer anywhere.
The Shift From Blacklists to Whitelists
Classic internet censorship runs on blacklists: a list of forbidden domains (YouTube, Twitter, etc.), everything else passes. It's reactive, easy to bypass with a VPN, and constantly playing whack-a-mole with new proxies.
Whitelists flip the model entirely:
Everything is blocked by default. Only explicitly approved destinations pass.
If your destination IP isn't on the approved list — your packets literally never leave the operator's network. No ICMP. No TCP handshake. No UDP. The bytes just vanish at hop 2.
This is what's been rolling out across Russian mobile networks. Researchers scanned 46 million Russian IP addresses through a mobile interface (Megafon) and found only 63,126 IPs that responded — that's 0.14% of the address space surviving the filter.
Two Layers of Filtering: L3 + L7
The architecture operates on two simultaneous layers. Understanding both is crucial if you're building resilient systems.
Layer 3 (Network): CIDR-Based IP Filtering
At the IP level, a router at hop 2 from the user simply drops all packets destined for non-whitelisted IP ranges. No response. No RST. Just silence.
Packet → [L3: Is destination IP whitelisted?]
↓ NO → DROP (packet disappears silently)
↓ YES → continue to L7 check
For whitelisted IPs, port-level filtering also applies:
| Protocol/Port | Status |
|---|---|
| ICMP | OK |
| TCP:80 | OK |
| TCP:443 | OK |
| UDP:443 (QUIC) | Blocked |
| UDP:53 (DNS) | Blocked |
| UDP:51820 (WireGuard) | Blocked |
TCP on 80/443/22 works. Almost all UDP is killed — including QUIC, standard DNS, and WireGuard on its default port. This matters enormously for modern protocols.
Layer 7 (Application): DPI + SNI Inspection
If your IP passes L3, the Deep Packet Inspection system reads the TLS ClientHello and extracts the SNI (Server Name Indication) — the hostname you're connecting to. A separate SNI blacklist then decides whether to let the TLS handshake complete or inject a TCP RST.
The researchers ran an interesting test: using a whitelisted Yandex IP but presenting different SNI values:
| SNI Presented | Result |
|---|---|
| ya.ru | TLS OK, HTTP 302 |
| google.com | TLS OK, HTTP 406 |
| twitter.com | Connection reset |
| telegram.com | TLS OK, HTTP 406 |
Wait — google.com passes? Yes, because Google is blocked at L3 (IP level), but adding it to the SNI blacklist would break thousands of legitimate services that call Google APIs through their own IPs. The SNI blacklist is reserved for the most obvious offenders.
The TTL Trick: Finding Where the Filter Lives
Here's an elegant piece of network forensics. Every IP packet has a TTL counter that decrements by 1 at each hop. Linux starts at 64.
- Response from ya.ru → TTL 53 (11 hops away, real server)
- Response from blocked Telegram IP → TTL 62 (2 hops away)
Telegram's servers aren't 2 hops from a Russian mobile user. That response was generated by the filtering device itself, sitting right after the operator's first router:
[User] → [Operator router] → [DPI device] → [Internet]
The DPI box synthesizes fake TCP RSTs and pretends to be the remote server. At 2 hops from the user.
Who's on the Whitelist?
Out of 46 million Russian IPs, 63,126 survive. The top ASNs tell a story:
| # | Organization | IPs Whitelisted |
|---|---|---|
| 1 | Yandex.Cloud | 12,906 |
| 2 | Timeweb | 2,904 |
| 3 | Rostelecom | 2,312 |
| 4 | VK | 1,958 |
| 5 | Beget | 1,644 |
| 6 | Selectel | 1,037 |
Yandex.Cloud alone holds 1 in 5 whitelisted IPs. Why? Because so much of Russia's state-adjacent internet infrastructure runs on it. Removing Yandex from the whitelist would break government services, banking, and state media. So it stays — and becomes the primary bypass vector.
Engineering Around It: What Actually Works
This is where it gets practically useful. If you need to build systems that must function in heavily filtered environments — enterprise tools in restricted regions, IoT fleets, global SaaS — here's what the research shows:
1. Serverless Functions on Whitelisted Cloud Providers
Yandex Cloud Functions are on whitelisted IPs. If you proxy through a serverless endpoint on a whitelisted provider, your traffic rides along legitimately. We've helped clients architect multi-region relay layers for exactly this reason — see our infrastructure work at gerus-lab.com.
2. Domain Fronting (Where Still Available)
Presenting a whitelisted CDN domain as your SNI while routing to a different backend. Increasingly detected, but understanding why it worked helps you design alternatives.
3. VPS on Whitelisted ASNs
Timeweb (2,904 IPs), Beget (1,644), Selectel (1,037+) — these Russian hosting providers are on the whitelist. A VPS there can serve as a relay. The key insight: it's not about geography, it's about whether the specific ASN made the approved list.
4. TCP-Wrapped Tunnels on Ports 80/443
Since UDP is almost entirely killed — WireGuard on :51820, QUIC — TCP-based tunneling on allowed ports becomes the fallback. OpenVPN TCP mode, stunnel, websocket-based proxies on port 443 — these survive L3 filtering if the destination IP is whitelisted.
5. WebRTC Tunneling
WebRTC's ICE/STUN negotiation can sometimes traverse filters because IP range negotiation happens dynamically. Complex but viable in some configurations.
What This Means for Your Architecture
If you're building anything that needs to work globally — and increasingly that includes regions with sophisticated filtering — your architecture needs:
1. UDP fallbacks. QUIC, WireGuard, and UDP DNS fail in whitelist environments. Design TCP fallbacks into your protocol stack from day one.
2. ASN awareness. In a whitelist world, your hosting provider's ASN determines whether you exist at all for certain users.
3. SNI opacity plans. Even with TLS 1.3, SNI in ClientHello is plaintext. Encrypted Client Hello (ECH) is the future fix, but adoption is slow.
4. Distinguish silence from RST. When packets disappear with no response (no RST, no ICMP unreachable), you're hitting L3 filtering, not application-layer blocking. Your monitoring needs to tell the difference.
At Gerus-lab, we design backend and infrastructure systems for clients operating across diverse regulatory environments. The whitelist model is spreading — China has used it for years, and the architecture is being copied. Understanding the technical substrate of censorship isn't political; it's engineering literacy.
The Consistency Problem
One last fascinating wrinkle: SNI filtering rules are inconsistent across ASNs.
| SNI | Via Yandex | Via VK | Via MAX |
|---|---|---|---|
| telegram.org | OK | FAIL | OK |
| twitter.com | OK | FAIL | FAIL |
| youtube.com | OK | OK | OK |
The same SNI passes through Yandex's infrastructure but gets blocked via VK's. Either different DPI rule sets per ASN, or some nodes haven't been updated. There's no unified blacklist — it's a patchwork.
Reassuring (the system isn't omnipotent) and alarming (you can't predict behavior without per-path testing) in equal measure.
Conclusion
Whitelist-based filtering is technically elegant and politically brutal. It inverts the assumption that the internet is open by default — requiring government approval for every destination IP. At 0.14% whitelist penetration, it transforms a global network into a national intranet.
But it has seams. Inconsistent SNI rules, large cloud providers that can't be removed, TCP-only survival paths — the architecture creates its own bypass vectors.
If you're building systems that need to survive in such environments, model these constraints from day one. We've done this for several clients at Gerus-lab, and the lesson is always the same: know your packet path, know your ASN, and never assume UDP works.
Want to talk infrastructure design for restricted environments? Reach out at gerus-lab.com — we work with startups and scale-ups who cannot afford their stack going dark in key markets.
Inspired by research published on Habr by the openlibrecommunity team. Data from scanning 46M Russian IPs via Megafon mobile interface, April 2026.
Top comments (0)