Show HN: PoC - VPN over WebRTC to Bypass Whitelists

Most circumvention tools are built against blocklist firewalls: the operator says "everything is allowed except these protocols and hosts", and the game is making your VPN traffic not look like the blocked things via Wireguard, Shadowsocks, obfs4, etc.

The whitelist concept flip the model - the operator says "everything is blocked except this short list of domestic services", and suddenly there's nothing left to hide 'as': traffic doesn't have to look unlike the blocked stuff, it has to literally be one of the allowed things. Iran has been rolling this out in waves through 2024 and 2025, Russia has been experimenting with the same shape, China has been doing variants for years. This pattern is spreading and I don't like it.

The interesting opening is that some of those whitelisted services are video calling platforms. A WebRTC call is, structurally, a bidirectional encrypted media stream between two peers, mediated by an SFU (Selective Forwarding Unit) that the network operator has decided to trust. So, technically, you can stuff arbitrary bytes into the payload on one end and pull them out the other, you've got a covert channel that DPI can't distinguish from a normal call.

There are two places to put those bytes inside a call. The first is a DataChannel, when the platform exposes one. Not all DataChannels are equal: some are restricted to signalling (presence, chat, control messages) and won't carry arbitrary payloads, some are open but routed through SFU paths that weren't built for throughput and cap out at a few hundred KB/s, and some are wide-open SCTP streams that move tens of megabits without complaint (best scenario).

The second is fake VP8 frames on a published video track, used when DataChannels aren't available or aren't useful. The ceiling depends on what the SFU lets through. A single track in this configuration tops out around 6.5 Mbps. A second track (screenshare alongside the camera) roughly doubles that when the platform allows it, but some SFUs have a frame rate cap per track (120 or 240 FPS is typical), and pushing above it trips congestion control on their side, which stalls the stream for a while before it recovers.

The implementation splits into two roles: a creator on the free-internet side, and a joiner on the censored side. The creator authenticates against the target platform, opens a call, and waits. The joiner connects to that call and exposes a local SOCKS5 proxy.

So the architecture looks like:

[Censored] Apps -> VpnService/TUN -> tun2socks -> SOCKS5 -> Joiner --- SFU --- Creator -> Internet [Free]