I set up a full dual-stack enterprise network in GNS3, launched a silent IPv6 man-in-the-middle attack using nothing but a Python script — and then shut it down completely with a single switch policy. This post walks through every step: the topology, the ACLs, the attack, and the mitigation.
Table of Contents
- What This Project Is About
- The Threat: SLAAC Abuse
- Lab Setup
- Network Topology and Addressing
- Dual-Stack Configuration
- Parallel ACL Policy — IPv4 and IPv6
- RA Guard Deployment
- The Attack: Live SLAAC Hijack from Kali Linux
- Mitigation and Verification
- Lessons Learned
- Final Results
1. What This Project Is About
Most enterprise security teams have years of experience hardening IPv4. Firewalls, ACLs, ARP inspection, DHCP snooping — the whole stack is mature and well-understood.
But IPv6? It's usually an afterthought.
The problem is that dual-stack networks run both protocols simultaneously on the same physical links. If your IPv4 controls are airtight but your IPv6 is unmonitored, an attacker on the same segment can bypass everything — silently — using protocols and attack techniques that didn't exist when your security policy was written.
This project addresses that gap from scratch. Here's what I built and proved:
- ✅ A full multi-VLAN dual-stack enterprise network in GNS3
- ✅ Parallel ACL policies that give IPv6 the same level of control as IPv4
- ✅ A live SLAAC abuse attack that silently hijacks all IPv6 traffic on a segment
- ✅ RA Guard mitigation that kills the attack with zero host-side changes
Let's get into it.
2. The Threat: SLAAC Abuse
Before the configs, you need to understand why IPv6 is a problem.
In IPv4, getting a network address requires either manual config or a DHCP server. In IPv6, there's a third option called SLAAC — Stateless Address Autoconfiguration (RFC 4862).
Here's how it works normally:
- A router periodically broadcasts a Router Advertisement (RA) — an ICMPv6 type-134 packet — to the all-nodes multicast address
ff02::1
- The RA contains a prefix (e.g.
2001:db8:2:10::/64) - Every host on the segment receives it and automatically generates its own IPv6 address by appending a 64-bit interface ID to that prefix
- The router's link-local address becomes the host's default IPv6 gateway
This is elegant and stateless. It's also a security nightmare.
Here's the attack: nothing stops any host on the segment from sending its own RA. If an attacker broadcasts a forged RA advertising a prefix they control, with themselves listed as the default gateway — every host on the segment will:
- Auto-configure an IPv6 address in the attacker's prefix
- Install the attacker's link-local address as their default IPv6 route
- Forward all outbound IPv6 traffic through the attacker first
The victims get no error, no warning, no prompt. The OS just follows RFC 4862 correctly. It's a full man-in-the-middle, achieved with a single Python script, requiring zero privileges on victim machines.
This is exactly what I demonstrated in this lab.
3. Lab Setup
What You Need
| Component | Details |
|---|---|
| Simulator | GNS3 2.x with GNS3 VM |
| Router image | Cisco IOSv (vios-adventerprisek9-m.vmdk) |
| Switch image | Cisco IOSvL2 (vios_l2-adventerprisek9-m.vmdk) — IOS 15.2(4)S minimum |
| Attacker | Kali Linux 2024 (GNS3 appliance) |
| Victims | GNS3 VPCS × 3 |
| Attack tool | Python 3 + Scapy 2.5 |
IOS version matters. RA Guard — the primary mitigation — requires IOS 15.2(4)S or later on the switch. Check with
show versionbefore starting. If your image is older, the RA Guard commands will silently do nothing.
GNS3 Setup Steps
- Install GNS3 from
CODEdual-stack-security/
├── configs/
│ ├── router/CORE-RTR.cfg ← Full dual-stack router config + ACLs
│ └── switch/DIST-SW.cfg ← VLANs, RA Guard, DHCPv6 Guard
├── attack/
│ └── rogue_ra.py ← Scapy rogue RA script
├── report/
│ └── dual_stack_report.tex ← Full LaTeX report (compile in Overleaf)
└── docs/
├── ADDRESSING.md
├── ACL_POLICY.md
└── RA_GUARD.md
⚠️ The attack script is for authorized lab use only. Never run it on a network you don't own.
Ahmed El Euch — Network Security Engineering
↗ Original-Artikel auf dev.to lesenVollständiger Original-BerichtAusführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.
SOCIAL SHARE CARD GENERATOR