How can I troubleshoot an iptables rule that is preventing internet access from my server?

Rick Roy

7/8/24, 11:26 AM

So I am facing a strange issue, not able to make any sense. Hope someone here can help me understand. I have my iptable rules set like this

root@COV0495:~# iptables -S
-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N DOCKER
-N DOCKER-ISOLATION-STAGE-1
-N DOCKER-ISOLATION-STAGE-2
-N DOCKER-USER
-N ufw-after-forward
-N ufw-after-input
-N ufw-after-logging-forward
-N ufw-after-logging-input
-N ufw-after-logging-output
-N ufw-after-output
-N ufw-before-forward
-N ufw-before-input
-N ufw-before-logging-forward
-N ufw-before-logging-input
-N ufw-before-logging-output
-N ufw-before-output
-N ufw-reject-forward
-N ufw-reject-input
-N ufw-reject-output
-N ufw-track-forward
-N ufw-track-input
-N ufw-track-output
-A INPUT -i lo -j ACCEPT
-A INPUT -s 192.*.*.*/32 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s 192.*.*.*/32 -p tcp -m tcp --dport 8443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -j LOG
-A FORWARD -j LOG

While I can access the sites hosted on the server over internet, I can't access anything on the internet from within the server. Here is a sample ping request output:

root@COV0495:~# ping bing.com
ping: bing.com: Temporary failure in name resolution`

Now I have noticed that If i change the first rule to -P INPUT ACCEPT then I am able to access resources on the internet from within the server again.

What I am confused about though is why does the -P INPUT DROP affect traffic going out of the server?

I have tried enabling DNS inbound requests with rules like this

-A INPUT -p udp -m udp --sport 53 -m state --state ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --sport 53 -m state --state ESTABLISHED -j ACCEPT

But it still doesn't work.

130

1 + 0

ubuntu

iptables

web-server

Score:3

Server

A.B

7/8/24, 2:32 PM

The default DROP policy in your ruleset affects the replies: your query was done, a reply was sent back from remote to your server, and then your server dropped this reply. Final result: no reply meaning no connectivity.

Your last attempt with:

-A INPUT -p udp -m udp --sport 53 -m state --state ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --sport 53 -m state --state ESTABLISHED -j ACCEPT

should have made the DNS part work. Leading to the next step: an attempt to connect to the resource now it was resolved. But then again this attempt failed for the same reason: replies are dropped.

You're missing a generic stateful rule, which should be the very first rule in the ruleset:

-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

It will allow replies to any query sent by the hosts itself, including related errors (typically reeived as ICMP) because such query is memorized by Netfilter's conntrack facility for stateful operations (and also for NAT when relevant).

Should a REJECT rule be added later, then above should be followed by:

-A INPUT -m conntrack --ctstate INVALID -j DROP

(that's not needed here).

To have this take effect immediately, just run as root, using -I instead of -A:

iptables -I INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Note that Docker's containers are unaffected, because everything going to or from Docker's containers is routed (because of NAT), so traverses filter/FORWARD instead of filter/INPUT. They might still have been affected when relying on host's services, possibly DNS resolution.

+ 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: How can I troubleshoot an iptables rule that is preventing internet access from my server?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.