I'm running a Synology NAS with docker and used to have multiple containers running perfectly fine for months. Last week I switched ISP and use their router to connect to the internet. Since then my containers are unable to make any outbound requests. I first thought there was a problem with Dock...
It looks like you are using dnsmasq for DNS server (for cache DNS etc..). The resolver is not able to request 8.8.4.4:53 (which is a Google Public DNS server). You got a timeout, so it is a firewall blocking issue. You can't resolve anything from your containers.
@hidigoudi Its indeed the new router that I received. I tried completely turning off its firewall (just for testing purposes), but that did not resolve the issue. What other options are there left for me?
What is the error ? You got a timeout or something else ? - Are you able to run from the container : host github.com or nslookup github.com without error ? - You can also try to force the DNS resolver by using : dig @8.8.4.4 github.com
@hidigoudi Still a timeout, yes. My containers are unable to find both dig and host but nslookup returns the following: ;; connection timed out; no servers could be reached. Still, even if I were to force the DNS, it wouldn't matter because the very request is blocked, is it not?
Yes you still have a firewall blocking. If you disabled the firewall, something else in the network blocks DNS requests. You should open UDP port 53 (you can also open TCP port 53 but DNS protocol uses UDP by default).
A good test would be to run nslookup github.com 8.8.4.4 in another machine in the same network as your container. - If the nslookup can resolve the name, the issue is probably in your container, if it's the same behavior (a timeout), then it's probably a network issue.
@hidigoudi I wish I could. When I try to do so in the router, I get the following warning: The following reserved ports cannot be forwarded because of safety reasons: (53,135,137,139,161,162). Would putting this one in bridge mode and using an external router allow me to bypass this restriction?
This warning is not related to your problem. It's about port forwarding, so the NAT in your internal network (when traffic comes from the internet). This is probably a firmware restriction from your ISP. - Your problem is located on the outgoing traffic (inside the firewall). - Have you tried to put the default gateway (the router IP) instead of 8.8.8.8 and 8.8.4.4 for the DNS resolver inside the container ? - Normally the router itself is a DNS resolver.
@hidigoudi Thanks for the explanation. So not related to the ISP, gotcha. So if I understand you correctly, you want me to add the default gateway (in my case 192.168.2.1) to my container? In this case I added it to /etc/resolv.conf and it did change the errors, albeit slightly: context deadline exceeded (Client.Timeout exceeded while awaiting headers)
While this will probably work, and I cannot thank you enough that it will, I have to ask; why is this necessary? What broke so dramatically on my side?
By the way, some ISP blocks DNS query to the external DNS resolvers like Google (8.8.8.8, 8.8.4.4), why ? To prevent their clients use another DNS resolver than their. It is also used to block some connection to pronography website or others malware.
You cannot bypass this behavior, it is directly integrated into the router firmware
It's for this reason you can't use Google DNS but you can use the router DNS resolver
Because the router DNS resolver is managed by the ISP and they have the full control on it.
I see. And them forcing me to use their DNS is beneficial to them as it allows them to harvest my browsing data, I assume? Would putting their router in bridge mode and connecting an external router have also resolved this?
It does make sense in my head but perhaps bridge mode doesn't sideline every single thing in that router
Yes it can solved by configured the router in bridge mode BUT it's more of a waste of time than anything else. Whatever happens, if it's not your ISP that collects your information, it will be Google or another company.
It does not really matter
But I can't stop from making your choice
By the way, your traffic will pass through the ISP router.
The exact content of this file is now {"data-root":"/var/packages/ContainerManager/var/docker","dns":["192.168.2.1"],"log-driver":"db","registry-mirrors":[],"storage-driver":"btrfs"} and the error is the old one again Get "https://acme.zerossl.com/v2/DV90": dial tcp: lookup acme.zerossl.com on 127.0.0.11:53: read udp 127.0.0.1:51113->127.0.0.11:53: i/o timeout
It did reset it indeed. The timeout errors are back. I also set the default gateway inside another container, but that one does it like it either. I will update it docker compose file to see if that does anything
So I removed everything from the daemon file. I manipulated a docker compose file to include dns: - 192.168.2.11 and restarted that container. While I don't have timeouts in that log, I do not get a response in the web interface as I expect (its Radarr)
Sample udhcpd configuration file (/etc/udhcpd.conf) # Values shown are defaults
# The start and end of the IP lease block start 192.168.0.20 end 192.168.0.254
# The interface that udhcpd will use interface eth0
# The maximum number of leases (includes addresses reserved # by OFFER's, DECLINE's, and ARP conflicts). Will be corrected # if it's bigger than IP lease block, but it ok to make it # smaller than lease block. #max_leases 254
# The amount of time that an IP will be reserved (leased to nobody)
Discussion between hidigoudi and Denn…
Discussion between hidigoudi and Denn…