How Envoy Hijacks Traffic: Deep Dive into iptables Sidecar Mode

Introduction

Envoy is a high‑performance network proxy designed for service meshes. It runs alongside applications as a sidecar, abstracting network functions in a platform‑agnostic way, and enables consistent observability and performance tuning when all service traffic passes through the mesh.

Sidecar vs. Gateway Modes

In Istio, Envoy can operate in two deployment modes:

Sidecar mode : traffic is intercepted using iptables rules.

Gateway mode : Envoy acts as a standalone gateway without iptables hijacking.

The sidecar mode is the focus of this analysis.

Interception Modes

Istio supports two iptables interception strategies:

REDIRECT : Uses the REDIRECT target to capture inbound packets and forward them to Envoy. This requires the nf_conntrack kernel module (available since Linux 2.6.15) for state tracking.

TPROXY : Uses the TPROXY target to redirect inbound traffic without altering the destination IP/port and without invoking connection tracking. Currently supported only for inbound traffic due to kernel limitations for outbound use.

Both modes can be set globally or per‑workload via the sidecar.istio.io/interceptionMode annotation.

Default REDIRECT Mode Details

When a pod enters the sidecar network namespace, Envoy’s default configuration applies the REDIRECT mode. The following iptables-save excerpt illustrates the generated NAT table rules:

# Generated by iptables-save v1.6.1 on Mon Dec  6 11:33:15 2021
*nat
:PREROUTING ACCEPT [3402:234907]
:INPUT ACCEPT [3167:190128]
:OUTPUT ACCEPT [529:49526]
:POSTROUTING ACCEPT [529:49526]
:ISTIO_INBOUND - [0:0]
:ISTIO_IN_REDIRECT - [0:0]
:ISTIO_OUTPUT - [0:0]
:ISTIO_REDIRECT - [0:0]
-A PREROUTING -p tcp -j ISTIO_INBOUND
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A OUTPUT -p udp -m udp --dport 53 -m owner --uid-owner 1337 -j RETURN
-A OUTPUT -p udp -m udp --dport 53 -m owner --gid-owner 1337 -j RETURN
-A OUTPUT -d 10.96.0.10/32 -p udp -m udp --dport 53 -j REDIRECT --to-ports 15053
-A ISTIO_INBOUND -p tcp -m tcp --dport 15008 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 22 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15090 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15021 -j RETURN
-A ISTIO_INBOUND -p tcp -m tcp --dport 15020 -j RETURN
-A ISTIO_INBOUND -p tcp -j ISTIO_IN_REDIRECT
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15006
-A ISTIO_OUTPUT -s 127.0.0.6/32 -o lo -j RETURN
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -p tcp -m tcp ! --dport 53 -m owner --uid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -o lo -p tcp -m tcp ! --dport 53 -m owner ! --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -m owner --gid-owner 1337 -j ISTIO_IN_REDIRECT
-A ISTIO_OUTPUT -o lo -p tcp -m tcp ! --dport 53 -m owner ! --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN
-A ISTIO_OUTPUT -d 10.96.0.10/32 -p tcp -m tcp --dport 53 -j REDIRECT --to-ports 15053
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
-A ISTIO_OUTPUT -j ISTIO_REDIRECT
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001
COMMIT
# Completed on Mon Dec  6 11:33:15 2021

Key observations:

Outbound DNS traffic (UDP/TCP 53) is redirected to port 15053.

Inbound traffic is captured on port 15006, while outbound traffic uses port 15001.

Specific ports such as 22, 15008, 15090, 15020, and 15021 are excluded from hijacking.

The address 10.96.0.10 represents the Kubernetes DNS service (CoreDNS) injected by Istio.

Because iptables relies on the conntrack module, high connection volumes can exhaust the tracking table, leading to packet drops. To mitigate this, eBPF‑based acceleration solutions have been proposed, allowing packets to bypass the kernel networking stack.

Additional Technical Details

Why both UDP and TCP port 53 are intercepted: support for DNS‑over‑TCP (see Istio PR #27081). The separation of ports 15001 (outbound) and 15006 (inbound) is intentional (see Istio PR #15713). A special loopback address 127.0.0.6 is used for internal Istio traffic handling (see Istio issue #29603).

Gateway Mode Overview

In gateway mode, Envoy does not use iptables for traffic hijacking, and listeners are not virtual; a deeper analysis will be provided in a future article.