There is a document that settles this entire question before it starts. RFC 7296 — Internet Key Exchange Protocol Version 2 — was published in October 2014. Its Section 2.1 defines exactly one exchange type for initial security association negotiation. Not two. One. There is no aggressive mode in IKEv2. There is no main mode. Those distinctions belong to IKEv1, specified in RFC 2409, a protocol finalized in 1998 that RFC 7296 was designed to supersede. Yet across penetration testing forums, certification prep materials, and VPN vendor documentation, the phrase "IKEv2 aggressive mode pre-shared key brute force" circulates as though it describes a real attack surface. It does not.
The Protocol Version Conflation
The root of this confusion can be stated plainly: people do not read RFCs. They read summaries of summaries. IKEv1, as defined in RFC 2409, offered two Phase 1 exchange modes. Main mode consumed six messages and protected both peers' identities behind encryption before any authentication material crossed the wire. Aggressive mode compressed that to three messages by transmitting the initiator's identity and authentication hash in the clear during the first exchange. That compression carried a cost — a passive observer could capture the hash, pull it offline, and run a dictionary attack against the pre-shared key at whatever rate their hardware permitted.
IKEv2 replaced both modes with a single four-message sequence: IKE_SA_INIT followed by IKE_AUTH. The IKE_SA_INIT exchange establishes a Diffie-Hellman shared secret and negotiates cryptographic parameters. Everything sensitive happens afterward. The IKE_AUTH exchange — the part that carries identity and authentication — occurs inside an encrypted channel that IKE_SA_INIT has already built. Identities and authentication payloads never traverse the network unprotected. There is no three-message shortcut. The protocol specification forbids it.
Yet the conflation persists, and for a concrete reason: both protocols share UDP port 500, and port 4500 for NAT traversal. Many gateway products support both versions simultaneously. A Cisco ASA running software prior to version 9.14 would negotiate IKEv1 aggressive mode if a client proposed it, regardless of what the administrator believed was configured. CVE-2020-3125, disclosed in May 2020, demonstrated a Kerberos authentication bypass on Cisco ASA that could be combined with protocol downgrade scenarios — a reminder that dual-stack IKE configurations produce version ambiguities that neither operators nor auditors consistently resolve. When a vulnerability scanner flags "IKE aggressive mode PSK" on port 500, it is reporting an IKEv1 behavior. The report almost never says that explicitly enough.
The Aggressive Mode Ghost
Penetration testing toolkits have an institutional memory that outlives the vulnerabilities they were built to find. ike-scan, originally written by Roy Hills, remains a standard VPN enumeration tool despite its age. Its default behavior sends IKEv1 main mode and aggressive mode probes. When a gateway responds — and many still do, because backward compatibility ships as a default — ike-scan reports the aggressive mode handshake. It does not prominently flag the protocol version. A tester who runs the scan, captures an aggressive mode response, and writes "target supports aggressive mode with pre-shared key authentication" has produced a technically accurate IKEv1 finding that reads as though it applies to the IKE implementation generally.
Certification training deepens the habit. Study material for the Offensive Security Certified Professional and comparable credentials teaches IKE aggressive mode exploitation as a core VPN attack technique. The pedagogy is sound within its IKEv1 scope. But the curriculum rarely stops to clarify that this attack surface disappears entirely under IKEv2. Students internalize "IKE aggressive mode equals vulnerable" as an unqualified rule, carry it into professional engagements, and never revisit the version boundary. The misattribution becomes muscle memory.
Vendor documentation provides the third reinforcement. Configuration guides that advise administrators to "disable aggressive mode to prevent pre-shared key exposure" are giving correct IKEv1 guidance. They are simultaneously implying, to any reader who does not already know the protocol history, that aggressive mode is a configurable option in IKEv2. It is not a configurable option. It is not a hidden option. It is a concept that does not exist within the specification at all.
If your finding references "IKEv2 aggressive mode," you have either misidentified the protocol version or documented an attack surface that the RFC never defined.
The Pre-Shared Key Blame Shift
This is where the analysis moves past taxonomy and into threat model territory. Pre-shared keys in IKEv2 carry genuine weaknesses. They are categorically different from the IKEv1 weakness that started this conversation.
In IKEv1 aggressive mode, the flaw is structural. The responder transmits a hash derived from the PSK before the Diffie-Hellman exchange has completed encryption of the channel. Any passive observer with a packet capture can extract that hash and run offline dictionary attacks at GPU speed. The research presented at USENIX Security 2018 by Felsch, Grothe, Schwenk, Czubak, and Szymanek demonstrated practical exploitation of IKEv1 authentication weaknesses, including PSK hash extraction from aggressive mode exchanges. Cracking a weak pre-shared key from a captured hash was shown to be computationally trivial with commodity hardware. Hours, not weeks.
IKEv2 operates on fundamentally different sequencing. The PSK authenticates within the IKE_AUTH exchange, which is encrypted by keys derived from IKE_SA_INIT. A passive network observer captures nothing useful. An active man-in-the-middle attacker cannot extract the PSK hash for offline work because the authentication payload is encrypted with Diffie-Hellman-derived keys the attacker does not possess. What remains is an online attack: attempting authentication directly against the gateway, one guess per attempt, subject to rate limiting, account lockout, and source blacklisting at the implementation level.
Offline versus online. That distinction is the entire threat model gap. An offline brute force scales with attacker hardware — throw more GPUs at it, get faster results. An online attack scales with defender tolerance — configure your gateway to drop connections after five failed attempts from the same source and the attacker's compute advantage becomes irrelevant. Confusing the two misstates the risk by orders of magnitude. A weak PSK exposed through IKEv1 aggressive mode falls in hours. That same weak PSK behind IKEv2's encrypted authentication could resist online guessing for months against a properly configured endpoint, assuming the endpoint does not simply refuse further attempts well before that.
NIST Special Publication 800-77 Revision 1, published June 2020, addresses IPsec VPN configuration guidance and explicitly recommends IKEv2 over IKEv1. Among its rationale: the elimination of aggressive mode as an attack surface. When the federal authority on cryptographic implementation standards makes the protocol version distinction central to its own recommendation, treating both versions as interchangeable in a penetration test deliverable is not a simplification. It is a factual error.
The Pentest Template Inheritance
Audit findings have an inheritance problem that mirrors software dependency rot. A consultancy that performed fifty VPN assessments in 2019 built a findings library. Somewhere in that library sits a finding titled "IKE Aggressive Mode Pre-Shared Key Vulnerability" with a canned description, a severity rating, and boilerplate remediation text. Five years later, the finding persists unchanged. A new analyst encounters an IKE service on port 500, runs ike-scan, captures an aggressive mode handshake from an IKEv1-speaking endpoint, and drags the template finding into the report. The finding omits the version number. It says "IKE."
The client's infrastructure team reads the report, checks their gateway configuration, sees IKEv2 selected, and pushes back. The consultancy, rather than correcting the version attribution, sometimes defends the finding as "still relevant for defense in depth." This is institutional face-saving dressed as security guidance. A finding about a protocol mode absent from the deployed protocol version is a false positive. Relabeling it as defense-in-depth does not change the underlying misidentification.
The regulatory landscape makes this conflation harder to defend. ENISA — the European Union Agency for Cybersecurity — publishes guidelines on cryptographic protocols for network security that draw a clear line between IKEv1 and IKEv2 security properties. Germany's BSI Technical Guideline TR-02102-3, which covers IPsec and IKE and receives periodic updates, specifies that IKEv1 aggressive mode must not be deployed and separately addresses IKEv2 pre-shared key considerations as a distinct topic with distinct mitigations. A compliance audit referencing BSI guidelines that conflated the two versions would contradict the very source material the auditor claims to follow. Across the Atlantic, CISA has published advisories flagging specific IKEv1 vulnerabilities in legacy networking equipment — the 2016 advisory on Cisco IOS IKEv1 fragmentation handling among them — without attributing those weaknesses to IKEv2 deployments. The advisory and regulatory ecosystem treats the versions as different protocols. The pentest findings template often does not.
The downstream cost is measurable in misdirected effort. When a legitimate IKEv1 aggressive mode finding is written vaguely enough to implicate IKEv2, remediation work targets the wrong surface. An infrastructure team investigating whether their IKEv2 deployment is "exposed to aggressive mode brute force" is chasing something that cannot exist in their configuration. The actual risk — that the same gateway might still accept IKEv1 fallback connections on a legacy configuration nobody remembered to disable — goes unexamined because the precise question was never asked.
So What Do You Actually Do
Start by determining whether your VPN gateways speak IKEv1 at all. Not whether they are configured for IKEv2 — whether they also respond to IKEv1 proposals when probed. Dual-stack deployment is common, and dual-stack is where the real exposure lives. Run explicit version-differentiated probes and inspect the transform set in the response. If a gateway negotiates an IKEv1 security association using aggressive mode, you have found the genuine vulnerability. The remediation is disabling IKEv1 on the gateway entirely — not "disabling aggressive mode in IKEv2," which amounts to removing a feature from software that was never installed.
If operational constraints require pre-shared keys with IKEv2 — and there are environments where certificate infrastructure is genuinely impractical — treat the PSK as a high-entropy cryptographic secret rather than a human-memorable password. The IKEv2 PSK is not exposed to the offline hash extraction that makes IKEv1 aggressive mode lethal, but a weak key remains a weak key regardless of the protocol protecting it. Sixteen random bytes generated from a cryptographic source is reasonable. A passphrase a human chose because it was easy to type on a phone is not. The relevant threat against IKEv2 PSK is online guessing, and sufficient entropy renders online guessing inert within any realistic operational timeframe.
When an audit report lands on your desk and references "IKEv2 aggressive mode," ask the auditor to cite the RFC section that defines the mode they claim to have identified. There is no such section. If they cannot point to a specification, the finding is either mislabeled IKEv1 or fabricated, and it should be corrected or withdrawn. This is not terminological nitpicking — it is the difference between a security assessment that directs resources toward actual risk and a document that sends your team investigating protocol states that do not exist. We would revise this position if a future IETF extension to IKEv2 reintroduced a reduced-round-trip exchange that exposed authentication material prior to encryption establishment. No such RFC has been published, no Internet-Draft proposing it is under active consideration, and the foundational design principle of IKEv2 — establish encryption first, authenticate inside the encrypted channel — runs against the possibility. Until the protocol specification changes, the brute force attack you are searching for exists in IKEv1 and nowhere else.