Hiding Origins When Your CDN Won't Cover the Protocol

The Tunnel That Almost Works

Cloudflare Tunnel is the cleanest origin-concealment story in the industry. You install cloudflared, your origin connects out to Cloudflare's edge, and the world stops being able to reach your real IP. No firewall holes, no VPN, no anycast subscription. For HTTP and HTTPS, it just works.

But the moment your stack steps outside HTTP, the story falls apart.

Inbound SMTP on port 25? Tunnel won't carry it. Authoritative DNS on UDP/53? No. A game server on UDP/27015, a SIP gateway, a custom TCP protocol your trading desk speaks? Free-tier tunnels stop at L7. The expensive options that do cover them, Cloudflare Spectrum, Gcore, Path.net, start at four figures a month.

And so the typical "tunneled" infrastructure ends up looking like this:

www.example.com    -> tunnel -> origin (hidden)
api.example.com    -> tunnel -> origin (hidden)
mail.example.com   -> A 203.0.113.10 (origin, exposed)
ns1.example.com    -> A 203.0.113.10 (origin, exposed)
*.example.com      -> dig +short -> 203.0.113.10

The web is hidden. Everything else is a billboard pointing at the real box.

The Pattern That Generalizes

You don't need anycast. You need this:

cheap public frontend  <->  private tunnel  <->  hidden origin

The frontend speaks the protocol your tunnel can't. The tunnel hides the real backend. Frontends are disposable. If one is identified, you replace it. The origin never moves.

Below is the playbook, protocol by protocol.

SMTP: Stop Receiving Mail Directly

If your MX record points at your origin, your origin IP is in every email header that bounces back to a hostile sender. There is no fixing this except moving the receiving function off-box.

Inbound

• Managed receiver: SES, Postmark, Mailgun, ImprovMX. Set MX to their hostnames. They terminate, you fetch via IMAP through the tunnel.
• Self-hosted relay: a $5 VPS running Postfix as the public MX. It forwards to the origin over WireGuard. If the VPS is targeted, rotate it.

Outbound

This is the leak that gets ignored. Your origin sending mail directly burns its IP into Received: headers. Route every outbound mail through authenticated SMTP submission to a relay (SES, Postmark, your own Postfix). The recipient sees the relay, not the origin.

Authoritative DNS: Never Self-Host the Public Side

If ns1.yourdomain.com resolves to your origin and answers DNS queries, every recursive resolver on the planet has touched your real IP. There is no tunnel for authoritative DNS. There is one solution: don't host it yourself.

• Managed authoritative: Cloudflare DNS, Route 53, NS1, deSEC. Free tiers cover most use cases.
• Hidden primary, public secondaries: if you need to keep a primary on-prem (regulatory, custom view-based logic), run it private and let public secondaries serve queries via AXFR over your tunnel.

Either way, the origin never answers a query from the internet.

Arbitrary TCP: One Frontend, One Tunnel

If you have a service that speaks TCP but isn't HTTP, build the simplest reverse proxy you can:

# /etc/nginx/nginx.conf on a $5 VPS
stream {
    server {
        listen 5432;
        proxy_pass origin-via-wg.internal:5432;
        proxy_protocol on;
    }
}

The VPS is the public face. Your origin only accepts traffic from the WireGuard interface. The protocol can be Postgres, Redis, MQTT, custom binary, anything. nginx stream and haproxy both pass PROXY protocol so the origin still sees the real client IP for logging and per-IP rate limits.

The frontend is replaceable. You can run two or three of them in different geos, point your DNS at the healthy one, and have a kill-switch script that nukes a frontend the moment it gets attacked.

UDP and Real-Time Protocols: GRE or Anycast Wrappers

UDP is harder because it's stateless and latency-sensitive. nginx stream handles UDP but a single VPS isn't a scrubber. Three options:

• GRE tunnel from a scrubbing provider: OVH VAC, Path.net, X4B. They announce your IP via BGP from anycast, scrub, then GRE-tunnel clean traffic to your origin. The internet sees their anycast IP, not yours.
• Anycast WireGuard frontend with DNAT: more DIY, less robust under sustained attack.
• Cloudflare Spectrum (paid): arbitrary TCP/UDP behind anycast. Enterprise pricing, but if you're already CF-everything it's the easy answer.

IP-Whitelisted Partners: The Static Egress Trick

Banks, payment processors, SWIFT gateways, B2B APIs, all of these expect to see one specific source IP. The instinct is to put the origin's real IP on the whitelist. Don't.

origin (hidden)  -> tunnel -> egress proxy (one stable IP)  -> partner

Run a dedicated egress VM with a fixed IP. That's the IP your partners whitelist. Origin never directly initiates the partner connection. If the egress is ever scanned, you rotate it without touching the partner relationship (just update the whitelist).

The Six Leaks That Defeat All of This

Building the frontends is the easy part. The hard part is plugging the leaks that put your origin IP in public databases anyway.

1. Historical DNS

Securitytrails, dnshistory.org, viewdns.info, AlienVault OTX passive DNS. Every A record you ever published is archived forever. If your origin was once in DNS, it is always in DNS. The moment you decide to hide an origin, change its IP. The old one is burned.

2. Certificate Transparency

Every TLS certificate ever issued for your domain is in a public log. crt.sh exposes them all. Forgotten subdomains like internal-app.example.com or staging-old.example.com with origin-pointing A records are findable in seconds.

3. Outbound Callbacks

The most underestimated leak. Every webhook your origin sends, every npm install, every Sentry error report, every NTP sync touches a third party who logs your IP. If your security model assumes the origin is unreachable, route outbound through the same egress proxy too.

4. Default Vhost

Hit https://<origin-ip>/ directly. Does it serve your real site? Most nginx and Apache defaults will. Configure a catch-all vhost that returns a blank 444 or a decoy. If the IP confirms identity to anyone who guesses it, you've made the rest of this work pointless.

5. IPv6

Easy to forget. Your IPv4 is behind the tunnel, your AAAA record points straight at the origin's globally-routable IPv6. Cloudflare Tunnel terminates v6 too, but only if you actually configure it. Many setups don't.

6. Service Banners on the Raw IP

UFW only allowing CDN IPs to port 443 is great. UFW still allowing the world to hit port 22, 25, 587, 8080? Each open port is a confirmation oracle. SSH banners, SMTP HELO responses, HTTP Server: headers all confirm "yes, this is the box you're looking for." Lock down every port, not just the public ones.

How DDactic Tests This

Our recon pipeline runs eight separate origin-discovery methods against every CDN-protected domain we scan: crt.sh subdomain enumeration, MX resolution, SPF parsing, common-subdomain brute force, IPv6 AAAA enumeration, AlienVault OTX historical DNS, Shodan favicon-hash correlation, and Shodan TLS-cert-fingerprint correlation. Whatever we find then gets validated by probing the candidate IP with a Host-header bypass.

If any of those eight methods finds an origin, your hidden infrastructure isn't actually hidden. The same tools attackers use for free are the ones we run on every scan.

The test you should care about is whether they work, not whether you deployed them. Buying Cloudflare doesn't mean your origin is hidden. It means you're now responsible for verifying the hiding worked.

The Checklist

• MX records: not pointing at origin
• NS records: not self-hosted authoritative on the origin
• Outbound mail: routed via authenticated relay, not direct
• Outbound HTTP from origin: routed via egress proxy
• Webhooks, callbacks, error reporters: same egress
• Default vhost on raw IP: returns blank or decoy
• IPv6: either tunneled or absent
• Firewall: only CDN ranges allowed on every port, not just 443
• Historical DNS: scrubbed or replaced (you won't get it deleted, but you can move the IP)
• CT logs: audited for forgotten subdomains pointing at origin
• Shodan and Censys: search for your favicon hash and cert SHA, see what comes back

Ten minutes of audit before someone finds them for you.

DDactic helps organizations validate that their origin concealment actually conceals. Contact us at [email protected] for a free origin-concealment audit.