ICMP Redirect Attacks: Route Poisoning, LAN Interception & VPN Defense

On any shared Ethernet or Wi-Fi local area network, devices rely on dynamic routing protocols and local gateway announcements to route outbound traffic toward the wider internet. Under standard operating conditions, your workstation transmits packets to a default gateway router, which forwards the traffic hop by hop to its final destination. However, the foundational design of IPv4 includes a diagnostic control protocol engineered in 1981: the Internet Control Message Protocol (ICMP), standardized in RFC 792.

Embedded within RFC 792 is the ICMP Redirect message (Type 5). Designed during an era when local network nodes trusted all neighboring devices implicitly, ICMP Redirect allows a router to notify an end host that an alternative, more optimal first-hop router exists for a specific destination. When misconfigured or abused by an adversary sharing the local broadcast domain, this mechanism becomes an attack vector known as an ICMP Redirect attack or route poisoning.

Understanding how ICMP Redirect messages manipulate kernel routing tables reveals critical vulnerabilities in legacy operating systems and demonstrates why cryptographic tunnel isolation remains essential on unshielded networks.

Anatomy of RFC 792 ICMP Type 5 Messages

When a router receives an IP datagram and forwards it out through the exact same physical network interface on which it was received, standard routing logic assumes an inefficiency. The transmitting host could have reached the next hop directly without passing through the primary router first. In response, the router generates an ICMP Redirect packet directed back to the source host.

An ICMP Redirect datagram features a specific binary structure:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type (5)  |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Gateway Internet Address                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Internet Header + 64 bits of Original Data Datagram      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The message includes several specific parameters:

• Type Field: Set to binary value 5, denoting an ICMP Redirect.
• Code Field: Identifies the redirection scope:
  • Code 0: Redirect datagrams for the entire destination network.
  • Code 1: Redirect datagrams for a specific destination host.
  • Code 2: Redirect datagrams for the Type of Service and network.
  • Code 3: Redirect datagrams for the Type of Service and host.
• Gateway Internet Address: A 32-bit IPv4 address designating the alternate first-hop router to which future frames must be forwarded.
• Payload: The complete IPv4 header plus at least the first 64 bits (8 octets) of the original datagram payload that triggered the redirect.

When the operating system kernel on the originating client host receives this packet, it parses the attached 64 bits of original data. If the enclosed header matches an active socket connection (for example, matching the protocol, source IP, destination IP, and transport-layer port numbers), the kernel validates the notification and dynamically modifies its local Forwarding Information Base (FIB).

The Local Man-in-the-Middle Attack Vector

The vulnerability stems from the complete absence of cryptographic authentication within RFC 792. Any device connected to the same Layer-2 broadcast segment (such as an open coffee shop Wi-Fi network or an unmanaged office Ethernet switch) can craft and transmit forged ICMP Type 5 frames.

An attacker executes an ICMP route poisoning attack through three synchronized steps:

1. Traffic Sniffing: The attacker monitors local broadcast or promiscuous traffic to capture active outbound connections from the victim host.
2. Packet Forgery: The attacker crafts an ICMP Type 5 Code 1 (Host Redirect) packet. The packet specifies the attacker’s own local IP address inside the Gateway Internet Address field, sets the source IP to match the legitimate network router, and appends the victim's recently sniffed IP header and 8 bytes of payload.
3. Kernel Cache Injection: Upon receipt, the victim’s network stack assumes the packet originated from the genuine default gateway. The kernel immediately installs a transient /32 host route into its dynamic routing cache, assigning the attacker’s IP address as the immediate gateway for that target destination.

Once injected, all subsequent IP frames directed toward that target destination circumvent the genuine router and travel straight to the attacker's network adapter. The attacker forwards the captured packets onward to the real gateway after logging credentials, inspecting unencrypted payloads, or attempting TLS downgrade injections.

Threat Vectors Against Virtual Private Networks

Virtual private networks alter host routing topologies by establishing a virtual network interface (such as tun0 or wg0) and directing traffic through an encrypted tunnel. Despite this encapsulation, ICMP Redirect attacks present distinct threats when client stacks lack strict endpoint pinning and firewall isolation.

