I have a Debian machine behind a wifi router. The machine is running a cron script to restore connectivity whenever a ping to a pre-defined host fails. I have set up iptables so that only the required ports/adresses are open. Everything works alright.

It gets a bit more complicated as I also need to be alert to possible changes in the router's external IP address, which is why I use a Dynamic DNS provider (www.noip.com) to keep the machine acessible from the outside. I use the following command to update the machine's address whenever connectivity is restored after a drop:

curl https://login:[email protected]/nic/update?hostname=user.domain.net&myip=

In turn, to determine the part, I run

dig +short myip.opendns.com  @resolver1.opendns.com 

Now, this part works, as well. But only with iptables disabled. Which is where my problem begins - I am not sure which ports/addresses to enable in iptables to let the above request go through.

I set up iptables to log the requests. I can see a UDP exchange between the machine in question and the wifi router that uses port 53 on both. That's DNS, I can understand that. But then, the Debian machine also receives from the router a packet intended for (okay, I found the meaning of that - it's multicast, even though I'm not sure how necessary it is), and sends a UDP request to a server in Germany which looks like NTP (port 123). And finally, it contacts on port 443, which is obviously the noip server.

Here's the questions I have:


Assuming that port 123 is ntp, what do I do about it? Is it really part of the dig / update process? If so, why that specific German server and should I then whitelist it?

2 - should I care to enable it?

(not asking about the dynamic handling of the IP address for dynupdate.no-ip.com, since it already has an answer on this site: Using iptables to redirect traffic to a dynamic DNS name instead of an IP address?)

(Added by David Go for readability formatting of iptables rules provided in comments)

-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT 
-A INPUT -p udp -m udp --sport 53 --dport 1024:65535 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i enp1s0 -m state --state RELATED,ESTABLISHED -j ACCEPT
  • How about providing a copy of your iptables rules? is not your problem. Neither is NTP - your system is likely setting its clock on startup.
    – davidgo
    Oct 20, 2020 at 9:47
  • -P INPUT DROP .......... -A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT .......... -A INPUT -p udp -m udp --sport 53 --dport 1024:65535 -j ACCEPT .......... -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT .......... -A INPUT -i enp1s0 -m state --state RELATED,ESTABLISHED -j ACCEPT
    – vanhemt
    Oct 22, 2020 at 7:00
  • @davidgo Sorry for not providing that info sooner. It's a relief, I don't need to worry about NTP and the 224. Also, enp1s0 leads to another machine and there are some FORWARD rules, too. Those are probably, irrelevant here. The OUTPUT chain is clear.
    – vanhemt
    Oct 22, 2020 at 7:03

2 Answers 2


I think you are missing some rules in your iptables list. I will assume that these are irrelevant.

My guess is that the relevant rules are missing or that the below rule is wrong:

  -A INPUT -p udp -m udp --sport 53 --dport 1024:65535 -j ACCEPT

The above rule assumes that the request reverses source and target ports - ie when you are running a dig, the destination port is 53, and the source port is 1024-65535.

I point out another gotcha - which is related, but not the presenting problem - you are only dealing with UDP port 53. DNS uses both UDP and (for longer queries) TCP 53, so you need to rules like

  -A INPUT -p udp --dport 53 -j ACCEPT
  -A INPUT -p tcp --dport 53 -j ACCEPT

(You can additionally add a source port, but I'm not sure what benefit this will provide)

  • My OUTPUT chain was clear all this time, which wasn't exactly "right". I note your comments for my upcoming OUTPUT rules, though.
    – vanhemt
    Oct 25, 2020 at 9:30

Actually, I was in touch with noip's support and they pointed out that I needed to unblock ports 80 and 443 on my INPUT chain for the curl request. They also mentioned port 8245, but the command works without it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .