How does Podman work with the different firewall providers? I can't access a web server migrated from Docker.

[FishyBusinessYT]

I'll provide any and all necessary info, so please let me know if I'm missing anything.

I found the following issues which may be related (?):

• Internet connectivity doesn't work on rootful podman and default bridge network #25072 | I'm on Linux though, but this comment states that there may be some conflicting firewall rules when migrating from Docker. Still, I stopped every container and uninstalled the Docker package before even installing Podman, so it may be irrelevant. Worth noting.
• podman differs with docker in ipv6 functionality (port forwarding on ::1 as root) #14491
• Support publishing ports on specific network interfaces #14425

Here's the Compose.yml file for the container:

services:
  pihole:
    container_name: pihole
    image: docker.io/pihole/pihole:latest
    ports:
      # Serve DNS on all 3 interfaces
      - "192.168.68.100:53:53/tcp"
      - "192.168.68.100:53:53/udp"
      - "127.0.0.1:53:53/tcp"
      - "127.0.0.1:53:53/udp"
      - "[200:f86e:ed65:d1e9:47e0:d308:f265:869b]:53:53/tcp"
      - "[200:f86e:ed65:d1e9:47e0:d308:f265:869b]:53:53/udp"
      # Serve webpage over local network and yggdrasil
      - "192.168.68.100:80:80/tcp"
      - "192.168.68.100:443:443/tcp"
      - "[200:f86e:eb65:d1e9:47e0:d308:f265:869b]:80:80/tcp"
      - "[200:f86e:eb65:d1e9:47e0:d308:f265:869b]:443:443/tcp"
    environment:
      TZ: 'America/Argentina/Mendoza' # Timezone
      # DNS addresses:
      FTLCONF_dns_upstreams: |-
        1.1.1.1
        1.0.0.1
    volumes:
      - './etc-pihole:/etc/pihole' # Pi-hole's databases and common configuration file
      - './etc-dnsmasq.d:/etc/dnsmasq.d' # Make DNS settings persistent
    restart: unless-stopped
    networks:
      - pihole
networks:
  pihole:
    name: pihole

