Transparent Interception — No App Changes Required
Your application thinks it is talking directly to the network. It has no idea Envoy exists. It opens a socket to 10.0.0.5:5432 (a database), and data flows. But in reality, every byte is intercepted by Envoy first. This transparency is achieved through iptables NAT rules set up inside the Pod's network namespace.
When the Pod starts, the istio-init initContainer runs a script (pilot-agent istio-iptables) that installs the following rules:
Outbound interception:
Any TCP traffic leaving the application (from any port, to any destination) is redirected by the ISTIO_OUTPUT iptables chain to localhost:15001 — Envoy's outbound listener. Envoy then makes the actual connection to the real destination, applying all mesh policies (mTLS, retries, circuit breaking) along the way.
Inbound interception:
Any TCP traffic arriving at the Pod (on any port) is redirected by the ISTIO_INBOUND chain to localhost:15006 — Envoy's inbound listener. Envoy processes it (verifies mTLS, checks authorization policy) and then forwards it to the application on its real port.
The escape hatch:
Traffic from Envoy itself (running as UID 1337) is explicitly excluded from redirection. Without this exclusion, Envoy's outbound traffic would be redirected back to itself, creating an infinite loop.
Application (UID 1000)
└─ connect() to 10.0.0.5:5432
│
▼ (iptables ISTIO_OUTPUT rule intercepts)
│
Envoy Outbound Listener (:15001)
│
├─ Apply VirtualService routing rules
├─ Initiate mTLS handshake with destination
│
▼
Real connection to 10.0.0.5:5432
Why This Matters for Debugging
Because iptables operates at the kernel level, it is invisible to your application. If iptables rules are misconfigured or missing (e.g., istio-init failed), your application traffic bypasses Envoy entirely — no mTLS, no metrics, no policy enforcement — and you will not get an error. The traffic just works, silently bypassing the mesh. This is one of the hardest failure modes to detect.