Why Your VPN Gets Blocked and How Domain Fronting Solves It

If you've ever set up a VPN on a VPS and watched it work perfectly for about two days before suddenly dying, you're not alone. I've been there — staring at connection timeouts, wondering if my server crashed, only to realize the network I'm on has started blocking my traffic.

The problem isn't your VPN software. The problem is that VPN traffic is increasingly easy to fingerprint and block.

The Root Cause: VPN Traffic Sticks Out

Deep packet inspection (DPI) has gotten terrifyingly good. Even if your traffic is encrypted, the pattern of that traffic gives it away. OpenVPN has a recognizable handshake. WireGuard uses a fixed UDP port and has distinctive packet sizes. Even SSH tunnels exhibit telltale flow patterns.

Here's what a typical blocked scenario looks like:

Client → VPN Server (port 1194/UDP)
         ↓
    DPI Firewall detects OpenVPN handshake pattern
         ↓
    Connection RST or silently dropped

The firewall doesn't need to decrypt anything. It just recognizes the shape of the conversation. Some networks go further and block all traffic to known VPS IP ranges from major cloud providers.

So you're stuck. Your VPN works on your home network but fails on restrictive ones. What do you do?

The Domain Fronting Technique

Domain fronting is a technique that hides your actual destination behind a trusted domain. The idea is simple but clever: your TLS connection says it's going to google.com (in the SNI field), but the HTTP Host header inside the encrypted tunnel points somewhere else entirely.

From the firewall's perspective, it sees HTTPS traffic going to Google. And nobody blocks Google.

# What the firewall sees (TLS layer):
SNI: script.google.com → Allowed ✓

# What's actually inside the encrypted TLS session:
Host: your-secret-relay.googleusercontent.com
Body: [encrypted VPN payload]

This works because large CDNs and cloud platforms often route requests based on the Host header after TLS termination, not the SNI. Your traffic rides on the reputation of a trusted domain.

How a Google Apps Script Relay Works

An interesting open-source project called GooseRelayVPN recently showed up on GitHub Trending, and it demonstrates this concept in a practical way. It tunnels raw TCP through Google Apps Script — essentially using Google's infrastructure as a relay to reach your own VPS.

The architecture has three pieces:

1. Local SOCKS5 proxy — runs on your machine, accepts connections from your apps
2. Google Apps Script relay — a script deployed on Google's infrastructure that forwards your encrypted data
3. VPS exit server — your actual server that makes the final connection to the internet

The flow looks like this:

Your App → SOCKS5 Client (local)
    → HTTPS to script.google.com (looks like normal Google traffic)
    → Google Apps Script forwards payload
    → Your VPS exit server
    → Internet

All traffic between your client and the relay is encrypted with AES-256-GCM before it even enters the HTTPS tunnel to Google. That means even if someone could inspect the Apps Script execution (they can't, but hypothetically), they'd see nothing useful.

Why SOCKS5 Instead of a Full VPN?

A full VPN captures all system traffic at the network layer. A SOCKS5 proxy works at the application layer — only apps you explicitly configure will use it. This is actually an advantage in many scenarios:

• Selective routing — only tunnel the traffic that needs it
• No kernel modules — no tun device, no admin privileges needed to set up
• Less fingerprinting surface — you're not creating a virtual network interface that might leak DNS or other metadata
• Easier debugging — you can see exactly which apps are using the proxy

For browsers, you can use extensions like FoxyProxy to route specific domains through your SOCKS5 proxy while letting everything else go direct.

The AES-256-GCM Layer

You might wonder why there's an additional encryption layer when the traffic already goes through HTTPS. Two reasons:

First, defense in depth. The HTTPS connection terminates at Google's edge. Between Google's infrastructure and your VPS, the data needs to travel again. Without the inner encryption, that leg would be exposed.

Second, integrity verification. GCM (Galois/Counter Mode) provides authenticated encryption — it doesn't just encrypt, it also guarantees the data hasn't been tampered with. Each chunk of forwarded data can be verified by the exit server.

# Conceptual example of AES-256-GCM encrypt/decrypt
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

key = AESGCM.generate_key(bit_length=256)  # 32-byte key
aes = AESGCM(key)

# Encrypt with a unique nonce per message
nonce = os.urandom(12)  # 96-bit nonce, MUST be unique per encryption
ciphertext = aes.encrypt(nonce, plaintext, associated_data=None)

# Decrypt — will throw InvalidTag if tampered
decrypted = aes.decrypt(nonce, ciphertext, associated_data=None)

The nonce management is critical here. Reusing a nonce with AES-GCM completely breaks the security guarantees. Any serious implementation needs to either use a counter or generate random nonces with a large enough space to make collisions negligible.

Limitations You Should Know About

Before you get too excited, there are real tradeoffs:

• Latency — you're adding an extra hop through Google's infrastructure. Every request goes client → Google → VPS → destination. Expect higher round-trip times.
• Throughput — Google Apps Script has execution time limits and payload size constraints. This isn't going to replace a proper WireGuard tunnel for bulk data transfer.
• Google's terms of service — using Apps Script as a traffic relay is almost certainly not what Google intended. Your script could get shut down. Don't build your entire infrastructure on this.
• Domain fronting availability — major cloud providers have been gradually closing domain fronting loopholes. Google, Amazon, and Azure have all made moves to restrict it. What works today might not work tomorrow.

When This Actually Makes Sense

This approach isn't for everyday VPN use. It's for specific scenarios:

• Testing network security — understanding how your own network's DPI handles domain-fronted traffic
• Research — studying censorship circumvention techniques
• Emergency access — when you need to reach your own infrastructure from a heavily restricted network

Prevention Tips for Network Administrators

If you're on the other side — trying to understand and detect this kind of traffic — here's what to look for:

• SNI/Host header mismatches — inspect whether the TLS SNI matches the HTTP Host header where possible
• Unusual Apps Script traffic patterns — high-volume, sustained HTTPS connections to script.google.com from a single client is suspicious
• Traffic analysis — even through domain fronting, the timing patterns of proxied traffic look different from normal web browsing

Wrapping Up

Domain fronting through cloud services is a fascinating technique that sits at the intersection of networking, cryptography, and platform architecture. Projects like GooseRelayVPN are valuable because they make these concepts concrete and testable rather than theoretical.

That said, I'd treat this as a learning tool and a proof-of-concept, not a production solution. The reliance on a third-party platform's unintended behavior makes it inherently fragile. For reliable, long-term VPN needs, look into tools like obfs4 bridges or Shadowsocks that are specifically designed for protocol obfuscation without depending on a single provider's infrastructure.

The real takeaway here isn't about any specific tool — it's understanding why VPN traffic gets blocked and what techniques exist to make encrypted traffic blend in with normal web activity. That knowledge is useful whether you're building network security tools or just trying to understand how modern censorship works.