The web page (only thing I've thoroughly tested) is not accessible at all, not even from the host machine, and I'm stumped. I've checked:

• The container is running in rootful mode
• Firewall allows traffic (Note: I'm using UFW, not sure if it plays well with Podman or not)
• I can connect to the host via SSH, so it's not a connection issue.
• curl -v localhost, ran from the host machine, fails with the following output:

 Host localhost:80 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:80...
* connect to ::1 port 80 from ::1 port 54992 failed: Connection refused
*   Trying 127.0.0.1:80...
* connect to 127.0.0.1 port 80 from 127.0.0.1 port 34310 failed: Connection refused
* Failed to connect to localhost:80 after 0 ms: Could not connect to server
* closing connection #0
curl: (7) Failed to connect to localhost:80 after 0 ms: Could not connect to server

• nmap ran from my machine outputs the following:

Starting Nmap 7.991 ( https://nmap.org ) at 2026-09-23 08:00 -0300
Initiating Ping Scan at 08:00
Scanning 200:f86e:ed65:d1e9:47e0:d308:f265:869b [2 ports]
Completed Ping Scan at 08:00, 0.41s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 08:00
Completed Parallel DNS resolution of 1 host. at 08:00, 0.00s elapsed
Initiating Connect Scan at 08:00
Scanning (200:f86e:ed65:d1e9:47e0:d308:f265:869b) [201 ports]
Completed Connect Scan at 08:00, 11.44s elapsed (201 total ports)
Nmap scan report for (200:f86e:ed65:d1e9:47e0:d308:f265:869b)
Host is up (0.28s latency).
Not shown: 199 filtered tcp ports (no-response)
PORT   STATE  SERVICE
53/tcp closed domain
80/tcp closed http

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 11.87 seconds

Everything 'just works' if I just use Docker, which I'm trying to move away from.

My working theory is that there's some issue with the way Podman handles firewalls and the way I set up the service here, but as I said before, I'm stumped.

Thanks for taking the time to read this over, I really appreciate it.

[FishyBusinessYT]

Okay, I'm making some edits because looking back, I wrote this in a frustrated stupor. I believe I may have some new information (edit: Done, I can also append the output of nft list ruleset, but it was a little too extensive.)

[jmrplens]

Your own nmap output is the most useful thing in the report, and it says the container is not listening on that address at all.

On rootful podman, a published port is a real listening socket that podman opens and holds on the host while the container runs. If the container were up and publishing 53 on 200:f86e:ed65:d1e9:47e0:d308:f265:869b, nmap would have reported that port as open. It reported closed, which is a RST from the kernel, while the other 199 ports came back filtered, which is UFW dropping them. So the firewall is letting 53 and 80 through and there is nothing behind them: this is not a firewall problem.

Two things in the compose file explain it.

The two yggdrasil addresses are not the same address. The DNS ports use 200:f86e:ed65:d1e9:... and the web ports use 200:f86e:eb65:d1e9:..., ed65 against eb65. If the host does not hold the one you publish on, the container never starts: on podman 5.8.7 I get

Error: cannot listen on the TCP port: listen tcp6 [fd00:dead:beef::1]:8081: bind: cannot assign requested address

and the container stays in Created instead of reaching Up. So podman ps -a (not podman ps) and podman logs pihole are the first two commands to run, then podman port pihole and ss -ltnp | grep -E ':(53|80|443)' to see what it really bound.

And curl localhost cannot work with that file even when everything else is right: publishing on a specific address binds only that address, and port 80 is published on 192.168.68.100 and the yggdrasil address only, never on 127.0.0.1 (the DNS ports do have a 127.0.0.1 entry, which is why they behave differently). I checked the semantics on the same version: a container published on one host IP answers on that IP and gives no connection at all on 127.0.0.1 or localhost, with a single listening socket in /proc/net/tcp. Use curl http://192.168.68.100/ from the host.

One more thing for when it does start: the pihole network in your compose has no IPv6, so publishing on an IPv6 address will not forward into the container. Add enable_ipv6: true to that network.

About UFW in general, since that was the theory: the friction with podman is the opposite of what you are seeing. netavark installs its own firewall rules (iptables or nftables, depending on how your podman was built and on firewall_driver in containers.conf), and those rules are invisible to UFW, so the usual complaint is that published ports are reachable when the admin expected UFW to be blocking them.

[FishyBusinessYT]

Yeah, sorry... I just wanted to obscure my IP address when I realized I'd leaked it like a dummy. Nevermind, though, as I already changed it and reflected those changes in the compose file.

I had tried to enable_ipv6, and it didn't work, but after trying again, I'm seeing good results on the server? That's confusing. Probably made a typo the first time.

Remotely, however, the results are very interesting:
Container running + nmap -6 [IP] -p 0-200 -v:

Starting Nmap 7.991 ( https://nmap.org ) at 2026-09-24 11:28 -0300
Initiating Ping Scan at 11:28
Scanning [IP] [2 ports]
Completed Ping Scan at 11:28, 3.00s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 0 hosts. at 11:28
Completed Parallel DNS resolution of 0 hosts. at 11:28, 0.00s elapsed
Nmap scan report for [IP] [host down]
Read data files from: /usr/bin/../share/nmap
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.01 seconds

Container running + nmap -6 [IP] -p 0-200 -v -Pn:

Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times may be slower.
Starting Nmap 7.991 ( https://nmap.org ) at 2026-09-24 11:30 -0300
Initiating Parallel DNS resolution of 1 host. at 11:30
Completed Parallel DNS resolution of 1 host. at 11:30, 0.00s elapsed
Initiating Connect Scan at 11:30
Scanning [IP] [201 ports]
Completed Connect Scan at 11:31, 43.02s elapsed (201 total ports)
Nmap scan report for [IP]
Host is up.
All 201 scanned ports on [IP] are in ignored states.
Not shown: 201 filtered tcp ports (no-response)

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 43.04 seconds

Container stopped + nmap -6 [IP] -p 0-200 -v:

Starting Nmap 7.991 ( https://nmap.org ) at 2026-09-24 11:34 -0300
Initiating Ping Scan at 11:34
Scanning [IP] [2 ports]
Completed Ping Scan at 11:34, 0.35s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 11:34
Completed Parallel DNS resolution of 1 host. at 11:34, 0.00s elapsed
Initiating Connect Scan at 11:34
Scanning [IP] [201 ports]
Completed Connect Scan at 11:34, 9.36s elapsed (201 total ports)
Nmap scan report for [IP]
Host is up (0.28s latency).
Not shown: 199 filtered tcp ports (no-response)
PORT   STATE  SERVICE
53/tcp closed domain
80/tcp closed http

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 9.72 seconds

Container running + nmap -6 [IP] -p 0-200 -v, ran on the server:

Starting Nmap 7.991 ( https://nmap.org ) at 2026-09-24 13:06 -0300
Initiating Ping Scan at 13:06
Scanning [IP] [2 ports]
Completed Ping Scan at 13:06, 0.00s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 13:06
Completed Parallel DNS resolution of 1 host. at 13:06, 1.00s elapsed
Initiating Connect Scan at 13:06
Scanning [IP] [201 ports]
Discovered open port 53/tcp on [IP]
Discovered open port 80/tcp on [IP]
Completed Connect Scan at 13:06, 0.01s elapsed (201 total ports)
Nmap scan report for [IP]
Host is up (0.00013s latency).
Not shown: 199 closed tcp ports (conn-refused)
PORT   STATE SERVICE
53/tcp open  domain
80/tcp open  http

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 1.04 seconds

Now, the weird thing is that when the container is running, ALL ports, even unrelated ones I publish for other services (SSH, non-standard port, for example) show up as filtered from my own machine. Still, the SSH connection from where I'm testing all of this is never cut.

Also, podman port pihole shows all published ports as expected, I didn't find anything noteworthy when running podman logs pihole, either, and ss -ltnp only showed port 53 being bound to both IP addresses of the podman network interface. Ports 80 and 443 nowhere to be found. Finally, curl http://192.168.68.100 did return a web page. I'm so confused...

[jmrplens]

Those scans pin it down, and they also show I had the UFW part of my first reply backwards. It is UFW, just not on the path you allowed.

With the container stopped, a SYN to port 80 reaches the host itself, UFW's 80/tcp allow lets it into INPUT, nothing listens there, and the kernel answers with a RST: closed. With the container running, podman rewrites that SYN to the container's address before routing, so it no longer goes to INPUT at all. It goes through FORWARD, and UFW's default for forwarded traffic is deny (routed) (DEFAULT_FORWARD_POLICY="DROP" in /etc/default/ufw), which drops it silently: filtered. Your ufw allow rules only apply to INPUT, so they never see it. From the server itself the connection leaves through OUTPUT and never crosses FORWARD, which is why nmap on the server and curl http://192.168.68.100 both work.

The rest of the output follows from that. nmap's host discovery, when it does not run as root, is a connect to ports 80 and 443, the two you publish, so once both are dropped it reports the host as down. With -Pn, the other 199 ports were already filtered with the container stopped; the only change between your two runs is 53 and 80 going from closed to filtered.

Netavark's own accept rules do not save you here. With the nftables driver they live in their own inet netavark table, and an accept in one table does not stop another table from dropping the same packet at the same hook. With the iptables driver, NETAVARK_FORWARD only accepts established traffic to the container network, so a new connection falls through to UFW's policy. Docker adds an explicit ACCEPT for every published port in the FORWARD chain, which is why the same compose file worked there.

The fix is a route rule per published port. The rule sees the packet after the rewrite, so it matches the container network and the container port, not the host address:

podman network inspect pihole --format '{{range .Subnets}}{{.Subnet}} {{end}}'

sudo ufw route allow proto tcp to <ipv4-subnet> port 80
sudo ufw route allow proto tcp to <ipv4-subnet> port 443
sudo ufw route allow proto tcp to <ipv4-subnet> port 53
sudo ufw route allow proto udp to <ipv4-subnet> port 53

and the same four with the IPv6 subnet. Any other port you publish through podman takes the same path and needs the same kind of rule. If the network is ever recreated it can get a different subnet, so it is worth pinning one under ipam in the compose file.

I reproduced it on Debian 13 (podman 5.4.2, netavark 1.14.0, ufw 0.36.2) with nginx published on one IPv4 and one IPv6 host address and a second machine scanning. Before the route rules: filtered from the other machine while running, closed while stopped, a 200 from the host itself, and the drops counted on UFW's FORWARD policy. After them: open and a 200 from the other machine on both families. Same result with firewall_driver = "iptables".

About ss: the port 53 sockets on the two addresses of the podman interface are aardvark-dns, podman's DNS server for that network, not Pi-hole. The published ports show up as held by conmon in sudo ss -ltnp.

[FishyBusinessYT]

Hey! Sorry for the late reply. It actually worked! Thank you very much for your help.

I actually forgot to write back because I've been trying to specify a from address to the route rules.
First I tried my own machine's IP address, after which I was locked out. Then, I figured maybe there's some NATing going on in the middle, so I've been trying to figure out (using tcpdump) to what address my machine's IP is being translated into.

Edit: tcpdump reads the packets as coming from my own machine's IP address. Now I have no idea why UFW drops them.

This is all in favor of a little extra security, so I guess the actual questions would be:

• Is this achievable?
• If so, is it worth doing? By this I actually mean to ask if the measure would make any impact given my current setup (I haven't deleted the previous rules).
• And if so, how can I know for sure what IP to filter for so that the behavior is as expected?

As always, thank you very much for taking the time to help me out. I sincerely appreciate it.

[jmrplens]

Glad it works! Yes, it is achievable, and for the Yggdrasil side I think it is worth it.

Achievable. The rewrite only changes the destination, so your machine's address stays the source all the way to the container. I checked it with tcpdump on a test host: the SYN arrives on eth0 as client > host:80 and leaves on the podman bridge as client > container:80, same source. So from is your machine's address, and to stays the container network:

sudo ufw route allow proto tcp from <your-machine-ipv4> to <ipv4-subnet> port 80
sudo ufw route allow proto tcp from <your-machine-yggdrasil-address> to <ipv6-subnet> port 80

In that lab, with only those rules, the allowed client got a 200 on both families and a second client was dropped.

Why it went wrong. In the lab, each of these broke it:

• to set to the host address instead of the container network. By the time the packet reaches FORWARD its destination is already the container's, so that rule never matches and you are locked out.
• The wrong family. A connection to the server's Yggdrasil address comes from your machine's Yggdrasil address, not from its LAN IPv4, so an IPv4 from does not cover it. You need one rule per family; ufw refuses to mix them in one (ERROR: Mixed IP versions for 'from' and 'to').
• The old rules still in place. UFW takes the first rule that matches, so while the rules without from are there, the new ones change nothing: both clients got in until I deleted them (sudo ufw status numbered, then sudo ufw delete <n>).

How to know which IP. Let UFW tell you: sudo ufw logging on, try to connect, then sudo journalctl -k | grep 'UFW BLOCK'. A drop in FORWARD shows OUT= with the podman bridge, SRC= with the address to put in from, and DST= with the container address it was already rewritten to.

Is it worth it. For DNS on port 53, only if you want to limit who can use the resolver: every device that uses Pi-hole needs to reach it, so a single from would break DNS for the rest of your network. For the Yggdrasil address it matters most. Yggdrasil's FAQ answers "Will my machine be exposed to other users of the network?" with "Typically yes, you will be routable from other nodes on the network", so with ports published on that address, the Pi-hole admin page and the resolver are reachable by any node on the Yggdrasil network, not just yours. Either restrict those rules to your own machines' Yggdrasil addresses, or don't publish on the Yggdrasil address at all if you only use Pi-hole from your LAN.

[FishyBusinessYT]

So, it turns out I accidentally specified the HTTP ports as part of the from clause, so that meant all incoming connections (which have ephemeral ports assigned) were being dropped. Rearranging the arguments got it fixed.

Thank you very much for your time.