Hide your origin IP behind a WAF (and allowlist edge IPs only)

A quiet edge means nothing if attackers still punch the load balancer. Campus and agency operators put a managed web application firewall (WAF) in front of admissions, permitting, FOIA, and departmental CMS sites to stop junk before it burns the origin. That only works when public DNS points at the edge, and the origin accepts traffic from the edge's IP ranges only. If the origin IP stays reachable — old A record, leaked host, vendor portal, forgotten subdomain — attackers skip the WAF. That is origin IP bypass DDoS: a calm dashboard while load-balancer CPU hits 99%. This guide teaches the durable operator pattern. For the first-person incident (~90M req/h; origin still burning after the edge cooled), see /blog/request-flood-origin-bypass.

What "WAF bypass origin IP" actually means

WAF bypass via origin IP is not a clever exploit against your rule pack. It is a routing failure:

1. The public hostname resolves to the edge (or appears to).

2. Attackers already know — or rediscover — the origin / load-balancer address.

3. They send the flood (or exploit probes) straight to that IP, with your Host header if needed.

4. Edge counters stay quiet. Origin metrics scream.

You did not "fail open" on a signature. You left a second front door.

Common leaks: historical DNS; mail, staging, or monitoring hostnames on the same VIP; hosting panels and certificate metadata; departmental microsites never moved behind the edge; "temporary" direct access left open after a cutover.

Hide origin IP behind WAF means two controls: DNS that only advertises the edge, plus network policy that allowlists edge IPs only on the origin listeners.

Request flood and origin bypass

Why campuses and agencies get hit this way

One web team, many properties. Central IT cannot inventory every departmental CMS, staging host, and vendor portal. One leftover A record is enough.

Shared IdP and portals. The same VIP often sits behind admissions, SSO, permitting, and a forgotten microsite. Attackers only need one hostname that still publishes the origin.

Change freezes. "Temporary" direct access left open after a cutover survives the freeze — and is still there when the flood starts.

Wrong console. Watching only the WAF means a quiet edge looks like a win while load-balancer CPU hits 99%. Origin metrics are the other half of the picture.

Higher education Government

Operator checklist: hide origin, then allowlist edge only

Do the DNS cleanup and the origin allowlist. Either one alone is incomplete. The five steps below are the durable operator pattern — not an IP swap after the fact.

1. Make DNS advertise the edge only

Point every public hostname at the edge. Apex, www, admissions, permitting, FOIA, departmental CMS — if users type it, it must resolve to the edge, not the load balancer.

Remove leftover A and AAAA records that still publish the origin. A dual-stack leak is still a leak. Do not leave a "temporary" A record after cutover.

If a vendor or bookmark still uses the raw origin IP, treat that as a second front door and retire it.

2. Discover what still points at the origin

Walk historical DNS, old zone files, and anything that ever published the VIP. Mail, staging, and monitoring hostnames on the same address are classic leaks.

Check hosting panels and certificate metadata (SANs, CT logs). A departmental microsite that never moved behind the edge will still advertise the origin.

Vendor portals and forgotten subdomains count. If any name still resolves to the origin, attackers will find it — then hit that IP directly, often with your Host header.

3. Allowlist edge IPs only on the origin (durable control; IP swap is temporary)

On the origin listener, permit the edge provider's published address ranges and deny the rest of the public internet for application ports. That is the durable control. An IP swap after a leak is obfuscation, not a fix — attackers rediscover the new address.

Keep separate, controlled access for admins and vendors. Break-glass over VPN (or a jump host), not a public hole on 443. Do not punch a permanent exception "just for the vendor."

Refresh the ranges when the provider updates them. DNS cleanup without the allowlist is incomplete; the allowlist without DNS cleanup leaves accidental leaks.

4. Watch origin and edge together

Edge counters can stay quiet while origin CPU and TLS errors spike. Watch load-balancer CPU, origin 5xx, and TLS handshake failures alongside the WAF dashboard.

If the edge is calm and the origin is not, assume origin IP bypass until you prove otherwise. That split is the tell — a calm console is not a healthy site.

5. Keep the WAF operator model intact (count → promote; Copilot does not auto-block)

Hiding the origin does not change how you run the WAF. Rules start in count. After 24 hours, your dashboard shows what's safe to block — one click.

Promote Copilot explains Promote, Hold, or Needs allowlist from count-window evidence. It does not auto-block. Promoting to block remains a human action.

Origin allowlisting is a network control you (or your host) apply separately — it is not an AI deny.

What is WAF count mode?What's safe to block on a WAF?

Edge alone vs edge + origin lock-down

An edge without an origin allowlist still leaves a second front door. Lock the origin so only edge IPs can reach the listeners.

Edge alone vs edge + origin lock-down
Control	Edge alone	Edge + origin lock-down
Public DNS	Points at the edge	Points at the edge
Origin listeners	Still accept the public internet	Allowlist edge IPs only
Leaked A record or VIP	Attackers skip the WAF	Flood never reaches the origin
Dashboard vs origin	Edge can look fine while origin burns	Edge and origin stay aligned
IP swap after a leak	Temporary obfuscation	Optional extra; allowlist is the durable fix

How ProtectMyWebsite fits

The WAF that tells you what's safe to block.

Rules start in count. After 24 hours, your dashboard shows what's safe to block — one click.

Promote Copilot explains what's safe to promote — you still click once. It does not auto-block.

Self-serve is $150/site/mo with a 14-day trial. Campus Estate is quote on request — Talk to sales team. We do not publish Estate list prices.

We run the managed edge. You (or your host) still lock the origin so it accepts traffic from the edge's IP ranges only — so origin IP bypass DDoS is not a second outage behind a quiet console.

Talk to sales team Virtual patching websites with a managed WAF

FAQ

What is origin IP bypass DDoS? A flood (or probe storm) aimed at your origin or load-balancer IP instead of the public hostname's edge address. The WAF never sees the traffic, so edge dashboards look fine while origin CPU and TLS errors spike.

How do attackers find a WAF bypass origin IP? They reuse historical DNS, certificate or hosting metadata, leaked staging hostnames, vendor panels, or any property that still publishes the same VIP — then hit that IP directly, often with your Host header.

How do I hide origin IP behind a WAF? Point public DNS only at the edge, remove leftover A/AAAA records and direct-IP bookmarks, then lock the origin so it accepts traffic from the edge's IP ranges only. DNS cleanup without the allowlist is incomplete; the allowlist without DNS cleanup leaves accidental leaks.

What does "allowlist edge IPs only" mean in practice? On the origin listener, permit the edge provider's published address ranges and deny the rest of the public internet for application ports. Keep separate, controlled access for admins and vendors. Refresh ranges when the provider updates them.

Does Promote Copilot auto-block during a flood? No. Copilot explains Promote, Hold, or Needs allowlist from count-window evidence. Promoting to block remains a human action. Origin allowlisting is a network control you (or your host) apply separately — it is not an AI deny.

Start here

ProtectMyWebsite is the managed WAF for campus and agency operators who need the edge and the origin lock-down — so origin IP bypass DDoS is not a second outage behind a quiet console.