Skip to main content
This page traces the path of a network packet from code running inside a Firecracker 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 (MITM 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

The orchestrator installs rules in two places for each sandbox:

​
In the sandbox network namespace (applied to veth and TAP interfaces)

# Block metadata service (always)
iptables -A FORWARD -d 169.254.169.254 -j DROP

# Allow rules (higher priority)
iptables -A FORWARD -d 1.1.1.1 -j ACCEPT

# Deny rules
iptables -A FORWARD -d 0.0.0.0/0 -j DROP

​
In the Firecracker VM (applied to eth0, set via envd at boot)

# Redirect HTTP to proxy
iptables -t nat -A OUTPUT -p tcp --dport 80 -j REDIRECT --to-port <proxy_http_port>

# Redirect HTTPS to proxy
iptables -t nat -A OUTPUT -p tcp --dport 443 -j REDIRECT --to-port <proxy_tls_port>

# Redirect other TCP (non-80/443) for domain checking
iptables -t nat -A OUTPUT -p tcp -j REDIRECT --to-port <proxy_other_port>

# Exclude envd traffic from redirection (to localhost/veth IP)
iptables -t nat -I OUTPUT -d 172.16.0.1 -j RETURN

​
Summary of interception points

Traffic typeIntercepted byWhat happens
HTTP to blocked IPSandbox iptables (kernel)DROP — no proxy involved
HTTP to blocked domainNamespace proxy (userspace)RST after Host header read
HTTP to allowed domain, no scanNamespace proxyForward raw TCP
HTTPS to blocked IPSandbox iptables (kernel)DROP — no proxy involved
HTTPS to blocked domainNamespace proxyRST after SNI peek
HTTPS to allowed domain, no scanNamespace proxyTLS passthrough
HTTPS to allowed domain, scan activeNamespace proxy (MITM)Decrypt, scan, re-encrypt
API-to-envd trafficPrivate veth pairNo interception, private network
Cloud metadata (169.254.169.254)VM iptables (hardcoded)DROP always