VPN Concentrator DDoS Protection: Stop Attacks Without Dropping Tunnels

The VPN Concentrator DDoS Problem

VPN concentrators are among the most difficult infrastructure components to protect from DDoS attacks. The core challenge is that VPN traffic is encrypted. A DDoS scrubbing center cannot inspect the contents of a WireGuard, OpenVPN, or IPsec packet to determine whether it is legitimate tunnel traffic or attack traffic. From the outside, all encrypted UDP packets look identical.

This creates a dilemma. Traditional DDoS mitigation services work by routing your traffic through their scrubbing infrastructure, inspecting each packet, and forwarding only legitimate traffic to your server. But with encrypted VPN traffic, the scrubbing center has no way to distinguish a valid WireGuard handshake from a flood of garbage UDP packets targeting port 51820. If they filter aggressively, they drop legitimate tunnel traffic and your users lose their VPN connections. If they filter conservatively, the attack traffic passes through and overwhelms your concentrator.

The result is that many VPN providers simply accept DDoS as an unsolvable problem. When attacks hit, tunnels drop, users reconnect (creating additional load), and the service degrades until the attack stops. This is not acceptable for commercial VPN services where customer retention depends on reliability.

UDP Amplification on VPN Ports

VPN protocols overwhelmingly use UDP. WireGuard uses UDP exclusively (default port 51820). OpenVPN commonly uses UDP port 1194 (though TCP is an option). IPsec uses UDP ports 500 (IKE) and 4500 (NAT-T). This UDP dependency makes VPN concentrators particularly vulnerable to amplification attacks.

WireGuard (Port 51820)

WireGuard's handshake protocol is designed to be resistant to amplification because the server does not send a response larger than the client's initiation packet. However, attackers do not need to abuse the WireGuard protocol itself. They can launch UDP amplification attacks using other protocols (DNS, NTP, SSDP, memcached) and direct the amplified traffic to port 51820 on your concentrator. The concentrator receives a flood of non-WireGuard UDP packets on the WireGuard port. It must process each packet far enough to determine it is not a valid WireGuard handshake before discarding it.

At high volumes, this processing overhead consumes CPU and memory that should be handling legitimate tunnel traffic. WireGuard's kernel-level implementation is efficient, but it is not immune to resource exhaustion when millions of garbage packets per second arrive on its listening port.

OpenVPN (Port 1194)

OpenVPN's handshake is more complex than WireGuard's, involving TLS negotiation and certificate exchange. This makes OpenVPN concentrators more vulnerable to handshake exhaustion attacks. An attacker sending a high rate of partial TLS handshakes forces the server to allocate state for each handshake attempt, consuming memory and CPU. The attack does not need to complete any handshakes. Just initiating them is enough to exhaust resources.

OpenVPN's HMAC firewall feature (tls-auth or tls-crypt) mitigates this by requiring a pre-shared key before the TLS handshake begins. But this only works against attackers who do not have the pre-shared key. If the key is distributed broadly (as it is for many commercial VPN services), the protection is limited.

IPsec (Ports 500/4500)

IPsec uses IKE (Internet Key Exchange) on port 500 for key negotiation and port 4500 for NAT traversal. IKE handshakes involve computationally expensive Diffie-Hellman key exchanges. An attacker flooding port 500 with IKE_SA_INIT requests can exhaust the concentrator's CPU by forcing it to compute Diffie-Hellman shared secrets for each request.

Modern IKEv2 implementations include cookie-based DoS protection (RFC 7296) that requires the client to respond to a cookie before the server commits resources to the handshake. This helps, but it adds latency to legitimate connections during an attack and does not prevent bandwidth saturation on the network link.

Reconnection Storm Amplification

Reconnection storms are a secondary effect of VPN concentrator DDoS that can amplify the attack's impact far beyond the original bandwidth. Here is how the cascade works:

The attacker launches a DDoS attack against your VPN concentrator. The concentrator becomes overloaded and starts dropping packets.
Active VPN tunnels detect packet loss and begin their keepalive/dead-peer-detection timers. After the timeout expires (typically 15 to 60 seconds), clients conclude the tunnel is dead.
Thousands of clients simultaneously attempt to reconnect. Each reconnection requires a new handshake, which is the most CPU-intensive operation the concentrator performs.
The concentrator, already overloaded from the DDoS attack, now faces a flood of legitimate reconnection handshakes on top of the attack traffic. This pushes it further into overload.
Some reconnection attempts fail due to the overload, causing those clients to retry after a backoff period. But with thousands of clients retrying on slightly different timers, the reconnection load stays elevated for minutes or hours after the original attack.

The result is that a 60-second DDoS burst can cause 10 to 15 minutes of degraded service as the reconnection storm plays out. The original attack may have stopped, but the secondary effect continues because of the synchronized reconnection behavior of thousands of VPN clients.

