Why I Built This
I needed a way to bypass network restrictions that were blocking standard VPN protocols. The network I was dealing with had aggressive Deep Packet Inspection (DPI) that could identify and block OpenVPN, WireGuard, and even obfuscated SSH tunnels. But email traffic on port 587 (SMTP with STARTTLS) was always allowed through—because blocking it would break legitimate business communication.
The idea was simple: make TCP traffic look like email traffic during the initial handshake, then switch to a binary tunnel once TLS encryption was established. DPI systems would see a normal SMTP session starting up, complete with proper TLS negotiation, and let it through.
My Real Setup
I ran this on a cheap VPS with a free DuckDNS domain pointed at it. The server side needed:
- Port 587 open (standard SMTP submission port)
- A domain name for TLS certificate validation
- Python 3.8 or newer
On the client side, I tested this from:
- A restrictive corporate network that blocked all VPN protocols
- A public WiFi network with aggressive filtering
- A residential ISP that throttled encrypted traffic
The client ran on my laptop (Linux) and connected through the tunnel to access blocked services. I configured Firefox to use the local SOCKS5 proxy that the client created on port 1080.
How I Set It Up
Server Configuration
I started with a fresh Ubuntu VPS and ran the installer script. The process was straightforward:
- Got a free DuckDNS subdomain and pointed it to my VPS IP
- Ran the one-line installer which handled dependencies, certificates, and systemd service setup
- Created my first user account, which generated a pre-shared secret
The installer automatically generated self-signed TLS certificates. This worked fine because the client was configured to trust the specific CA certificate, not rely on public certificate authorities. In a restrictive network, having the client validate against a known CA cert actually helped—it looked like a properly configured email client.
The server listens on port 587 and responds to initial SMTP commands exactly like Postfix would. It sends back proper EHLO responses, advertises STARTTLS, and handles the TLS upgrade. Only after TLS is established does it switch to the binary tunnel protocol.
Client Configuration
The server generated a ZIP file for my user account containing:
- Client Python scripts
- Configuration file with server details and my secret
- CA certificate for TLS validation
- Platform-specific launcher scripts
I extracted this on my laptop and ran the start script. The client:
- Connected to the server on port 587
- Performed a fake SMTP handshake (EHLO, STARTTLS)
- Established TLS encryption
- Authenticated using my pre-shared secret with HMAC-SHA256
- Switched to binary tunnel mode
- Started a local SOCKS5 proxy on port 1080
I then configured Firefox to use 127.0.0.1:1080 as a SOCKS5 proxy with DNS proxying enabled.
What Worked
The SMTP disguise was effective. DPI systems saw:
- Connection to port 587 (legitimate email submission)
- Proper SMTP protocol commands
- STARTTLS upgrade to encrypted connection
- Continued encrypted traffic that looked like email being sent
Once the TLS tunnel was established, the actual data transfer was fast. The protocol switched to a simple binary format with minimal overhead—just a 4-byte length prefix before each chunk of data. This was much faster than protocols that try to maintain the disguise throughout the entire session.
The per-user authentication worked reliably. Each user had a unique secret, and the HMAC-based authentication prevented replay attacks. I could add and remove users without restarting the server.
The client auto-reconnect feature was essential. When the network dropped the connection (which happened frequently on unstable networks), the client would automatically reconnect within a few seconds without requiring manual intervention.
What Didn't Work
Initial connection time was slower than a direct VPN. The SMTP handshake, TLS negotiation, and authentication added about 2-3 seconds before the tunnel was ready. For interactive browsing this was barely noticeable, but for applications that opened many short-lived connections, the overhead added up.
Some networks had rate limiting on port 587 to prevent spam. On one network, I could only establish about 10 connections per minute before getting temporarily blocked. This broke applications that opened many parallel connections.
The SOCKS5 proxy didn't work with all applications. Some software didn't support SOCKS5, and others didn't handle DNS-over-SOCKS correctly, which caused DNS leaks. I had to configure each application individually and test for leaks.
The server needed a real domain name for TLS to work properly. I tried using just an IP address initially, but certificate validation failed because the client expected a proper hostname. Free dynamic DNS services worked, but they occasionally had reliability issues.
Traffic analysis could still potentially detect this. While the initial handshake looked like SMTP, the traffic pattern after TLS establishment was different from real email. A determined analyst looking at connection duration, packet sizes, and timing could probably identify this as a tunnel. It worked against automated DPI, not against targeted investigation.
Key Takeaways
Protocol disguise only needs to fool the initial inspection. Once TLS is established, you can switch to an efficient binary protocol. The DPI system has already decided to allow the connection.
Using a legitimate, commonly-allowed port (587) was more effective than trying to hide on unusual ports. Networks rarely block email submission because it would break too many legitimate use cases.
Self-signed certificates worked fine when the client was configured to trust them. This avoided dependencies on public CAs and actually made the setup look more like a corporate email system with internal certificates.
Per-user secrets and IP whitelisting added useful access control. I could give different people access without sharing credentials, and revoke access individually when needed.
This is not a replacement for a proper VPN for general use. It's a specific tool for bypassing DPI in restrictive networks when standard protocols are blocked. The security model assumes the TLS encryption is protecting your traffic, not the SMTP disguise.
Free dynamic DNS services are good enough for this use case. I didn't need a paid domain—DuckDNS worked reliably and updated quickly when my VPS IP changed.
The biggest limitation is that this only works as long as networks continue to allow SMTP traffic. If a network blocks port 587 entirely, or requires email to go through their own servers, this approach fails. It's a cat-and-mouse game, not a permanent solution.
