VR on IPsec VPN Part 1 - First Peek Into The Rabbit Hole

1. Introduction

This series is about vulnerability research against IPsec VPN, with IKEv2 as the main target. Before we start building labs or crafting packets, we need a clear picture of what IPsec actually gives us, why the attack surface is worth the pain, and how we plan to poke at it.

This first part stays high level on purpose. We will cover:

1. What IPsec is and the properties it claims to provide.
2. Why edge VPN implementations are such a juicy (and painful) target.
3. How IKEv2 replaced IKEv1, and why that state machine is hard to fuzz.
4. The lab and analysis approach we will use for the rest of the series.

2. What is IPsec?

IPsec (Internet Protocol Security) is a suite of protocols used to secure IP communications over untrusted networks such as the Internet. It provides:

• Confidentiality – encryption prevents eavesdropping on traffic.
• Integrity – tamper detection ensures packets have not been modified in transit.
• Authentication – both peers verify each other’s identity before exchanging data.
• Anti-replay protection – sequence numbers prevent an attacker from capturing and replaying legitimate packets.

IPsec is commonly used for site-to-site VPNs (connecting two office networks over the Internet) and remote access VPNs (allowing individual users to connect securely to a corporate network). Those remote access deployments are often called road warrior setups, which is exactly the lab topology we will build in Part 2.

3. Motivations

IPsec is widely deployed on edge devices from vendors like Palo Alto, Cisco, and F5. That makes it a highly valuable attack surface:

• It is an entry point directly reachable from the Internet or other untrusted networks.
• A remote code execution (RCE) vulnerability in an IPsec implementation can give an attacker access to the internal networks behind the VPN gateway.

CVE-2026-33824 is one such vulnerability: a double-free in the Windows IKEv2 implementation caused by improper ownership handling of a heap-allocated blob pointer during IKEv2 fragment reassembly.

Even FortiGate made a move to only support IPsec VPN from 7.6.3, ridding itself of the ever-vulnerable SSL VPN. If vendors are betting the farm on IPsec, then implementations of IKEv2 are where the interesting bugs are going to live.

4. Internet Key Exchange (IKE)

IPsec relies on the Internet Key Exchange (IKE) protocol to automate the negotiation and establishment of Security Associations (SAs). An SA is essentially an agreement between two peers on which cryptographic algorithms and keys to use. IKE runs on UDP port 500 (or port 4500 when NAT traversal is in use).

There are two versions of IKE:

The rest of this series focuses on IKEv2.

5. Difficulty for VR

Vulnerability research against IKEv2 is hard – and “hard” is an understatement. The protocol is deeply stateful: a responder only does anything interesting after a valid IKE_SA_INIT exchange and a completed Diffie-Hellman handshake. A coverage-guided fuzzer feeding random bytes at UDP/500 will almost never reach the deeper code paths, because the very first state-machine checks reject anything that does not look like a well-formed initiation.

On top of that statefulness, there are many distinct branches an implementation has to handle:

• IKE_SA_INIT, IKE_AUTH, IKE_INTERMEDIATE, CREATE_CHILD_SA, and INFORMATIONAL exchanges.
• Fragmentation and reassembly, rekeying, EAP, redirect, and NAT-D payloads.

Then there is the combinatorial explosion of configurations: certificate-based versus PSK authentication, a wide range of Diffie-Hellman (DH) groups, and – increasingly – Post-Quantum key exchange negotiated via Additional Key Exchanges (ADDKE) per RFC 9370.

But precisely because the surface is this large and this stateful, something somewhere is bound to mishandle a transition. That is exactly what makes it worth attacking.

6. Approach

Our approach is to combine a controlled lab environment with both static and dynamic analysis of the target implementation:

• Lab environment. A strongSwan server and client on Linux, on an isolated network, give us a known-good reference implementation to drive and observe.
• Verbose debugging. With strongSwan’s ike subsystem log level set to 4 (or the save-keys plugin enabled), the daemon dumps the SK* session keys into a Wireshark-compatible ikev2_decryption_table, so we can decrypt captured IKEv2 traffic and inspect every payload.
• Packet crafting. Scapy’s ikev2 contrib layer lets us build and mutate raw IKEv2 packets – including fragments for replay and targeted fuzzing.
• Static and dynamic analysis. On the server side, we combine static reverse engineering (Ghidra, and CodeQL where source is available) with dynamic analysis of the process that handles incoming client traffic.

7. Conclusion

This first part covered the IPsec and IKEv2 background and laid out why the protocol is a worthwhile target. The rest of the series will walk through the lab setup and packet crafting – and, if we’re lucky, turn up some new bugs in strongSwan along the way.

Before we start poking at message types, we need a lab we fully control. That is what Part 2 is for: building strongSwan from source, wiring up PSK and certificate-based road warrior connections, and dumping session keys into Wireshark.

8. References

1. RFC 7296 – Internet Key Exchange Protocol Version 2 (IKEv2)
2. RFC 9370 – Multiple Key Exchanges in IKEv2 (ADDKE)
3. Scapy IKEv2 contrib layer
4. strongSwan Logging documentation
5. strongSwan save-keys plugin