Replies: 2 comments 5 replies
-
SummaryI can observe something Similar (Fedora 40 with all Updates installed as of Today). But I CANNOT / DO NOT ALWAYS observe EXACTLY the same behavior. I have the issue in both cases to be honest ... Using Loopback Address on the Podman Host:
Using the "wrong" IP Address that is NOT registered in Container's
Using the "right" IP Address that IS registered registered in Container's
Using VolumesI tried only using Funnily enough TCP works in my case using Host Address (192.168.8.13). Another Note: for whatever reason the Podman Host (Virtual Machine) is getting 2 IPv4 Addresses (1 Static, 1 via DHCP). 192.168.8.13 (Static) and 192.168.13.161 (DHCP). For poking around I did a NOTE that only ONE IP address is pointing to the Container ! Indeed now both UDP and TCP work, if I use the right IP: Using Bind MountsI tried with both Or The Now I try the same Inspection of /etc/hosts from within the container: And doing the |
Beta Was this translation helpful? Give feedback.
-
|
Does your VM have multiple interfaces? I suppose podman is handling them differently. and its /etc/resolv.conf |
Beta Was this translation helpful? Give feedback.
-
|
Not intentionally but yeah, between I also had IPv6 Addresses in the Container. I was about to post about inspecting the Differences on That's probably some difference I introduced myself (I cannot let pihole do the default of In the past there was a bug on Pasta/Passt that @sbrivio-rh helped to Troubleshoot (IPv6 with Local Addresses IIRC), but another thing was that I had an (IPv6) misconfiguration on my main DNS Server which did NOT allow Queries because the Container was in another Subnet from what the BIND Nameserver allowed Queries from. Probably not your case though since you use a Bridge though. As I mentioned to @sbrivio-rh in IRC, it also seems that on 20240906 for Fedora a new Aardvarkdns and Pasta/Passt were released. The
Could be interesting to see if previous versions didn't show this Issue. OR, from within the Container, try if all things work in all directions: last Time I had Issues with OUTBOUND connection, so maybe try I had a quick look at your Packet Capture but I am not an Expert. There seemed to be some DNS Query & DNS Query Answer Messages which I guess are good, but also some out-of-order Packets related to TCP Connections (RST Flag I believe). You'll have to wait until somebody more experienced has a look at it. Was this the Packet capture with the working or the non-working Config ? Maybe clarify that in the Message where you attached the link to the File. EDIT 1: You could also simply try an |
Beta Was this translation helpful? Give feedback.
-
|
@MrSSvard could you capture some traffic so that we can understand where those DNS queries end up? There are basically two ways:
If you don't want to share the resulting captures because they contain confidential details, you can use |
Beta Was this translation helpful? Give feedback.
-
|
Absolutely, it's just a throwaway container anyways. The MAC address of my interface is 0c:9d:92:c2:c2:16 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, I downloaded it, I'll have a look soon. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the delay, I finally managed to have a look. Weird, the capture shows the TCP query (I'm checking that one as it's a bit simpler to follow in captures than UDP) in frame #1128, and pasta closes the connection before an answer is sent (frames #1130, #1131). Ignore the out-of-order segment, #1127 and #1128 are swapped (we just found this a while ago and we'll fix that in a bit): the kernel copes with that. I guess I'll have to reproduce it. It's really not clear why pasta would reset the connection. Maybe this comes from the resolver in the container, I'm not sure. |
Beta Was this translation helpful? Give feedback.
-
Hi!
I have a weird behavior that I'm trying to figure out.
I'm setting up Pihole in rootless podman but I'm having issues with timeouts and other errors with exposing ports while using bind mounted folders.
Connecting via the loopback address works fine for both tcp and udp but connecting via the host address (e.g. 192.168.1.53) either from the same machine or from another computer, I get a timeout on udp and an error over tcp.
Both work fine with regular volume though.
Steps to reproduce:
Working setup with regular volumes
podman run --rm -e WEBPASSWORD=123 -p 8153:53/tcp -p 8153:53/udp -p 8180:80 -v etc:/etc/pihole/:Z -v masq:/etc/dnsmasq.d/:Z docker.io/pihole/pihole:latestdig @127.0.0.1 -p 8153 google.com# works finedig @127.0.0.1 -p 8153 +tcp google.com# works finedig @192.168.1.53 -p 8153 google.com# works finedig @192.168.1.53 -p 8153 +tcp google.com# works fineNon-working setup with bind mounted volumes
mkdir -p ~/volumes/pihole-etc ~/volumes/pihole-etc-dnsmasq.dpodman run --rm -e WEBPASSWORD=123 -p 8153:53/tcp -p 8153:53/udp -p 8180:80 -v ~/volumes/pihole-etc/:/etc/pihole/:Z -v ~/volumes/pihole-etc-dnsmasq.d/:/etc/dnsmasq.d/:Z docker.io/pihole/pihole:latestdig @127.0.0.1 -p 8153 google.com# works finedig @127.0.0.1 -p 8153 +tcp google.com# works finedig @192.168.1.53 -p 8153 google.com# communications error to 192.168.1.53#8153: timed outdig @192.168.1.53 -p 8153 +tcp google.com# communications error to 192.168.1.53#8153: end of fileFiles are created in both volume types and they look fine.
About my system:
Fedora Silverblue 40
podman-5.2.2-1.fc40.x86_64
passt-0^20240906.g6b38f07-1.fc40.x86_64
I have stopped firewalld
I ran
setenforce 0I also confirmed the issue on a separate system:
Fedora IoT 40
podman-5.2.2-1.fc40.x86_64
passt-0^20240906.g6b38f07-1.fc40.x86_64
Am I misunderstanding something or doing something incorrectly?
If it were a misconfiguration of pihole, I think it would have failed on the loopback interface too.
Any insight is welcome, thanks!
Beta Was this translation helpful? Give feedback.
All reactions