[Bug]: Host cannot reach container IPs (No route to host) and published ports reset connections on fresh 1.0.0 install

[JasonVranek]

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

Steps to reproduce

container system start
container run -d --name nettest -p 8080:80 docker.io/library/nginx:alpine
curl -v http://127.0.0.1:8080
IP=$(container ls | awk '/nettest/ {print $6}' | cut -d/ -f1)
curl -v http://$IP:80
sudo tcpdump -ni bridge100 "arp or host $IP"

Problem description

Observed:

• Inside container, nginx returns HTTP 200 on 127.0.0.1:80.
• Container can ping host gateway 192.168.64.1.
• Host direct curl/ping to container IP fails immediately with “No route to host.”
• tcpdump on bridge100 captures 0 ARP/ICMP packets from the host.
• Published port 127.0.0.1:8080 accepts TCP, then resets before returning HTTP.

Expected:

• Host can reach published port.
• Ideally host can also reach container IP or at least ARP correctly on bridge100.

Environment

- OS: macOS 26.3.1
- Xcode: Not installed; Command Line Tools only, version 26.2.0.0.1.1764812424
- Container: container CLI version 1.0.0 (build: release, commit: ee848e3)

Code of Conduct

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

[XuanLee-HEALER]

Cannot reproduce on a slightly newer revision — looks like #1686 may have eliminated the published-port symptom

I tried to reproduce this on the same main branch but a few commits ahead of your build, and I cannot reproduce either symptom. Sharing the data in case it helps narrow down the root cause.

Environment

• macOS 26.4.1 (Build 25E253), Apple Silicon
• Xcode 26 (full install)
• container CLI version 1.0.0-4-gc8b4fd7 (build: release, commit: c8b4fd7) — 4 commits ahead of your ee848e3, notably including Always update default network with system configuration values #1686 ("Always update default network with system configuration values") which fixed [Bug]: TOML network subnet setting not applied to VM #1677
• Fresh install: no pre-existing ~/Library/Application Support/com.apple.container/ from any older version
• No ~/.config/container/config.toml overrides; default subnet 192.168.64.0/24

Result of your exact reproduction steps

Step	Your report	My result
curl -v http://127.0.0.1:8080 (published port)	TCP accepted, then RST before HTTP	HTTP 200, full nginx response
curl -v http://192.168.64.2:80 (direct container IP)	Immediate "No route to host"	HTTP 200, ~2.5 ms, stable across repeats
ping 192.168.64.2	n/a (didn't show in your repro)	3/3 packets received, ~0.5 ms avg
Host ARP table	n/a	192.168.64.2 at f6:db:99:a1:59:3c on bridge100 — populated

Interesting observation about tcpdump -ni bridge100

When I curl the container IP from the host while tcpdump is running on bridge100, the curl succeeds (HTTP 200) but bridge100 shows no host-originated packets — only the guest's own ARP requests (who-has 192.168.64.1 tell 192.168.64.2). My read of this is that vmnet shared mode delivers host→VM traffic through an internal path that doesn't traverse the bridge100 interface from the sniffing side, so "tcpdump on bridge100 sees 0 host packets" is not necessarily evidence that the host failed to send — at least on a working configuration. The 0-packet observation in your report may be consistent with both "host packets never left" and "host packets bypassed bridge100 internally"; on my box it's clearly the latter, since the request actually completed end-to-end.

Transient "No route to host" right after container start

I did see a single "No route to host" on the very first ping/curl immediately after the container booted, before the guest had ARPed for the gateway. Within a few seconds (after the guest sent its who-has 192.168.64.1 broadcast and the host populated its ARP cache for 192.168.64.2), the same commands started succeeding and have stayed reliable. This makes me wonder if part of your symptom is a stuck/unresolved ARP state rather than a routing-table problem.

Two hypotheses for your environment

1. Stale default-network state from before a prior container install. This is what [Bug]: TOML network subnet setting not applied to VM #1677 / Always update default network with system configuration values #1686 are about — a persisted "default" network configuration could shadow the values the apiserver tries to apply on boot, leaving vmnet attached with the wrong subnet / gateway. Always update default network with system configuration values #1686 force-overwrites the persisted default-network record at startup, which would also fix any downstream forwarders relying on a consistent attachment. Could you try the workaround the [Bug]: TOML network subnet setting not applied to VM #1677 thread mentions (stop services, remove ~/Library/Application Support/com.apple.container/, restart) and re-test on your existing ee848e3 build? If the published-port path comes alive after that, this issue is plausibly already fixed by Always update default network with system configuration values #1686 on main.

2. macOS 26.3.1 vmnet behavior. I'm on 26.4.1; you're on 26.3.1. I cannot rule out a point-release vmnet fix between those two builds. If hypothesis 1 doesn't pan out, a softwareupdate to the latest 26.x might be informative.

Happy to provide raw tcpdump pcaps, container system property list, or the container system logs -f output from my repro attempt if useful.