[Bug]: --internal (hostOnly) networks allow arbitrary outbound TCP; isolation test passes only because DNS fails

[rc979]

I have done the following

• I have searched the existing issues
• If possible, I've reproduced the issue using the 'main' branch of this project

(Reproduced on the 1.2.0 signed release. The relevant code paths on main appear unchanged — see "Root cause" below.)

---

Steps to reproduce

1. Create a host-only network:

   container network create --internal isolated-test

2. Confirm the mode:

   container network inspect isolated-test | grep mode
   #       "mode" : "hostOnly",

3. Confirm the container has a single NIC, one default route, and no proxy configuration:

   container run --rm --network isolated-test alpine/curl \
     sh -c 'ip -o addr show | grep -v " lo "; ip route; env | grep -i proxy || echo "(no proxy vars)"'

   2: eth0    inet 192.168.250.2/24 scope global eth0
   default via 192.168.250.1 dev eth0
   192.168.250.0/24 dev eth0 scope link  src 192.168.250.2
   (no proxy vars)
   

4. Reach the public internet over TCP, addressing hosts by IP:

   container run --rm --network isolated-test alpine/curl \
     curl -sSk --connect-timeout 8 -o /dev/null -w "http=%{http_code}\n" \
     -H "Host: github.com" https://140.82.121.4/

   http=200
   

5. Confirm the traffic is NAT'd out of the host, not blocked:

   # from the isolated network
   container run --rm --network isolated-test alpine/curl \
     curl -sS --noproxy '*' https://1.1.1.1/cdn-cgi/trace | grep ^ip=
   # ip=[REDACTED — host's public IP]
   
   # from the default NAT network, for comparison
   container run --rm alpine/curl \
     curl -sS --noproxy '*' https://1.1.1.1/cdn-cgi/trace | grep ^ip=
   # ip=[REDACTED — identical]

   Both networks egress with the same public source address.

Scope of the leak

Outbound TCP is fully open. UDP and ICMP are not forwarded.

Test from the hostOnly network	Result
https://140.82.121.4 (GitHub, -k)	HTTP 200
https://151.101.1.140 (Fastly, -k)	HTTP 421 (real server response)
https://1.1.1.1, 1.0.0.1, 8.8.8.8, 9.9.9.9	301 / 301 / 302 / 404
nslookup example.com 8.8.8.8 (UDP/53)	timeout
ping 8.8.8.8 (ICMP)	100% loss

---

Problem description

--internal is documented and implemented as an isolation boundary, but it does not block egress. A container on a hostOnly network can open TCP connections to any internet host, NAT'd behind the host's public IP.

The intended behavior is stated consistently in four places:

• NetworkMode.swift — hostOnly: "Containers can talk with each other in the same subnet only."
• Isolated network #1079, which introduced the flag — "Containers under the same subnet can connect each other (and the host), but not the external network."
• container network create --help — "Restrict to host-only network."
• [Request]: Option to prevent host access on internal networks #1320 describes the current behavior as "creates a network with no internet access" — that premise does not hold.

Why this has gone undetected

The integration test that covers this asserts isolation by resolving a hostname:

// Tests/IntegrationTests/Network/TestCLINetwork.swift
// External connection should be blocked — the isolated network has no gateway.
let externalResult = try f.run([
    "run", "--rm", "--network", net, curlImage,
    "curl", "--connect-timeout", "5", "http://google.com",
])
let hostOnlyBlockedCodes: Set<Int32> = [6, 7, 28]
#expect(hostOnlyBlockedCodes.contains(externalResult.status), ...)

