Root cause

OVH private network (vRack / ens4) DHCP was injecting a default route at the same metric (100) as the public interface (ens3). For locally-originated traffic this was harmless — the kernel picked ens3 via source-address selection. But for forwarded Docker traffic (172.18.0.0/16), there's no source preference, so the kernel fell back to FIB order and picked ens4 first. The ens4 gateway (10.10.0.1) doesn't actually exist on OVH private networks — ARP resolution failed, the kernel returned EHOSTUNREACH, and every outbound container connection died with No route to host.

• IPv6 unaffected — only one IPv6 default gateway existed (on ens3), no competition.
• Host itself unaffected — source-address selection always preferred ens3 for locally-originated packets.

Fix applied — /etc/netplan/50-cloud-init.yaml

ens4:
  match:
    macaddress: "fa:16:3e:ee:32:6a"
  dhcp4: true
  dhcp4-overrides:
    use-routes: false
    use-dns: false
  set-name: "ens4"
  mtu: 1500

netplan apply

This drops the phantom default route while keeping the 10.10.0.0/24 connected route intact, so private network traffic still works. Container outbound IPv4 restored immediately.

Note for OVH + vRack users — if you run Cloudron with a second interface for private networking, add use-routes: false on that interface. OVH's DHCP silently advertises a default gateway that doesn't route to the internet, which breaks Docker NAT for all containers while leaving the host itself seemingly fine.

Cloudron's iptable rules area all setup in https://git.cloudron.io/platform/box/-/blob/master/setup/start/cloudron-firewall.sh?ref_type=heads

After a full network audit, here's what I found:

• Two default routes coexist at identical metric 100 — one via ens3 (public, 135.125.47.1, healthy) and one via ens4 (OVH private vRack, 10.10.0.1, dead — ARP FAILED, 100% packet loss).
• For locally-originated traffic, the kernel prefers ens3 via source address selection, so the host itself has no issue reaching the internet.
• For forwarded container traffic (from 172.18.0.0/16), there's no source preference, so the kernel picks ens4 first (FIB order) — and the packet dies there.
• Firewall rules are not the issue: DOCKER-FORWARD already accepts traffic from br-c372a117c03f (34K packets counted), MASQUERADE is present and active, rp_filter is set to loose.

My proposed fix is to suppress the default route advertised by ens4's DHCP in Netplan (dhcp4-overrides: use-routes: false), keeping the 10.10.0.0/24 connected route intact for private network access.

Before I apply anything — am I on the right track? And is there anything Cloudron-side that manages iptables or routing that I should be aware of before touching Netplan?

@adm1n said:

Question: Did something change on the Cloudron platform side today (routing, iptables rules, network configuration) that could explain why IPv4 forwarding from containers to external IPs stopped working, while IPv6 remains functional?

If you see no Cloudron update in your recent system backups, no, nothing changed.

Did you try to reboot the server?