NAT port 53 to podman port loses client IP address


I'm running pi-hole using podman as a non-root user so I've mapped port 53001 on the Pi to the
pi-hole container's port 53.

I've then added the following iptables rule:

iptables -t nat -A PREROUTING -p udp --dport 53 \
        --source -j DNAT --to-destination

This works great except all of the clients are logged as 'localhost' and if I look in the pihole log all DNS requests show as the client.

Oct 16 09:43:20 dnsmasq[718]: query[AAAA] from

After some research I've tried adding:

iptables -t nat -A POSTROUTING -p udp --destination --dport 53001 -j SNAT --to-source

iptables -t nat -A POSTROUTING -j MASQUERADE

But nothing seems to be able to show the original 192.168.2.XXX ip address on the pihole.

Is this possible? Could it because the client is on a different subnet ?



You can try the POSTROUTING chain instead but I don't think you'll find a real solution. NAT is designed to change the IP address, that's just how it works.

Thanks Dan. Good to know that it can't be solved with NAT.

Its more important to me that ad domains are being blocked rather than knowing which client made the request anyway.

Dan is right, your later attempts using MASQUERADE would for sure replace the source IP with your device's outbound IP.

But your first statement using DNAT should have worked, since that is solely using a destination NAT, i.e. it would only replace a packet's destination address.

If you are seeing the source address being replaced as well, this would strongly suggest there are other SNAT or MASQUERADE rules present in the rule chain, replacing the source IP as well.

If I had to guess, I'd suspect that Podman (just like Docker) would apply its own set of iptables rules (maybe even inside a container instance?). I don't know Podman, but Docker would e.g. masquerade packets for it's default bridge network.

You could try to experiment with Podman's network modes, assuming Podman is similar to Docker in that regard.

However, your best approach may be consulting Podman's documentation or reaching out to their support to find out whether there would be a way around this.

Even using DNAT mangles the packet. Something keeps record of where the packet originally intended to go, rewrites to where you want to go and then does the opposite with the response (takes the response with the source of the rewritten destination and puts back the original destination). That process changes some of the IP header data and dnsmasq can see that. (Going from memory, @DL6ER would have a definitive answer about how pihole-FTL treats header information.) The packets are getting from client to Pi-hole and back to client with the right payload so there is some packet manipulation going on that would/could affect.

As for podman, since it running in non-root mode it does not have the capability to affect things on the network level, it just doesn't have the privileges to do that. I think you may be on the right track though, this is something I neglected to consider, non-root mode.

Would be good to get a full dump of the iptables regular and nat tables, all chains to see.

Edit: Added clarification to last sentence in the first paragraph.