1. Tunnel Endpoint Redirection

To maintain an active VPN tunnel, the client operating system must route encapsulated UDP packets destined for the remote VPN server through the underlying physical network interface (such as eth0 or wlan0) toward the local LAN gateway.

If an attacker on the local network transmits an ICMP Redirect targeting the public IP address of the VPN server, an unprotected operating system will install a host route directing all encapsulated VPN packets to the attacker's machine. While the payload remains secured by robust cryptographic algorithms like ChaCha20-Poly1305, the attacker gains direct visibility into packet timings, data volumes, connection heartbeats, and can selectively drop traffic to trigger denial-of-service conditions.

2. Route Hijacking and Split-Tunnel Leakage

When a VPN operates under a split-tunnel configuration or fails to claim routing table priority via policy routing, rogue ICMP host routes can punch direct holes through the secure perimeter.

Because host routes with a /32 subnet mask possess higher prefix specificity than broad network routes (such as 0.0.0.0/1 or 128.0.0.0/1), an attacker can emit targeted ICMP redirects for sensitive destination IPs. If accepted, the operating system routes plaintext traffic for those specific addresses out through the local Wi-Fi interface instead of encapsulating it within the virtual tunnel adapter.

Hardening the Host: Disabling ICMP Redirects

Because modern network topologies feature centralized routers capable of efficient forwarding without host-level assistance, accepting ICMP Redirect messages provides negligible performance benefit while introducing severe security risks. RFC 1122 Section 3.2.2.2 advises that network hosts should not generate redirects and must strictly regulate their acceptance.

Disabling ICMP redirect handling across all interfaces establishes the first line of defense.

Linux Kernel Hardening via Sysctl

On Linux distributions, kernel parameters control whether redirect frames are processed or forwarded. Inspect current configurations with sysctl:

# Check current ICMP redirect settings across all interfaces
sysctl -a | grep -E "accept_redirects|send_redirects"

To permanently reject all incoming redirect notifications and prevent your host from generating them, configure /etc/sysctl.d/99-disable-icmp-redirects.conf:

# Disable ICMP redirect acceptance on all IPv4 interfaces
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0

# Disable ICMP redirect sending
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Disable IPv6 ICMPv6 redirect acceptance (RFC 4861)
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

Apply the changes immediately without restarting:

sudo sysctl --system

macOS and BSD Systems

On BSD derivatives and macOS, kernel redirect handling is controlled via the net.inet.icmp tree:

# Disable ICMP redirect acceptance on macOS / BSD
sudo sysctl -w net.inet.icmp.drop_redirect=1

Windows Host Configuration

On Windows workstations, redirect behavior is governed through the system registry under the TCP/IP parameter stack. Administrators can verify or enforce redirect rejection via PowerShell:

# Set EnableICMPRedirect to 0 in Windows Registry
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" -Name "EnableICMPRedirect" -Value 0 -Type DWord

Architectural Defense with RiceGuard Policy Routing

While kernel parameter hardening offers vital local protection, complete defense against local network manipulation requires cryptographic encapsulation paired with policy-based routing (PBR).

VPNRice implements the RiceGuard architecture to isolate internet traffic from local broadcast anomalies:

1. Isolated Routing Tables and Firewall Marks: Rather than simply updating the default kernel gateway in the primary table, RiceGuard marks outgoing application traffic with a dedicated firewall mark (fwmark). The Linux kernel routing policy database (ip rule) directs all marked packets exclusively through table 51820, pointing directly to the virtual tunnel interface.
2. Physical Interface Packet Filtering: RiceGuard deploys kernel-level packet filter rules via nftables that drop all incoming ICMP Type 5 packets on physical interfaces before the network stack can parse them.
3. Cryptographic Anti-Replay Verification: Even if an attacker attempts to intercept tunnel frames at the local Layer-2 layer, WireGuard's underlying Noise IK handshake protocol and 64-bit sliding window anti-replay counters reject forged or duplicate packets instantly.

By combining strict kernel sysctl hardening with RiceGuard's policy-routed cryptographic tunnel, network connections remain immune to local route poisoning, ensuring uncompromised privacy across untrusted Wi-Fi and corporate local networks.