# Timeline of a VPN DDoS with reconnection storm
T+0:00   Attack begins. 4 Gbps UDP flood to port 51820.
T+0:05   Concentrator CPU at 100%. Packet loss begins.
T+0:20   First clients detect dead tunnels. Keepalive timeouts fire.
T+0:30   Reconnection wave begins. 12,000 clients attempt handshakes.
T+0:45   Attack stops. But 8,400 clients are still reconnecting.
T+1:00   Handshake backlog clears for 60% of clients.
T+2:30   Retry wave from failed reconnections hits.
T+4:00   95% of clients reconnected. Remaining 5% stuck in retry loop.
T+8:00   Service fully recovered. 3,200 support tickets filed.

Preventing reconnection storms requires preventing the initial tunnel disruption. If the DDoS attack is mitigated before it causes packet loss on the concentrator, tunnels stay up and the reconnection cascade never starts.

Why Traditional DDoS Mitigation Breaks Encrypted Tunnels

Let us be specific about why conventional DDoS mitigation fails for VPN concentrators:

Scrubbing Centers Cannot Inspect Encrypted Traffic

Cloud-based DDoS mitigation services operate by proxying your traffic through their network and filtering out attack packets. For HTTP traffic, they can inspect headers, validate requests, and challenge suspicious clients. For encrypted VPN traffic, they see opaque UDP payloads. They cannot distinguish between a WireGuard data packet, a WireGuard handshake initiation, and a random UDP packet from an attacker.

BGP Rerouting Breaks Tunnel State

