IPv6 VPN Brute Force Attacks: The Emerging Blind Spot in Network Security

Bottom line up front: IPv6 brute force attacks against VPN portals are growing as global IPv6 adoption climbs past 40% of all internet traffic. The problem is that the vast majority of IP blocklists, threat feeds, and firewall rules were built for IPv4 and have never been updated to cover IPv6. This creates a real, exploitable gap—attackers who source their traffic from IPv6 addresses often bypass every layer of IP-based defense. Here is what is happening, why your current protections probably miss it, and how to close the gap.

When security teams think about VPN brute force attacks, they picture botnets hammering a GlobalProtect or FortiGate portal with credential-guessing attempts from thousands of IPv4 addresses. They configure blocklists, set up rate limiting, and import threat feeds—all built around 32-bit IPv4 addresses. That model was sufficient for a long time. It is no longer.

The internet is in the middle of a fundamental addressing transition. IPv6 now carries approximately 40% of global traffic, with some countries and networks well above 50%. Cloud providers assign IPv6 addresses by default to new virtual machines. Mobile carriers route the majority of their traffic over IPv6. And the botnets that power brute force campaigns are running on the same infrastructure—which means a growing share of attack traffic arrives over IPv6.

Most organizations are not prepared for this. Their threat intelligence is IPv4-centric, their firewall rules only reference IPv4 address objects, and their log analysis pipelines may not even parse IPv6 source addresses correctly. This article explains the threat, the coverage gap, and exactly what to do about it.

What Are IPv6 VPN Brute Force Attacks?

An IPv6 VPN brute force attack works the same way as its IPv4 counterpart: automated tools attempt to authenticate against a VPN portal by rapidly trying username and password combinations. The difference is the source address. Instead of originating from an IPv4 address like 185.224.128.71, the attack traffic comes from an IPv6 address like 2001:db8:a1b2::1f3e.

IPv6’s address space is incomprehensibly large—2¹²⁸ possible addresses, compared to IPv4’s roughly 4.3 billion. This vastness changes the dynamics of network scanning. Traditional IPv4 brute force campaigns often start with mass scanning to discover VPN portals, then pivot to credential guessing. Scanning the full IPv6 address space is computationally infeasible, but that does not mean IPv6 targets are safe.

Attackers find IPv6-enabled VPN portals through several methods:

• DNS enumeration: VPN portals have DNS records. If the record includes an AAAA entry (the IPv6 equivalent of an A record), the attacker knows the portal is reachable over IPv6 and can target it directly.
• Dual-stack reconnaissance: Attackers who discover a VPN portal via IPv4 scanning can check whether it also responds on IPv6. If it does, they have a second attack vector that may bypass IPv4-only defenses.
• IPv6-enabled botnets: Modern botnets run on cloud VMs, compromised IoT devices, and mobile devices—many of which have IPv6 connectivity by default. The botnet controller does not need to seek out IPv6 specifically; the bots simply use whichever protocol is available.
• IPv6 tunneling protocols: Techniques like 6to4 and Teredo encapsulate IPv6 traffic within IPv4 packets, allowing attackers on IPv4-only networks to send traffic that arrives at the target as IPv6. This can bypass firewalls that only inspect at the IPv4 layer.

The end result is the same: your VPN portal receives a barrage of login attempts from addresses your blocklist has never seen and your firewall rules do not match.

Why IPv6 Is a Blind Spot

The IPv6 coverage gap is not theoretical. It is a measurable, systemic failure across most of the threat intelligence ecosystem. Here is why:

Blocklists Are IPv4-Centric

The most widely used open-source and commercial blocklists were built during the IPv4 era and have not meaningfully expanded to cover IPv6. FireHOL’s aggregated lists, the ipsum reputation list, and Spamhaus DROP are all predominantly or entirely IPv4. Their collection infrastructure—honeypots, scanning engines, log aggregation—was designed around 32-bit addresses. Adding IPv6 coverage requires new honeypots on dual-stack networks, new parsing logic for 128-bit addresses, and new aggregation pipelines. Most providers have not made that investment.

