Zone networking (standalone, no Kubernetes)

5 min read · Advanced

This guide explains how Edera zone networking works in standalone mode (without Kubernetes). For Kubernetes deployments, zone networking is handled by your CNI plugin and standard NetworkPolicy resources.

Overview

Edera zones communicate with the outside world through the host’s network stack. Each zone gets a virtual ethernet link to the host, and traffic is routed using standard Linux networking primitives: static routes, ARP proxying, and nftables.

Edera uses ARP proxying rather than a Linux bridge, which provides a simpler and more secure networking model.

Traffic flow

Zone network link → Xen VIF link → Host link (if static route exists) → External network

Traffic leaving a zone traverses the Xen virtual interface (vif) to the host. The host kernel routes it out through the host NIC, but only if a static route exists for the zone’s IP. This means even a privileged container that binds a new IP inside the zone cannot get traffic out unless someone with host-level access explicitly adds a route for it.

IP addressing

Zone IPs are allocated from configurable subnets defined in daemon.toml:

Any IP in the configured subnet range belongs to an Edera zone.

How it works

Virtual interfaces

When a zone (Xen domain) starts, a new virtual interface appears on the host:

vif<DOMID>.<DEVID>

For example, vif1339.2 is the virtual ethernet link for domain 1339, device 2. This interface acts as a virtual cable between the host and the zone—similar to a veth pair in traditional container networking, but managed by Xen.

Static routes

Edera adds a static route on the host for each zone IP, pointing to the zone’s VIF:

sudo ip route add 10.75.0.3/32 dev vif1339.2

This route is what allows the zone’s traffic to reach the host network stack. Without it, packets from the zone have no path out.

ARP proxying

Edera uses ARP proxying to route zone traffic through the host. The host kernel handles resolving and translating addresses for traffic coming out of the zone, but only if a static route for the zone’s IP exists.

This design has two key properties:

• Simple—no bridge interfaces to manage, fewer moving parts in the network path.
• Secure—a privileged container that binds a new IP inside the zone cannot reach the external network unless a static route is explicitly added by a process with host-level access.

nftables

Edera uses nftables to set up the forwarding and NAT rules that allow zone traffic to flow. When a zone starts, protect-network automatically configures:

• An EDERA-FORWARD chain in the filter table for zone traffic forwarding
• Accept rules for traffic on zone VIF interfaces
• NAT (masquerade) rules for zone traffic egressing through the host NIC

Example of the auto-generated forwarding rules:

nft add chain ip filter EDERA-FORWARD
nft insert rule ip filter FORWARD counter jump EDERA-FORWARD
nft add rule ip filter EDERA-FORWARD oifname "vifX.X" counter accept
nft add rule ip filter EDERA-FORWARD iifname "vifX.X" counter accept

Filtering zone traffic

Since zone traffic egresses from the host NIC, you can use standard host-level firewall rules to filter it, just like you would for any other traffic on the host. You don’t need to do anything special beyond layering your desired nftables (or iptables) rules on top of the ones Edera automatically adds.

Identifying zone traffic

All zone IPs fall within the configured subnet (default 10.75.0.0/16). You can use this to write rules that target zone traffic specifically.

Example: restrict zone egress to specific destinations

Block all zone egress except to allowed IPs:

# Create a chain for zone egress filtering
nft add chain ip filter ZONE-EGRESS

# Jump to it for traffic from the zone subnet
nft add rule ip filter FORWARD ip saddr 10.75.0.0/16 counter jump ZONE-EGRESS

# Allow DNS
nft add rule ip filter ZONE-EGRESS ip daddr { 8.8.8.8, 8.8.4.4 } udp dport 53 counter accept

# Allow HTTPS to specific destinations
nft add rule ip filter ZONE-EGRESS tcp dport 443 ip daddr { <ALLOWED_IP> } counter accept

# Drop everything else from zones
nft add rule ip filter ZONE-EGRESS counter drop

Example: restrict a specific zone

Target a single zone’s VIF interface for per-zone rules:

# Block all egress from a specific zone except HTTPS
nft add rule ip filter FORWARD iifname "vif1339.2" tcp dport != 443 counter drop

Domain-level filtering

nftables operates at layer 3/4 (IP addresses and ports), not at the domain name level. For domain-based filtering (for example, “allow api.anthropic.com but block everything else”), you have two options:

1. Resolve domains to IPs and create nftables rules—simple but brittle if IPs change.
2. Run a filtering proxy (for example, Envoy, Squid, or a custom proxy) on the host and route zone traffic through it—more robust, supports domain-based allowlists and TLS inspection.

Kubernetes deployments

For Kubernetes deployments, zone networking is handled by the CNI plugin and standard Kubernetes NetworkPolicy resources. The standalone networking backend described on this page is not used when running with Kubernetes.

Architecture notes

Relationship to protect-network

The protect-network daemon is responsible for reacting to zone lifecycle events and configuring the host network stack accordingly. When a zone starts, it:

1. Detects the new VIF interface
2. Adds a static route for the zone’s IP
3. Configures nftables forwarding and NAT rules
4. Enables ARP proxying for the interface

When a zone is destroyed, it cleans up the routes and rules.

Further reading

• Running Edera without Kubernetes
• How Edera’s components fit together
• Edera architecture overview