DNS is known not to work on host-only networks (noted by @jglogan in discussion #1170), so this test terminates on curl exit 6 — "couldn't resolve host" — which is the UDP path failing, not the TCP path being blocked. On the same network, in the same moment:

curl http://google.com       → exit 6    ← scored as "blocked"
curl https://140.82.121.4/   → HTTP 200  ← actual egress

The test would pass unchanged with TCP egress wide open. #1552 later widened the assertion from == 6 to {6, 7, 28} in response to flakes, which further decoupled it from what it is meant to verify.

The missing UDP/ICMP translation and the "DNS doesn't work on host-only networks" limitation are the same underlying gap — and that gap is precisely what conceals the open TCP path.

The test comment also states "the isolated network has no gateway", but a gateway is configured unconditionally (gateway = ipv4Subnet.lower + 1), and the guest receives it as its default route.

Root cause

The only isolation mechanism is the vmnet operating mode:

// Sources/Services/NetworkVmnet/Server/ReservedVmnetNetwork.swift:114
let mode: vmnet.operating_modes_t = configuration.mode == .hostOnly
    ? .VMNET_HOST_MODE : .VMNET_SHARED_MODE

There is no packet filter rule, no route suppression, and no other enforcement anywhere in the vmnet plugin. The guarantee rests entirely on VMNET_HOST_MODE suppressing forwarding, which does not hold for TCP on this configuration. The host has net.inet.ip.forwarding: 1 and holds 192.168.250.1 on bridge100.

Impact

--internal combined with a dual-homed proxy is the isolation pattern recommended to users sandboxing autonomous coding agents (discussion #1170, and #1320 / #719). Under that pattern the sandboxed workload can bypass the proxy entirely by connecting to any destination by IP address. Users following the documented guidance are getting materially less containment than the flag advertises.

Suggested fix

1. Enforcement — apply an explicit egress block for hostOnly subnets rather than relying on VMNET_HOST_MODE alone, or plumb through a vmnet configuration that reliably suppresses forwarding.

2. Test — assert against a raw IP so the check exercises the TCP path rather than DNS:

   // Reaching a literal IP proves egress is open regardless of DNS state.
   let externalResult = try f.run([
       "run", "--rm", "--network", net, curlImage,
       "curl", "-sSk", "--connect-timeout", "5", "https://1.1.1.1/",
   ])
   #expect(externalResult.status != 0, "hostOnly network must not reach external IPs")

   Retaining a hostname-based check as well is fine, but it cannot be the only signal.

---

Environment

• OS: macOS 26.5 (25F71), Apple silicon (arm64)
• Xcode: n/a — Command Line Tools only (/Library/Developer/CommandLineTools)
• Container: Container CLI version 1.2.0 (build: release, commit: 6e65319)

---

Code of Conduct

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

[am-saksham]

I'm going to take a stab at fixing this by conditionally dropping the default gateway allocation for hostOnly networks, and updating the integration test to check against a raw IP.

[jglogan]

@am-saksham dropping the default gateway would make it so the host cannot be reached, correct?

[am-saksham]

Hi @jglogan, great question!

Dropping the default gateway removes the 0.0.0.0/0 route, which successfully stops the container from reaching the internet or the host's external LAN IPs.

However, the container can still reach the host via the host's assigned IP on the internal vmnet subnet (e.g., 192.168.250.1). Because the subnet's link-local route (e.g., 192.168.250.0/24 scope link) remains intact, local traffic between the container and the host still routes perfectly.

If the intended --internal behavior is for the container to reach the host only on that specific bridge interface, this approach keeps the host accessible while successfully plugging the TCP egress leak.

[jglogan]

I'm unable to reproduce this:

% sw_vers
ProductName:		macOS
ProductVersion:		26.5.2
BuildVersion:		25F84

% container network inspect isolated-test
[
  {
    "configuration" : {
      "creationDate" : "2026-08-05T05:45:06Z",
      "labels" : {

      },
      "mode" : "hostOnly",
      "name" : "isolated-test",
      "options" : {

      },
      "plugin" : "container-network-vmnet"
    },
    "id" : "isolated-test",
    "status" : {
      "ipv4Gateway" : "192.168.128.1",
      "ipv4Subnet" : "192.168.128.0\/24",
      "ipv6Subnet" : "fd89:da72:8d9f:1799::\/64"
    }
  }
]

% container run --rm --network isolated-test alpine/curl ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UP qlen 1000
    link/ether f2:3d:18:96:59:16 brd ff:ff:ff:ff:ff:ff
3: teql0: <NOARP> mtu 1500 qdisc noop state DOWN qlen 100
    link/void 
4: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
5: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
6: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN qlen 1000
    link/tunnel6 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

% container run --rm --network isolated-test alpine/curl \
  curl -sSk --connect-timeout 8 -o /dev/null -w "http=%{http_code}\n" \
  -H "Host: github.com" https://140.82.121.4/
curl: (28) Connection timed out after 8006 milliseconds
http=000

[am-saksham]

Hi @jglogan, thanks for testing this!

The reason it is timing out for you is likely because your macOS host has IP forwarding disabled (which is the default on macOS).

The original issue reporter noted in the "Root cause" section that their host had net.inet.ip.forwarding: 1. When IP forwarding is enabled on the Mac (which is often flipped on silently by VPNs, Internet Sharing, or other dev tools), the host will NAT and forward the outbound TCP packets from the vmnet interface.

To reproduce the leak on your machine, you can temporarily enable IP forwarding:

# 1. Enable IP forwarding on the host
sudo sysctl -w net.inet.ip.forwarding=1

# 2. Run the test again (it should now return HTTP 200, bypassing the isolation)
container run --rm --network isolated-test alpine/curl \
  curl -sSk --connect-timeout 8 -o /dev/null -w "http=%{http_code}\n" \
  -H "Host: github.com" [https://140.82.121.4/](https://140.82.121.4/)

# 3. Disable it again when done
sudo sysctl -w net.inet.ip.forwarding=0

[jglogan]

I can try out a 25F71 system but that's going to take some time just due to too many things in the queue.

Can you try out a script that the team is using to help gather diagnostic data?

Treat it like a sysdiagnose - don't post the result or anything. If you've got access to a decent AI agent, the idea would be is to create a diagnostic archive, point your agent at it and ask it to look at the script and the packet filter state captures for the subnet corresponding to your host-only network.

One thing that looks funny is that your container interface appears to be on 192.168.250. Typically the host only subnets start at 192.168.128 and go up from there (as you see in my logs).

You should first run the script in dry-run mode to understand what it's grabbing and what it wants sudo for.

./container-diagnostics.sh -h
Usage: /opt/homebrew/libexec/container/distribution/apple-container.app/Contents/Resources/container-diagnostics.sh [-u] [-n] [-h]
  -u    Run in unprivileged mode (skip commands requiring sudo)
  -n    Dry run: print what would be collected without collecting it
  -h    Show this help message

container-diagnostics.sh

[jglogan]

The reason it is timing out for you is likely because your macOS host has IP forwarding disabled (which is the default on macOS).

Ahh, got it. I just drove by this issue so I skimmed it without taking it all in. Thanks!

I'll want to consult with some macOS networking folks on this before rushing to conclusions.

[am-saksham]

Sounds good! Take your time checking with the networking team.

Since the sysctl forwarding state explains why we saw different results, I'll hold off on running the diagnostic script for now. Just let me know if you end up needing those packet filter captures or anything else to help with the review. Happy to help!

[jglogan]

Since the sysctl forwarding state explains why we saw different results, I'll hold off on running the diagnostic script for now. Just let me know if you end up needing those packet filter captures or anything else to help with the review. Happy to help!

Yep, no need to run it. I'll try your repro tomorrow and chat one of our macOS networking folks up. In any case, you now have a shiny new diagnostic script! Thanks for the writeup and the repro procedure.