Skip to main content
This page traces the path of a network packet from code running inside a sandbox to the internet and back, covering both HTTP and HTTPS flows with and without security scanning.

Physical network layout

Flow 1: HTTPS with no security scanning

When only a domain allowlist (no PII, no injection) is configured, the proxy uses TLS passthrough — it inspects the SNI without decrypting. The workload negotiates TLS directly with the destination — the proxy is invisible.

Flow 2: HTTPS with PII scanning (edge proxy active)

When PIIConfig.enabled=True, the proxy performs full TLS interception.

Flow 3: Domain blocked

Flow 4: IP blocked by iptables (CIDR rule)

IP and CIDR rules bypass the userspace proxy entirely — they are kernel-level DROP rules.

Flow 5: Metadata service block (always-on)

The cloud metadata endpoint 169.254.169.254 is blocked by a hardcoded DROP rule regardless of network policy:

Flow 6: envd traffic (API-to-sandbox)

SDK calls go through the orchestrator to envd via the private veth pair — this traffic never crosses the public network:

iptables rule structure

All rules live host-side in the sandbox’s network namespace — the guest VM has no iptables rules of its own. The orchestrator installs two rule sets per sandbox, both keyed on the TAP interface that carries VM-originated traffic:

nat table — PREROUTING REDIRECT (on the TAP interface)

Redirects VM-originated TCP onto the namespace proxy’s local listeners:

filter table — FORWARD allow/deny

Summary of interception points