When a remote-access gateway goes down, the company does not lose a website. It loses its staff.
Consider 09:05 on a Monday. Several thousand people open their laptops at home and the client tries to connect. The public website sits behind a CDN and an always-on scrubbing service. The gateway sits on a fixed public address that is written into every client profile, published in DNS, and easy to find with a port scan.
If that gateway is flooded, nobody outside the office can reach email archives, the ERP, the build servers or the admin consoles. That includes the engineers who would normally respond to the flood.
What is DDoS testing for a VPN gateway?
DDoS testing for VPN and remote-access gateways is an authorised test of the gateway staff use to reach internal systems. It measures how many handshakes, logins and live tunnels the gateway can carry while it is being flooded, whether it fails over without dropping everyone, and whether people can still connect and do their work under load.
The flood mechanics themselves are not new. How a TLS handshake flood spends server CPU and how a TCP connection flood fills a state table each have their own page, and scoping an engagement on any target is in the complete guide to DDoS testing. This post is about what changes when the target is the way your own workforce gets in.
| Gateway surface | What a flood spends | What the test measures |
|---|---|---|
| IKE on UDP 500/4500 | half-open SA slots, then Diffie-Hellman work | half-open count, cookie onset, handshakes completed per second |
| TLS portal on 443 | handshake CPU, then login-page requests | new sessions per second, portal latency |
| Authentication chain | directory, RADIUS and MFA capacity | logins in flight, login success rate, lockouts |
| Tunnel table and address pool | licensed seats, inner IP addresses | concurrent tunnels, pool use, stale sessions |
| HA pair | the standby's capacity at the moment of failover | time until most users are reconnected |
Why is a VPN gateway harder to protect than a website?
Because it has to be reachable at a known address, it carries tunnels rather than HTTP, and most of the upstream protection a website relies on cannot stand in front of it.
It has to be found
A web origin can hide behind a proxy and keep its real address secret. A remote-access gateway cannot. Its address or hostname is in the client configuration on every laptop, and the client has to reach it directly.
So the gateway is already exposed before anyone looks for it. Hostnames like vpn. and remote. are the first ones an attacker tries, as the post on origin IP exposure shows.
A web CDN cannot carry the tunnel
An HTTP CDN caches and proxies web requests. An IPsec tunnel is ESP or UDP-encapsulated ESP, and a TLS VPN's data channel is often DTLS over UDP, so neither is something a web edge can terminate or cache.
What can sit in front of a gateway is network-layer protection: a scrubbing centre or provider-level filtering that cleans traffic before it reaches the link. Whether that is always-on or on-demand decides how long the gateway takes the flood alone, and that window is covered in detail in on-premise DDoS testing.
You know who your users are
This is the one advantage the gateway has over a public website. Its legitimate users are your employees and contractors, a known population in known countries.
That makes some controls usable here that would be reckless on a shop front: geo-blocking to the countries where staff actually work, device certificates checked before the login page appears, and pre-authentication filters that drop anything that is not a known client. Each one needs testing too, because a block list that also catches a travelling sales director at an airport is an outage for that person.
What does a handshake flood cost an IPsec gateway?
At first, very little: IKEv2 has a defence for the cheap spoofed version. The cost arrives when the flood comes from real addresses that can complete the first exchange.
IKE starts on UDP
IKEv2 opens with an IKE_SA_INIT exchange over UDP 500, moving to 4500 when NAT traversal is in play. Because it is UDP, the first packet can carry a forged source address, unlike a TLS handshake, which needs a completed TCP connection first. That makes the IPsec gateway one of the few remote-access surfaces where IP spoofing still matters.
Each IKE_SA_INIT the gateway answers normally creates a half-open IKE SA and a Diffie-Hellman key share. A flood of forged initiations fills the half-open table.
The cookie, and when it switches on
RFC 7296 gives the responder a way out. Once the number of half-open SAs crosses a threshold, the gateway replies with a COOKIE notification instead of doing any work, and only continues with initiators that send the cookie back. A forged source never receives the cookie, so the spoofed flood stops costing state.
Two things to test here. The threshold at which the cookie mechanism engages, which is configurable on many gateways and sometimes left at a value sized for a much bigger box. And whether real clients handle the extra round trip, since an old or unusual client that fails on a cookie is locked out the moment the defence turns on.
The expensive part comes after the cookie
A botnet with real addresses can return the cookie. Then the gateway does the real work: it computes the shared secret and derives keys, and it has to do that to decrypt the IKE_AUTH message that follows, even if that message is garbage.
RFC 8019 describes exactly this case and the countermeasures: limits on half-open SAs per source address, and client puzzles that make each initiator spend CPU before the responder does. Find out which of these your gateway supports, which are switched on, and what the handshake rate looks like when a few thousand real addresses each stay just under the per-source limit.
TLS-based gateways
A gateway that uses TLS for its tunnels pays the handshake cost described in the SSL flood definition. What it adds is a web login page in front of the tunnel.
That page is an ordinary HTTP endpoint, reachable before authentication, often with heavy scripts and redirects to an identity provider. It can be flooded like any other page, and the methods for that are in L7 DDoS testing. Where the portal sits behind a reverse proxy, that proxy's own connection and rate-limit arithmetic is in DDoS testing for NGINX and load balancers. The VPN-specific part is what each login on that page sets off behind it.
Why does the login become the bottleneck?
Because every login attempt, real or junk, is passed down an authentication chain that was sized for staff logging in over a morning, not for thousands of attempts a second.
Each attempt goes down the chain
A typical remote-access login runs the gateway, then RADIUS or LDAP to a directory, then often an MFA service, then back. The gateway is only the front of this chain. A flood of login attempts with random usernames becomes a flood of directory lookups and RADIUS requests.
The directory and the MFA service are usually shared with everything else in the company. Slowing them down hurts more than remote access.
RADIUS has a small number built into it
The RADIUS packet identifier is one octet, so a client using one source port can have at most 256 requests outstanding to a server at a time (RFC 2865). Implementations work around this with more source ports, and some do not.
That number turns backend latency into a hard ceiling. Requests in flight equal the login rate multiplied by how long each takes. At 40 attempts a second and a quarter of a second each, ten are in flight. Let the directory slow to six or seven seconds under the same load and the 256 are gone: new logins wait for a free identifier or time out, including every real employee's.
Account lockout is a denial of service you configured
Most directories lock an account after a number of failed passwords. That policy protects against guessing. Under a flood that uses real usernames, which are often easy to work out from email addresses, it locks your own staff out.
The test question is simple: what happens to a real user's account when an attacker sends 50 bad passwords for it in a minute? If the answer is "locked for 30 minutes", the attacker does not need to beat the gateway at all.
MFA prompts are another quota
If the gateway asks for MFA only after a correct password, junk logins never reach the MFA service. If it asks on every attempt, or uses an MFA step that runs before the password check, each junk login can send a prompt to a real user's phone and use up the MFA service's own rate limits.
Know which order your flow uses and whether the MFA provider throttles per account or per tenant. Throttling per tenant means one attacked user can stop everyone from completing a login.
How many people can the gateway hold at once?
Fewer than its throughput figure suggests. The limits that bind are counts: tunnels, licensed seats, inner addresses and session state.
Seats, tunnels and the address pool
Every connected user takes a tunnel, often a licensed seat, and an inner IP address from a pool. Each has a fixed number, and the pool is usually sized close to headcount with a margin.
An attacker who can complete a login, with a stolen password or a contractor account, can take seats and addresses without sending much traffic at all. Measure how many concurrent tunnels one identity can hold, and whether the gateway limits that per user.
Dead sessions keep their seat
When a client disappears without disconnecting, the gateway keeps its tunnel and address until a liveness check (dead peer detection, in IPsec terms) or an idle timer gives up. With long timers, a mass disconnect leaves hundreds of dead sessions holding seats while the same users try to reconnect.
So the real capacity during an incident is the pool minus the stale sessions. The test should drop a block of clients abruptly and watch how long their seats stay taken.
Full tunnel carries everyone's internet too
In a full-tunnel design, every remote user's video calls, updates and web browsing come back through the gateway. A link that looks half-empty at 03:00 can be most of the way full at 10:00 from legitimate traffic alone.
The flood needs much less headroom to finish the job on a busy weekday morning than on the quiet night when a test is usually scheduled. Test during working hours, with real usage on the link, or say plainly in the report that you did not.
What happens when the gateway fails over?
Often a second, self-inflicted surge. Unless the pair shares tunnel state, failover disconnects every user, and they all reconnect to the standby at once.
Without synced state, everyone starts again
Some HA designs synchronise IPsec SAs to the standby so tunnels survive a failover. Many do not, or synchronise IPsec but not TLS VPN sessions. Without that state, every client has to repeat the full handshake and the full login.
The standby takes the storm
The standby now receives every user's IKE_SA_INIT or TLS handshake within a few seconds, on top of whatever flood caused the failover. Behind it, the directory and MFA service receive a login for every user at once, and with MFA on every connection, every remote employee gets a prompt in the same minute.
Whether clients spread their retries is the same jitter question covered for mobile fleets and WebSocket reconnects; here the clients come from one or two vendors, so you can read their retry behaviour in the documentation and check it in the test.
Clients often pick the same backup
Clients with a list of gateways commonly try them in the listed order. If every profile names the same gateway second, the whole workforce lands on that one, while a third gateway in another region stays idle.
Check how your clients choose. Spreading the order across profiles, or using a load-balanced name, turns one overloaded backup into several partly busy ones.
What does "up" mean when staff cannot connect?
It means a person can log in, get a tunnel and use the internal application they need. A health check that sees port 443 answering measures none of that.
Measure the user's path, end to end
Run synthetic clients from several networks through the whole flow while the test runs: handshake, login with a test identity, tunnel up, then a real request to an internal application. Record four things per second:
- time to tunnel: from the first packet to a usable tunnel
- login success rate: the share of real-credential logins that complete
- goodput per tunnel: useful data moved, not raw packets
- internal reachability: whether the application behind the tunnel answers
A gateway that accepts handshakes but cannot complete logins is down for users. So is one that completes logins but cannot reach the application because the next hop has failed.
The next hop is often somewhere else
Behind the gateway, users reach applications through an internal firewall, a data-centre link or a cloud interconnect. Those have their own state and capacity limits. When the applications live partly in a cloud, the private link in the middle is its own failure point, covered in hybrid-cloud DDoS testing.
Which part breaks first is the layer of first failure, and for remote access it is often a counter inside the gateway, or the directory behind it, while the network interface still has room to spare.
How do you test the gateway your responders need?
Carefully, and with a way in that does not go through it. The people running the test, and the people who would stop it, must not depend on the target.
Keep a way in that bypasses the gateway
Before the test, confirm that the test lead, the network team and whoever can stop the traffic have access that does not use the gateway under test: an on-site console, a separate management gateway, or a cloud-hosted admin path with its own address.
Write it into the test plan and try it before the flood starts. A kill switch that needs the VPN is not a kill switch during a VPN test.
Use test identities, never real usernames
Create test accounts for the login floods and for the synthetic clients. Never send failed logins for real employees, since lockout is one of the findings and you do not want to find it on the finance director's account.
Check with the identity team that the test accounts do not trigger alerts that page someone or block an IP range that real staff share.
Pick the window with the business
A test at 03:00 is safe and unrepresentative. A test at 10:00 on a Tuesday is representative and risky. A common compromise is to test the standby on its own first, then failover in a quiet period, then a short, ceilinged run in working hours with the business told in advance.
The scenario is also a good one to rehearse on paper first: who decides to fail over, who tells staff, and how they work in the meantime. That side is in the post on the DDoS tabletop exercise.
A VPN gateway DDoS test checklist
- List every way staff reach internal systems, including second gateways and the clientless portal.
- Confirm the scrubbing or filtering in front of the gateway, and whether it is always-on or on-demand.
- Find the half-open threshold at which the IKEv2 cookie engages, and check old clients handle it.
- Check per-source limits and client puzzles for IKE, and the TLS handshake rate for the portal.
- Map the authentication chain (RADIUS, directory, MFA) and measure logins in flight against its limits.
- Test lockout and MFA behaviour with test accounts only.
- Measure seats, tunnels and the address pool, and how long dead sessions keep them.
- Run a failover under load and time how long until most users have a working tunnel.
- Check which backup gateway each client profile tries first.
- Confirm an out-of-band path for the responders before the first packet is sent.
FAQ
Can a VPN gateway sit behind a CDN?
Not in the usual sense. A web CDN proxies HTTP and cannot carry an IPsec tunnel or a DTLS data channel. Network-layer scrubbing in front of the gateway's address is the realistic upstream protection, plus whatever filtering the gateway can do before authentication.
Does IKEv2 protect itself against DDoS?
Partly. The cookie mechanism in RFC 7296 stops spoofed IKE_SA_INIT floods from filling the half-open table, and RFC 8019 adds per-source limits and client puzzles. None of these stops a large set of real addresses that complete the cookie exchange, so the handshake rate still needs testing.
Why test the authentication backend in a VPN DDoS test?
Because every login attempt reaches it. A flood of logins can saturate the directory or MFA service, lock real accounts, and stop staff connecting even when the gateway itself has spare capacity.
Is split tunnelling safer during a DDoS?
It reduces the legitimate load on the gateway, so the same link has more headroom. It is a security and policy decision as much as a capacity one, so treat it as an option to decide in advance, not a switch to flip mid-incident.
How often should a VPN gateway be tested?
After any change to the gateway, its HA pair, the client profiles or the authentication chain, and at least before periods when most staff work remotely. Client updates in particular can change retry and failover behaviour without anyone touching the gateway.
The door your responders use
Most DDoS planning treats the attack as something that happens to the public side of the company while the staff respond from the inside. Remote work moved the staff outside, and the gateway is now the only way back in.
That changes what the gateway is for. During an incident it carries the people who are trying to fix the incident. A flood that takes it down slows the response to every other outage, including the one the flood was meant to cover.
So the useful result of a gateway test is how many of your people could get in and keep working while it was under attack, and how long the rest waited.