[Bug]: Networking issue.

[metacritical]

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

Create a container network and change the ips, if you are on home router just restart router and the new dynamic ip assigned will break networking.

Problem description

OK So apple containers have a huge problem, the internal networking of containers handout ips, because it has no internal dns service to resolve containers address using names or host name, this is a huge problem, i spent a day debugging this since yesterday. Now realising the issue is not in the code but the apple container's which used wifi connection to hand out ips to the containers, when the network changed it stopped working. i tried rebuilding multiple times but nothing happened, eventually a mac restart solved it. There should be some kind of dns system for proper networking.

Environment

- OS: 
- Xcode: 
- Container:

Code of Conduct

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

[drewbroadley]

I have also faced this issue, on 1.1.0 - here's a summary of my issue:

Corroborating report: container → internet egress dies after a host IP change (only a reboot restores it)

Reproduced on a headless Apple-silicon Mac used as a deploy box — a strong repro of "a host network change breaks container networking and only a full reboot fixes it," with measurements in case they help isolate the cause.

Environment

container	1.1.0 (release)
macOS	26 (Tahoe), Apple silicon (arm64)
Host network	DHCP LAN, en0 → gateway 10.44.5.1
Default container network	mode: nat, plugin container-network-vmnet, 192.168.65.0/24, gateway 192.168.65.1

Symptom

Every container abruptly lost outbound internet, while container → host and host → internet both kept working:

• Container → external IPv4 (142.250.195.238:443): socket.connect_ex → 11 (timeout — SYN leaves, nothing returns)
• Container → external IPv6: [Errno 101] Network unreachable (ENETUNREACH)
• Container → host gateway & published ports (192.168.65.1:*): OK
• Host → the same external hosts: OK (curl → 302)

DNS itself was fine (the container resolver forwarded external names and returned A/AAAA records); only the packet path to the internet was dead.

Trigger — a host DHCP lease change after the network was created

This is the key correlation:

• container network inspect default → "creationDate": "2026-07-23T00:00:08Z"
• ipconfig getsummary en0 → LeaseStartTime : 2026-07-23 10:04:31

Egress worked from 00:00 until the 10:04 DHCP lease renewal, then died. The host adapted to the new lease (its own traffic stayed fine); the container NAT did not.

Ruled out (all still healthy while egress was dead)

• net.inet.ip.forwarding = 1, net.inet6.ip6.forwarding = 1
• bridge101 up, 192.168.65.1/24, all vmenet* members present
• container network inspect default still reported "mode": "nat"
• Not the macOS Application Firewall (container → host worked; no pending approval prompt)

What did NOT fix it vs. what did

• ❌ container system restart / recreating containers — no change (matches the original report)
• ✅ Full macOS reboot — egress restored immediately (connect_ex → 0)

Hypothesis / request

The container-network-vmnet NAT appears to bind to the host's primary-interface network state at network-creation time and never re-binds when the host IP/lease changes, so it silently blackholes container egress until the stack is fully recreated (in practice, only on reboot).

Could the runtime either (a) re-derive/rebind the vmnet NAT when the host's primary interface/IP changes, or (b) expose a container system network reload (or make container system restart actually rebuild the vmnet NAT) so recovery doesn't require a reboot? A DHCP reservation / static IP avoids the trigger, but that's a workaround, not a fix.

Repro / diagnostics used

# from inside any container — external egress (11 or ENETUNREACH = broken, 0 = ok):
container exec <c> python3 -c 'import socket; s=socket.socket(); s.settimeout(6); print(s.connect_ex(("142.250.195.238",443)))'

# host side works fine:
curl -s -o /dev/null -w '%{http_code}\n' https://<external-host>/

# everything that still LOOKED healthy while egress was dead:
container network inspect default     # "mode": "nat"
sysctl net.inet.ip.forwarding         # 1
ifconfig bridge101                    # up, inet 192.168.65.1
ipconfig getsummary en0 | grep Lease  # lease renewed AFTER the network creationDate