Replies: 2 comments
-
First of all, sorry for the late reply. I just tested this once again and I do not see any such DNS resolving issue here with my default docker compose test environment. In fact, I can perfectly fire up the raspberrymatic docker container and the container is perfectly able to run
In addition, the default
And all this works with the default iptables setup within the container:
So to me this looks like you might have a local misconfiguration in the docker host system which seem to prevent that the container is able to communicate with your local DNS system. Therefore I will move this ticket to the discussion part in case someone else might come up with a similar issue and you might to discuss things accordingl.y |
Beta Was this translation helpful? Give feedback.
-
Hello, no problem at all because of the late feedback, it works for me and so I am satisfied ;) The problem is probably related to the fact that I am running a pihole server for DNS resolution on the same system. If you are interested in the details, here is the pihole configuration:
FTLCONF_LOCAL_IPV4=192.168.145.5
TZ=Europe/Berlin
WEBPASSWORD=MySecretPassword
REV_SERVER=true
REV_SERVER_DOMAIN=fritz.box
REV_SERVER_TARGET=192.168.145.1
REV_SERVER_CIDR=192.168.145.0/24
HOSTNAME=pihole
DOMAIN_NAME=pihole.local
PIHOLE_WEBPORT=80
WEBTHEME=default-dark
services:
pihole:
container_name: pihole
image: cbcrowe/pihole-unbound:latest
hostname: ${HOSTNAME}
domainname: ${DOMAIN_NAME}
ports:
# - 443:443/tcp
- ${FTLCONF_LOCAL_IPV4}:53:53/tcp
- ${FTLCONF_LOCAL_IPV4}:53:53/udp
- ${FTLCONF_LOCAL_IPV4}:${PIHOLE_WEBPORT:-80}:80/tcp #Allows use of different port to access pihole web interface when other docker containers use port 80
# - 5335:5335/tcp # Uncomment to enable unbound access on local server
# - 22/tcp # Uncomment to enable SSH
environment:
- FTLCONF_LOCAL_IPV4=${FTLCONF_LOCAL_IPV4}
# - FTLCONF_REPLY_WHEN_BUSY=DROP
- TZ=${TZ:-UTC}
- WEBPASSWORD=${WEBPASSWORD}
- WEBTHEME=${WEBTHEME:-default-light}
- REV_SERVER=${REV_SERVER:-false}
- REV_SERVER_TARGET=${REV_SERVER_TARGET}
- REV_SERVER_DOMAIN=${REV_SERVER_DOMAIN}
- REV_SERVER_CIDR=${REV_SERVER_CIDR}
- PIHOLE_DNS_=127.0.0.1#5335
- DNSSEC="true"
- DNSMASQ_LISTENING=single
volumes:
- /home/skytale/docker/pihole:/etc/pihole:rw
- etc_pihole_dnsmasq-unbound:/etc/dnsmasq.d:rw
restart: unless-stopped
# dns: # https://github.com/pi-hole/docker-pi-hole/issues/342
# - 127.0.0.1
# - 8.8.8.8
volumes:
etc_pihole_dnsmasq-unbound: |
Beta Was this translation helpful? Give feedback.
-
Describe the issue you are experiencing
Hello everyone,
I have set up a raspberry latest distro with docker + raspberymatic and have problems with DNS resolution within the container.
I have created the container exactly according to the following blueprint: https://github.com/jens-maus/RaspberryMatic/wiki/Installation-Docker-OCI#using-docker-compose
The issue is now, that no DNS resolution is possible from within the container.
journalctl
gives me the following messages cyclically:A CUxD script issuing a query fails and I have a alert inside raspberymatic web interface:
WatchDog: no-internet | ausgelöst | No internet connection detected
Through an
nslookup wdr.de
from inside the container:and
journalctl
:However, if I completely reset the
iptables
within the container:The
nslookup wdr.de
is now working from inside the container:/ # nslookup wdr.de Server: 127.0.0.11 Address: 127.0.0.11:53 Non-authoritative answer: Non-authoritative answer: Name: wdr.de Address: 149.219.209.51
Also my CUxD script is now working.
I have reached the end of my knowledge, what am I doing wrong or how can I solve the
iptables
problem properly and persistent? Thanks!Ps: I have now also played around a bit with the firewall settings within the web interface. Adding port
53
does not help, only the optionports open
is so far successful. I would like to see a proper solution, but in principle that would be fine with me. Isports open
a security risk in a private LAN?Pss: Resolution is working after adding
try_exec_cmd "/usr/sbin/iptables -A INPUT -p udp --source-port 53 -j ACCEPT"
tolibfirewall.tcl
and mapping it inside the container. That solution is however not very good, since I have to replace the complete file....Adding the port via web interface results in:
But what seems to be required is just this one rule:
Describe the behavior you expected
DNS requests should resolve
Steps to reproduce the issue
exec
into the containernslookup
anythingWhat is the version this bug report is based on?
3.75.7.20240420
Which base platform are you running?
rpi2 (RaspberryPi2, ARM/armhf)
Which HomeMatic/homematicIP radio module are you using?
n/a
Anything in the logs that might be useful for us?
Additional information
For completeness, here is my network configuration:
nmcli device show
Beta Was this translation helpful? Give feedback.
All reactions