Some DDoS mitigation services use BGP to reroute your traffic during an attack. This changes the network path between your clients and your concentrator. For VPN protocols that are sensitive to path changes (IPsec with strict anti-replay windows, some OpenVPN configurations), this path change can break active tunnels. Even protocols that handle path changes well (WireGuard's roaming support) may experience brief disruptions during the BGP convergence period.

Rate Limiting Punishes Legitimate Users

Applying a blanket rate limit to UDP traffic on port 51820 affects all users equally. During an attack, you want to drop attacker traffic and preserve client traffic. But the rate limiter does not know which packets are which. It drops packets uniformly, causing packet loss for legitimate tunnels and triggering the reconnection storm described above.

Port-Aware Baseline Detection

Flowtriq solves the VPN DDoS problem by building per-port traffic baselines that understand the normal behavior of each VPN protocol port on each concentrator. The system learns the expected traffic volume, packet rate, source IP diversity, and traffic patterns for each port independently.

For a WireGuard concentrator serving 10,000 concurrent users, Flowtriq learns that port 51820 normally receives approximately 2 Gbps of UDP traffic from around 10,000 unique source IPs, with a typical packet size distribution centered around the WireGuard MTU. When an amplification attack arrives, the traffic pattern changes dramatically:

Packet size distribution shifts: Legitimate WireGuard packets cluster around specific sizes (handshake initiation is 148 bytes, handshake response is 92 bytes, data packets are near the configured MTU). Amplified DNS or NTP responses have different, distinctive size distributions.
Source IP diversity explodes: An amplification attack reflecting off thousands of open resolvers introduces source IPs that have never appeared in the baseline. Flowtriq detects this sudden increase in new source IPs.
Traffic asymmetry changes: Normal VPN traffic has a relatively balanced inbound/outbound ratio (clients send and receive data). An amplification attack creates a massive inbound spike with no corresponding outbound increase.

These signals allow Flowtriq to detect VPN-targeted DDoS attacks within seconds, even when the attack traffic arrives on the same port as legitimate VPN traffic.

Surgical FlowSpec Rules That Preserve Tunnel Traffic

When Flowtriq detects an attack on a VPN concentrator, it generates FlowSpec rules that are specifically designed to preserve encrypted tunnel traffic. The key is source-based filtering: blocking traffic from identified attack sources while allowing traffic from known client IP ranges to pass through unimpeded.

# FlowSpec rules for WireGuard concentrator under amplification attack
{
  "rules": [
    {
      "match": {
        "dst_ip": "198.51.100.20/32",
        "dst_port": 51820,
        "protocol": "UDP",
        "packet_length": ">1200"
      },
      "action": "rate-limit 100Mbps",
      "comment": "Rate-limit large UDP to WG port (amplified responses are typically >1200 bytes)"
    },
    {
      "match": {
        "dst_ip": "198.51.100.20/32",
        "dst_port": 51820,
        "protocol": "UDP",
        "src_prefix": "203.0.113.0/24"
      },
      "action": "discard",
      "comment": "Block top amplification reflector subnet"
    },
    {
      "match": {
        "dst_ip": "198.51.100.20/32",
        "dst_port": 51820,
        "protocol": "UDP",
        "src_prefix": "192.0.2.0/24"
      },
      "action": "discard",
      "comment": "Block second reflector subnet"
    }
  ]
}

Notice the first rule: instead of blocking all traffic, it rate-limits UDP packets larger than 1200 bytes. WireGuard handshake packets are 148 and 92 bytes. Data packets are typically at or near the configured MTU (usually 1420 bytes for WireGuard). Amplified DNS responses are commonly 3000 to 4000 bytes. By rate-limiting only large packets, the rule preferentially drops amplified traffic while allowing most legitimate WireGuard traffic to pass.

The second and third rules block traffic from the specific subnets hosting the amplification reflectors. This is targeted filtering that affects only attack sources, not legitimate VPN clients.

Multi-PoP Monitoring

Commercial VPN providers operate concentrators across multiple points of presence (PoPs) worldwide. An attacker may target a single PoP to disrupt service in a specific region, or they may attack multiple PoPs simultaneously to cause a widespread outage.

Flowtriq's multi-PoP monitoring provides a global view of your VPN infrastructure:

Per-PoP dashboards: Each PoP has its own traffic visualization, baseline status, and alert history. Your regional NOC teams can monitor their own PoPs while the global NOC sees everything.
Cross-PoP correlation: When attacks target multiple PoPs simultaneously, Flowtriq correlates the events and identifies shared attack characteristics (common source networks, similar traffic profiles, synchronized timing). This helps determine whether the attack is a coordinated campaign or coincidental.
Failover monitoring: When a PoP goes down, clients fail over to the next closest PoP. Flowtriq detects the resulting traffic increase on the failover PoP and adjusts its baselines temporarily to avoid false positive alerts from the legitimate traffic surge.
Capacity planning: Historical traffic data per PoP helps you plan concentrator capacity so that each PoP can absorb its own traffic plus failover traffic from adjacent PoPs during an attack.

User-Impact Correlation

For commercial VPN providers, the most important metric during a DDoS attack is not bits-per-second or packets-per-second. It is the number of users affected. A 10 Gbps attack on an underutilized concentrator may affect 200 users. A 500 Mbps attack on a fully loaded concentrator may affect 15,000 users. Your business cares about the second number, not the first.

Flowtriq correlates attack metrics with user-impact estimates based on the concentrator's pre-attack active session count. The alert includes:

Active tunnels at attack start: How many users were connected when the attack began
Estimated affected tunnels: Based on the severity of the attack relative to the concentrator's capacity, how many tunnels are likely experiencing degradation
Reconnection rate: How many new handshake attempts are occurring, indicating users whose tunnels have dropped
Time to full recovery: Based on current mitigation effectiveness and reconnection rate, estimated time until all users are reconnected

This user-impact framing helps your NOC and executive teams make informed decisions about escalation, customer communication, and incident severity classification.

Protocol-Specific Defense Configuration

Each VPN protocol has specific characteristics that inform optimal Flowtriq configuration:

WireGuard Configuration

# Flowtriq monitoring profile for WireGuard
port_monitor: UDP/51820
baseline_metrics:
  - pps (packets per second)
  - bps (bits per second)
  - unique_sources (connected clients)
  - packet_size_distribution
alert_thresholds:
  pps_deviation: 5x
  source_diversity_spike: 3x
  packet_size_anomaly: enabled
auto_mitigation:
  type: flowspec
  strategy: source_block + large_packet_rate_limit
  preserve: known_client_subnets

OpenVPN Configuration

# Flowtriq monitoring profile for OpenVPN
port_monitor: UDP/1194, TCP/443 (if using TCP fallback)
baseline_metrics:
  - pps, bps
  - new_connections_per_sec (handshake rate)
  - unique_sources
alert_thresholds:
  pps_deviation: 5x
  new_connection_spike: 4x (catches handshake exhaustion)
  source_diversity_spike: 3x
auto_mitigation:
  type: flowspec
  strategy: source_block + new_connection_rate_limit
  preserve: known_client_subnets + tls_auth_validated

IPsec Configuration

# Flowtriq monitoring profile for IPsec
port_monitor: UDP/500, UDP/4500
baseline_metrics:
  - pps, bps per port
  - ike_init_rate (new IKE negotiations)
  - unique_sources
alert_thresholds:
  pps_deviation: 5x (per port)
  ike_init_spike: 3x
  source_diversity_spike: 3x
auto_mitigation:
  type: flowspec
  strategy: source_block + ike_init_rate_limit
  preserve: known_peer_ips + established_sa_sources

Multi-protocol concentrators: If your concentrators run multiple VPN protocols (common for providers offering WireGuard, OpenVPN, and IKEv2 options), Flowtriq builds separate baselines for each port/protocol combination. An attack targeting port 51820 triggers mitigation only for that port. Traffic on ports 1194 and 4500 continues unaffected.

Flowtriq protects VPN concentrators with port-aware baseline detection, surgical FlowSpec rules that preserve encrypted tunnel traffic, and multi-PoP monitoring with user-impact correlation. Plans start at $9.99/node/month. Start your free trial and protect your VPN infrastructure from the DDoS attacks that traditional scrubbing centers cannot handle.

Back to Blog

VPN Concentrator DDoS Protection:Stop Attacks Without Dropping Tunnels