running a DNS forwarder/resolver with pasta / publish port 53/udp with pasta

[HassoSigbjoernson]

I am currently trying to switch my containers from using slirp4netns to pasta and can't get pihole to work properly.

Currently I'm testing this on my Silverblue system, using Podman 5.0.1:

podman run -d --network=pasta:-I,eth0 -p 8080:80 -p 5003:53/tcp -p 5003:53/udp -e WEBPASSWORD=password pihole/pihole

Pihole seems to to run fine but its answers appear to get lost on the way back out of the container when using udp and not localhost.

inside the container:
dig google.com @127.0.0.1 works
dig google.com @192.168.2.115 works

outside the container:
dig -p 5003 google.com @127.0.0.1 works
dig -p 5003 google.com @192.168.2.115 times out
dig +tcp -p 5003 google.com @192.168.2.115 works

I can see the timed out requests in the pihole query log, so they appear to reach pihole and disappear after that.

Is this some kind of shortcoming of pasta, compared to slirp4netns, because of how it's DNS works, or possibly a bug? Are there any podman/pasta options to get this working?

[Luap99]

What pasta version are you using?

[HassoSigbjoernson]

pasta 0^20240326.g4988e2b-1.fc40.x86_64

[Luap99]

@sbrivio-rh @dgibson ideas?

[sbrivio-rh]

I think it's a bug that @dgibson just happened to fix yesterday: https://bugs.passt.top/show_bug.cgi?id=87 -- the use case reported there looks exactly the same, with pihole running in a container for DNS resolution.

I'll report back here once the changed is merged and released.

[sbrivio-rh]

Hm, what part doesn't work now? What is 192.168.2.115 in your setup? Would you mind sharing a packet capture taken by passing --pcap / -p to pasta (-p,/tmp/pihole.pcap or suchlike)?

[HassoSigbjoernson]

192.168.2.115 is the IP of the machine running the container. And I have now determinded that --map-gw is only necessary if the query is coming from this machine and addressed to this IP. Sending the query from another machine to this IP works without --map-gw .

I can do the packet capture later.

[HassoSigbjoernson]

Better late than never. The packet capture: [expired]
Password: [expired]

[dgibson]

Ah, ok. That is unrelated, and not really fixable. When the origin and the guest have the same IP, there's simply no way to have traffic between them - other than remapping something, which is what --map-gw does. We hope to make the remapping options more flexible, but we'll always need something in order for this specific case to work. This is the fundamental tradeoff we make for avoiding NAT in most cases.

[HassoSigbjoernson]

OK, thanks. Being able to send queries from a different IP is all I really needed and the patch enabled that. So the current state is good enough for me.
I just wondered because the same command, to and from the same IP, works when adding +tcp. So UDP just behaves differently in that regard?

[dgibson]

I concur, this looks exactly like bug 87.

[MrSSvard]

Hi! Were you able to work around this bug? The fix doesn't seem to have been merged in pasta yet.

[dgibson]

Hi! Were you able to work around this bug? The fix doesn't seem to have been merged in pasta yet.

The fix for bug 87 was merged quite some time ago, and is even now obsoleted by the implementation of the flow table which fixes this in a more natural and robust way.

What pasta version are you using? If it's something current, and you're still seeing problems like this, I think it probably has an unrelated cause.

[sbrivio-rh]

The fix doesn't seem to have been merged in pasta yet.

The fix was merged a while ago: https://passt.top/passt/commit/?id=0804fdbc28418883f479fde1beb24c620087fe17 (see also https://bugs.passt.top/show_bug.cgi?id=87), and the first upstream release including this is 2024_04_26.d03c4e2.

What version are you running? What issue are you having, exactly?

[HassoSigbjoernson]

I can confirm that. I'm running Fedora 40 / passt-0^20240821.g1d6142f-1.fc40.x86_64 and everything seems to work.

[MrSSvard]

After some testing, it's a different issue I have so I'll create a new discussion to keep things cleaner. Thanks for the quick response!