Decoding Istio Ambient Mesh: Full Pod‑to‑Pod Traffic Path Explained

Introduction

Istio Ambient Mesh moves sidecar functionality into ztunnel and waypoint, using iptables and policy routing to enforce traffic rules. The article analyses the complete traffic path for a simple scenario: a curl request from a sleep pod on Node‑A to an httpbin service whose backing pod runs on Node‑B.

Environment

The demo uses a minimal setup: a sleep pod on Node‑A sends an HTTP request to the httpbin service (ClusterIP 10.96.0.105) which resolves to a pod on Node‑B. Under Ambient Mesh, packets traverse iptables, policy routing, and the ztunnel proxy before reaching the destination.

Full Traffic Path Overview

The path consists of three logical sections:

Curl →

ztunnel‑A

ztunnel‑A

→

ztunnel‑B

ztunnel‑B

→ httpbin pod

Each section is illustrated with diagrams (preserved as

tags) and detailed iptables/routing rules.

Section 1: Curl → ztunnel‑A

When the curl command resolves the service name, the packet’s destination is the service ClusterIP. Ambient Mesh adds custom iptables rules in the mangle and nat tables that jump to a ztunnel‑PREROUTING chain. Packets from the sleep pod are matched against an ipset ( ztunnel‑pods‑ips) and marked with 0x100. The subsequent policy routing rule directs these marked packets to routing table 101, which forwards them via the bridge interface istioout to the pistioout device inside the ztunnel pod.

=== PREROUTING ===
--- raw ---
--- mangle ---
    -A PREROUTING -j ztunnel-PREROUTING
--- nat ---
    -A PREROUTING -j ztunnel-PREROUTING
    -A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
    -A PREROUTING -d 172.18.0.1/32 -j DOCKER_OUTPUT
=== ztunnel-PREROUTING ===
--- mangle ---
    -A ztunnel-PREROUTING -p tcp -m set --match-set ztunnel-pods-ips src -j MARK --set-xmark 0x100/0x100
--- nat ---
    -A ztunnel-PREROUTING -m mark --mark 0x100/0x100 -j ACCEPT

Policy routing then uses table 101, whose default rule forwards the packet to the bridge istioout, reaching the ztunnel pod’s pistioout interface.

Inside the ztunnel pod, another iptables rule redirects traffic from pistioout to 127.0.0.1:15001 (the outbound proxy) while preserving the original destination via TPROXY. The packet is marked 0x400 and routed using table 100, which sends it to the loopback interface where the ztunnel process receives it.

-A PREROUTING -i pistioout -p tcp -j TPROXY --on-port 15001 --on-ip 127.0.0.1 --tproxy-mark 0x400/0xfff

Section 2: ztunnel‑A → ztunnel‑B

After decryption, ztunnel‑A initiates a connection to the target pod’s IP on port 15008 (used by Ambient Mesh for inbound routing). The packet exits the ztunnel‑A pod via its eth0 to the host, then follows the node’s routing table to the remote node (Node‑B) using the istioout bridge.

On Node‑B, policy routing tables (e.g., table 100) forward the packet to the istioin bridge, whose peer pistioin resides in ztunnel‑B. Inside ztunnel‑B, a TPROXY rule redirects the packet to 127.0.0.1:15008 and marks it 0x400. The packet is then routed via table 100 to the loopback interface, reaching the inbound listener of ztunnel‑B.

-A PREROUTING -i pistioin -p tcp -m tcp --dport 15008 -j TPROXY --on-port 15008 --on-ip 127.0.0.1 --tproxy-mark 0x400/0xfff

Section 3: ztunnel‑B → httpbin Pod

ztunnel‑B

uses the original destination (the httpbin pod IP) and the source address of the original sleep pod (via IP_TRANSPARENT) to construct a packet that appears to come directly from the source pod. The packet is sent out of ztunnel‑B ’s eth0, traverses the host’s main routing table, and is delivered to the veth pair that connects the host to the httpbin pod’s network namespace.

The final routing rule in the host’s main table directs traffic for the pod IP to the appropriate veth device, completing the transparent end‑to‑end path.

Conclusion

The analysis shows that Ambient Mesh achieves full transparency by hijacking packets at the host level, marking them, and using dedicated routing tables to steer traffic through ztunnel proxies without the applications being aware of the intermediate hops. The first packet of each direction follows a distinct path (via bridge interfaces), while subsequent packets are handled based on connection marks ( 0x210) that keep them on the optimized path.