[Request]: Option to prevent host access on internal networks

[jamesmacaulay]

Feature or enhancement request details

On --internal networks, the host gateway IP (e.g. 192.168.128.1) is reachable from containers. Any host service bound to 0.0.0.0 is accessible from inside the VM. This is a concern for security-sensitive use cases like sandboxing AI coding agents, where if the agent runs as root inside the VM then it should not be able to reach the host.

Current behavior:

• container network create --internal creates a network with no internet access
• The host gateway is still present on the subnet and reachable from containers
• macOS pf firewall rules don't seem to filter vmnet-bridged traffic
• Guest-side iptables works but is bypassable by a root process inside the VM

Requested behavior:

A way to create a network where the host has no presence on the subnet, i.e. containers can communicate with each other but cannot reach the host. This would need to be enforced at the vmnet/hypervisor level so that it can't be bypassed from inside the VM.

Use case:

Running autonomous AI agents (e.g. Claude Code with --dangerously-skip-permissions) in isolated VMs. The dual-homed proxy approach from discussion #1170 handles internet allowlisting well, but the agent VM can bypass the proxy to reach host services directly via the gateway IP. Related discussion: #719.

Code of Conduct

• I agree to follow this project's Code of Conduct

[dcantah]

@jamesmacaulay I've been thinking about the exact same lately and should have something to share hopefully soon :)

[dcantah]

TLDR we should be able to expose some bits on containerization (the sister library that this project consumes) to do some nftables setup in the root of the vm such that it can only talk to certain ports on the gateway addr (for my use case only 1 port that is running a proxy). We can shove the container in a netns such that it's none the wiser about the rulesets applied to the other end of some veth in the root of the vm.

[dcantah]

I was exploring basically the same idea. Want to run some coding agent that only has access to 1 ip:port (for some http proxy running on the host). The problem without some redirection rules is exactly what you've pointed out, yes it can access the proxy on the host, but it can also access anything listening on 0.0.0.0 as well.