Firewall Rules Often Skip IPv6

Even when a firewall supports IPv6 natively, security policies often only reference IPv4 address objects. This happens because the original ruleset was built before IPv6 was enabled on the network, and nobody went back to create parallel IPv6 rules. On Palo Alto Networks firewalls, address objects and External Dynamic Lists may only contain IPv4 entries. On FortiGate, firewall policies may reference address objects but not address6 objects. The result is a firewall that diligently blocks known IPv4 attackers while allowing the same attackers through on IPv6.

Log Analysis Misses IPv6

Many SIEM rules, log parsing regex patterns, and alerting dashboards were written to match IPv4 address formats. IPv6 addresses look fundamentally different—they use colons instead of dots, can be abbreviated with ::, and come in multiple representation formats. A log parser or SIEM correlation rule that uses a regex like \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3} to extract source IPs will silently skip every IPv6 address in the log. The attack happens, the logs record it, but the alerting pipeline never sees it.

Monitoring Gaps

Many network administrators have not explicitly enabled IPv6 monitoring on their VPN infrastructure. They may not have IPv6 traffic dashboards, IPv6-specific rate limiting, or IPv6 geolocation lookups. Some are not even aware their VPN portal is reachable over IPv6, because the dual-stack configuration was enabled by default and never reviewed.

How Attackers Exploit the IPv6 Gap

Sophisticated attackers are aware that IPv6 represents a blind spot, and they exploit it deliberately. Here are the most common techniques:

Dual-Stack Fallover

This is the simplest and most effective technique. The attacker (or their botnet) targets a VPN portal over IPv4 first. After a certain number of failed attempts, the IPv4 source address gets blocked by Fail2Ban, a rate limiter, or an IP blocklist. The attacker then switches to IPv6, hitting the same portal from a completely different address family. Because the blocklist, rate limiter, and firewall rules only cover IPv4, the attack continues unimpeded on IPv6. From the VPN portal’s perspective, a brand new source address appeared—one with no prior history.

IPv6 Tunneling

Protocols like 6to4, Teredo, and ISATAP encapsulate IPv6 packets inside IPv4. An attacker on an IPv4-only network can use these tunneling mechanisms to generate traffic that arrives at the target with an IPv6 source address. This is particularly effective against firewalls that only perform deep packet inspection on native IPv4 traffic and treat encapsulated IPv6 as pass-through.

Cloud Provider IPv6 Defaults

Major cloud providers—AWS, Azure, GCP, and smaller VPS providers—now assign IPv6 addresses to virtual machines by default or with minimal configuration. An attacker spinning up throwaway VMs for a brute force campaign automatically gets IPv6 connectivity. The botnet infrastructure is IPv6-capable without any extra effort from the attacker. Since cloud provider IPv6 ranges are vast and change frequently, they are poorly represented in most blocklists.

IPv6 Address Rotation

IPv6’s enormous address space makes per-address blocking less effective. A single /64 subnet allocation (the standard size for a single network segment) contains 2⁶⁴ addresses—more than the entire IPv4 address space. An attacker with access to even a small IPv6 allocation can rotate through millions of source addresses, making it impractical to block individual IPs. Effective IPv6 blocking requires CIDR-based rules that block entire prefixes, not individual addresses.

Detecting IPv6 Brute Force in Your Logs

The first step toward protection is detection. Here is what to look for on common firewall platforms:

Palo Alto Networks (PAN-OS)

On PAN-OS, authentication logs for GlobalProtect will show IPv6 source addresses in the same log fields as IPv4. Filter the traffic log for ( addr.src in ::/0 ) to see all IPv6-sourced traffic, or filter authentication logs for failed GlobalProtect logins with IPv6 source addresses. The key fields are Source Address, Source Zone, and Rule—verify that your deny rules match IPv6 traffic.

