Network Isolation in ArcBox: A Deep Dive
[Security]

Network Isolation in ArcBox: A Deep Dive

2026-01-15

Kai Nakamura

Kai Nakamura

Security

The Challenge

Network isolation is one of the most critical security components. A compromised container with access to the host network could:

  • Eavesdrop on traffic
  • Perform DNS spoofing
  • Conduct man-in-the-middle attacks
  • Access internal services

ArcBox solves this with complete network isolation at the hypervisor level.

Architecture Overview

Virtual Network Interfaces

Each ArcBox VM gets its own virtual network interface (virtio-net):

┌─────────────────────────────┐
│  Host Network Stack         │
│  (Controlled by ArcBox)     │
└──────────────┬──────────────┘
               │ virtio-net pairs
   ┌───────────┴───────────────────────┐
   │                                   │
┌──▼──────────────┐         ┌──────────▼──┐
│  VM 1           │         │  VM 2       │
│  eth0: 10.0.0.2 │         │ eth0: ...   │
└──────────────────┘         └─────────────┘

iptables Rules

At startup, we generate strict iptables rules that:

  • Allow internal VM traffic only
  • Permit outbound DNS and HTTP/HTTPS
  • Block all other network access
  • Are enforced by the kernel itself

Implementation Details

Virtio-Net

Virtio-net is a para-virtualized network device that:

  • Provides high-performance networking
  • Runs in the hypervisor, not the guest
  • Can enforce security policies before packets reach the host

Dynamic Rule Generation

At VM startup, ArcBox generates rules specific to each container:

# Example rules generated for a VM
iptables -A INPUT -d 10.0.0.2 -j ACCEPT
iptables -A OUTPUT -s 10.0.0.2 -d 127.0.0.1 -j ACCEPT
iptables -A OUTPUT -s 10.0.0.2 -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -s 10.0.0.2 -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -s 10.0.0.2 -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT -s 10.0.0.2 -j DROP

Isolation Guarantees

Zero Host Leakage

Once isolated, the VM cannot:

  • Access the host's network stack
  • Perform ARP spoofing
  • Access other VMs' networks
  • Modify firewall rules
  • Access management interfaces

Per-VM Policies

Each VM can have custom network policies:

network:
  outbound:
    - protocol: tcp
      ports: [80, 443]
    - protocol: udp
      port: 53  # DNS only
  inbound:
    - from: 10.0.0.0/24
      port: 8080

Performance

Network isolation is enforced at the hypervisor level with minimal overhead:

  • Throughput: No degradation compared to unvetted networking
  • Latency: <1ms additional per packet
  • CPU: <0.5% overhead for firewalling

Real-World Scenario

A web server in an ArcBox container:

  1. Attacker compromises the application
  2. Attacker tries to exfiltrate data to their server
  3. Packets are generated but blocked by virtio-net firewall
  4. VM cannot even establish the connection
  5. Data remains secure

Advanced Features

Custom DNS

Each VM can have its own DNS resolver configuration with custom records for internal services.

Port Forwarding

Controlled port forwarding allows specific services to be exposed while maintaining isolation:

arcbox forward localhost:8080 => vm:3000

Service Mesh Compatibility

ArcBox works seamlessly with Istio and Linkerd for service-to-service isolation.

Future Improvements

  • Per-connection encryption enforcement
  • Bandwidth limiting per VM
  • Traffic analysis and monitoring
  • Encrypted virtual networks (WireGuard integration)

Conclusion

Network isolation in ArcBox provides complete confidence that containers cannot communicate with the host or other VMs without explicit permission. This is real isolation, not just containerization.

That's all. Except not.

Ready to ditch
Docker Desktop?

Join thousands of developers who switched to something faster, lighter, and built for the way they actually work.

Free for personal use. Pro plans available for teams.

ArcBox - Containers
Terminal

$ arcbox run nginx

Starting container...

Ready in 47ms

Sandbox