Map

Whitelist Internet Blocking

Wiki conceptcensorshipnetworkingrussiaroskomnadzor ↳ show in map Markdown
title
Whitelist Internet Blocking
type
concept
summary
Default-deny national filtering where only explicitly approved destinations resolve
tags
censorship, networking, russia, roskomnadzor
sources
vpn-configs-for-russia
created
2026-04-21
updated
2026-04-21

For the current (April 2026) state of which specific methods are working against this filter — VLESS+Reality+XHTTP, AmneziaWG 2.0, and so on, ranked by reliability with dates — see russia-vpn-bypass-state-2026-04. The enforcement layer is tspu.

Whitelist internet blocking inverts the usual censorship model. Instead of "everything is allowed except this list of blocked things" (a blacklist), the network enforces "everything is blocked except this list of approved things" (a whitelist). Only destinations on the approved list — specific domains, specific IP subnets — resolve and connect. Everything else fails silently.

The Russian government has been rolling this out through mobile carriers (Megafon, Beeline, MTS, T2, Yota) since 2024, with the scope expanding over 2025 and accelerating in early 2026 — tspu's February 13 2026 update blocked WireGuard, OpenVPN, and old AmneziaWG across carriers simultaneously. The typical experience for a subscriber in whitelist mode: Yandex loads, VK loads, Gosuslugi loads, Sberbank loads, Mail.ru loads, Rutube loads. Google doesn't. Gmail doesn't. Anything outside the approved set doesn't.

How it differs from blacklist blocking

Most discussions of "internet censorship" implicitly mean blacklist blocking: the censor maintains a list of forbidden domains/IPs and drops packets to them while letting everything else through. DPI for SNI filtering, geoip blocks on specific services, TCP resets on Telegram — all blacklist mechanisms. russia-v2ray-rules-dat is a response to this regime: it packages the blocked list so your client can know what to route through a proxy.

Whitelist blocking is categorically different:

  • The default-deny posture. A brand-new domain is blocked by default until it's explicitly approved. This breaks the "route the blocked stuff through a proxy" strategy, because everything off-list is blocked, including the VPN endpoint you'd normally route to.
  • Enforcement at the carrier, not just DPI. Blacklist filtering often works via DPI inspecting traffic flows; whitelist filtering often works at DNS resolution (only whitelisted names resolve) and at IP routing (only whitelisted IP subnets reach the global internet). The filter applies before your VPN client can even open a connection.
  • Politically easier to defend as "protecting critical services." Presenting the restriction as "during an emergency, only essential services work" is more palatable than the blanket "we are blocking things" framing.

Why bypass is harder

A classic VPN needs to reach some endpoint off-list — an IP your provider controls, a domain you registered. Under whitelist blocking, that endpoint is unreachable by default. You can't even start the handshake.

The countermeasures that work exploit the structure of the whitelist itself:

  1. CIDR-based bypass. Host the VPN endpoint on an IP owned by a whitelisted entity. Russian whitelists include subnets belonging to VK, Yandex, CDNVIDEO, Beeline, and other approved hosters. If you rent a VPS inside one of those subnets (via shared hosting, a colocation deal, or resold capacity), connections to your endpoint look like connections to a whitelisted hoster. vpn-configs-for-russia publishes subscription files where every endpoint IP lives inside one of these subnets — the WHITE-CIDR-RU-*.txt series.
  2. SNI-based bypass. If the filter inspects only the TLS SNI, not the destination IP, you can set the outer SNI to a whitelisted hostname (e.g., yandex.ru) while the actual destination is your proxy. This is a cousin of domain-fronting — the outer hostname is a decoy and the real work happens inside the encrypted tunnel — except here the "inner" endpoint is your own, not a tenant on the same CDN. VLESS-Reality is the protocol most commonly used for this because its TLS handshake survives active probing.
  3. Using VLESS-Reality (as a protocol choice). Reality sets its TLS handshake to be byte-for-byte indistinguishable from a real TLS handshake to the fronting domain. If the filter tries active probing — replaying the ClientHello to see if the destination acts like a real TLS server — Reality's server-side logic forwards the probe to the real fronting target, so the probe returns a "yes, this is a real server" response. This is why VLESS-Reality dominates the whitelist-bypass subscriptions.

Note that (1) and (2) only work as long as the whitelisted entity's infrastructure is still accessible. If Roskomnadzor tightens the whitelist to specific IPs within VK's range rather than the whole range, the CIDR bypass breaks. This is an arms race with asymmetric update speeds: regulators change whitelists in batches, circumvention tooling responds per-day.

Implications for circumvention tool design

The existence of whitelist blocking changes what a well-designed circumvention stack has to do:

  • Endpoint IP matters. You can't just rent the cheapest VPS on DigitalOcean anymore — you need endpoints inside approved subnets, which is specialized and expensive.
  • Subscription freshness becomes critical. Approved-subnet endpoints rotate faster than global VPS endpoints because the provider has less margin and the regulator can revoke subnet approval. vpn-configs-for-russia tests hourly from inside Russia specifically because the reliability surface is this volatile.
  • Testing has to happen from inside. Checking "is this endpoint up" from outside Russia tells you nothing about whether a Russian mobile carrier's whitelist currently permits its subnet. You need a vantage point inside the blocked network.
Linked from