FortiGate

FortiGate logs IPv6 authentication attempts in the same event log as IPv4. Search for srcip6= in your log entries, or filter for authentication failures where the source IP contains colons. Check that your SSL-VPN policies have corresponding srcaddr6 address groups with threat feed entries.

Generic Syslog

For VPN concentrators that log to syslog, search for authentication failure patterns with IPv6 addresses. IPv6 addresses in logs are distinctive—they contain colons and are significantly longer than IPv4 addresses.

How to Protect Against IPv6 VPN Brute Force

Closing the IPv6 gap requires action across several layers. None of these steps are difficult, but they require deliberate effort because IPv6 protection is rarely configured by default.

1. Enable IPv6 in Your Firewall Rules

Audit your firewall policies and ensure every IPv4 deny rule has a corresponding IPv6 equivalent. On Palo Alto firewalls, create address objects and security policies that reference IPv6 addresses and ranges. On FortiGate, create address6 objects and reference them in your firewall policies. This is the most commonly missed step—many firewalls have comprehensive IPv4 policies and no IPv6 policies at all.

2. Use Blocklists That Cover IPv6

Not all blocklists are created equal. When evaluating a threat feed for VPN brute force protection, explicitly verify that it includes IPv6 entries. If your current blocklist is IPv4-only, you need to supplement it with a feed that tracks IPv6 attackers. ThreatListPro monitors attack traffic across both address families and includes confirmed IPv6 brute force sources in its curated feed.

3. Monitor Both Address Families in Your SIEM

Update your SIEM correlation rules and dashboards to handle IPv6 addresses. This means updating regex patterns to match both IPv4 and IPv6 formats, adding IPv6 geolocation lookups, and creating alerts that trigger on repeated authentication failures regardless of address family. Many SIEM platforms support IPv6 natively but require explicit configuration to enable it.

4. Consider Disabling IPv6 on VPN Portals If Not Needed

This is the simplest mitigation. If your organization does not require IPv6 connectivity for remote access VPN, disable IPv6 on the VPN portal interface. Remove the AAAA DNS record. This eliminates the IPv6 attack surface entirely. It is a pragmatic short-term measure while you build out full IPv6 protection for the long term.

5. Stack Your Defenses

No single control is sufficient. The most resilient VPN brute force defense stacks multiple layers:

• External Dynamic List (EDL): Block known attacker IPs—both IPv4 and IPv6—at the firewall perimeter before they can attempt a single login
• Rate limiting: Limit authentication attempts per source IP per time window, applied to both address families
• Multi-factor authentication (MFA): Even if an attacker guesses a password, MFA prevents access. This is the single strongest control against credential-based attacks
• Account lockout policies: Lock accounts after a threshold of failed attempts, with alerting so your team can investigate
• CIDR-based blocking: For IPv6, block at the /64 or /48 prefix level rather than individual addresses, since attackers can rotate through enormous address ranges

ThreatListPro’s IPv6 Coverage

ThreatListPro monitors VPN brute force attack patterns across both IPv4 and IPv6 address families. When IPv6 addresses or prefixes are confirmed as brute force sources through our honeypot network and partner log analysis, they are included in the curated blocklist feed alongside IPv4 entries.

The curated list focuses on confirmed, high-confidence attacker addresses regardless of address family. ThreatListPro’s EDL format natively supports both IPv4 addresses and IPv6/CIDR notation. When you import the feed into your firewall, both IPv4 and IPv6 entries are applied—no additional configuration required on firewalls that support mixed-family EDLs (including Palo Alto Networks PAN-OS 8.0+ and FortiGate 6.0+).

IPv6 threat intelligence is an evolving space. As IPv6 adoption continues to grow, the volume of IPv6-sourced attacks will increase, and ThreatListPro’s coverage will expand accordingly. The goal is straightforward: if an IP address is confirmed as a brute force attacker, it belongs in the blocklist, whether it is 32 bits or 128 bits long.