Hello all, I did some more investigation. TL;DR: Internal networks should work for my purposes as Keith said (while still being able to resolve container names via DNS), but apparently that doesn't work on my host due to either a bug or unsupported configuration.
For each container that needs to talk to another container, define a network in the `networks:` top-level element with `internal: true` set for it. In each container's entry in the `services:` top-level element, include that network in `networks:`.
When I do that, DNS name resolution stops working: I cannot nslookup <other container> e.g. a database from within a web server container, which is useful for avoiding having to hardcode IPs. Any way to help with that?
The following rules (I copied part of what's present when internal: false) are enough to get DNS working in containers with internal: true: iptables -I INPUT 1 -s 10.89.0.0/24 -d 10.89.0.0/24 -p udp --dport 20053 -j ACCEPT iptables -t nat -I PREROUTING 1 -m addrtype --dst-type LOCAL -p udp -d 10.89.0.0/24 --dport 53 -j DNAT --to-destination 10.89.0.1:20053 iptables -t nat -I OUTPUT 1 -m addrtype --dst-type LOCAL -p udp -d 10.89.0.0/24 --dport 53 -j DNAT --to-destination 10.89.0.1:20053 Container-to-container networking (directly via their IP) was already working even without these rules - they only affect DNS resolution. On my machine I set the dns_bind_port to 20053 in /etc/containers/containers.conf (because a DNS resolver is already listening on port 53 on the host and prevents aardvark-dns from running on the default port), but it turns out that: * My default policy for the INPUT and FORWARD iptables chains is DROP, managed by ufw, which blocks access to the resolver. The first rule lets containers contact the resolver at the non-standard 20053 port, but not 53 (because it's not actually listening at that port). * The last 2 rules redirect regular port 53 DNS requests from inside containers to the resolver listening at port 20053, making DNS finally work. I don't know why they're missing with internal: true. I looked at [0] in detail and it does not mention anything to explain these two gotchas. Is there any chance they could be added in the documentation/FAQ, and is [0] the best place for it? Or is it something that could be fixed/improved in Podman itself? In the second bullet point in particular a non-default DNS port is simply not working at all in an internal network because the DNAT rule is missing. In the first point I feel that Podman/netavark should cooperate with (or at least warn about connectivity issues potentially caused by) existing firewall rules and default chain policies, but I would understand that supporting all possible (mis-)configurations would be a daunting task! Thanks a lot for your insights, François-Xavier --- [0] https://github.com/containers/podman/blob/main/docs/tutorials/basic_networki...