Desktop Ubuntu-20.04.3 iptables problem

in flag

I want to test some iptables rules the rule is to deny all outbound traffic except DNS.
so I changed the OUTPUT default rule of filter table to DROP using this command.

sudo iptables -t filter -P OUTPUT DROP

then I appended this rule to ACCEPT DNS traffic.

sudo iptables -t filter -A OUTPUT -p udp --dport 53 -o ens33 -j ACCEPT

and I run this command to test the policy.


and before running this command I run wireshark on my vm and host.
then nslookup command toke some time and gave me this message.

connection timed out; no servers could be reached

and wireshark (on vm and on host) did not captcher any packets.

so I deleted this rule and added another one.

sudo iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT

and did the same thing as before.
the same message appear again but wireshark (on vm and on host) captcher the packets (the request and response).

then I deleted this rule and added the next rule.

sudo iptables -t filter -A OUTPUT -p udp -j ACCEPT

and did the same thing as before.
this time nslookup command return with the result and wireshark captcher the packets.

So why this happen?

before these tests I installed snort (on a different vm) and I tried to drop some packets but it didn't.
the packets are logged but not dropped.
I don't know if these cases are related or not.

gn flag

Your question is really a good one. There are no error messages and everything looks correct with various iptables inquiry tools.

However, you need to allow traffic to/from the local loopback interface, lo. So you need one other rule. By the way, you do not need the -t filter part. So, and modified for my test computer network interface, and I use tcpdump instead of wireshark, and I have two occurrences running, one on lo and one on my NIC:

sudo iptables -A OUTPUT -o lo -j ACCEPT
sudo iptables -A OUTPUT -p udp --dport 53 -o br0 -j ACCEPT
sudo iptables -P OUTPUT DROP
Server:     <<<<<<< NOTE:

Non-authoritative answer:
Address: 2607:f8b0:400a:806::200e


doug@s19:~/iptables/tmp$ cat c06.txt
2021-11-21 09:41:07.851723 IP > 52661+ [1au] A? (39)
2021-11-21 09:41:07.879409 IP > 52661 1/0/1 A (55)
2021-11-21 09:41:07.884300 IP > 58740+ [1au] AAAA? (39)
2021-11-21 09:41:07.899157 IP > 58740 1/0/1 AAAA 2607:f8b0:400a:806::200e (67)


doug@s19:~/iptables/tmp$ cat l01.txt
2021-11-21 09:41:07.850815 IP > UDP, length 1
2021-11-21 09:41:07.851625 IP > 31736+ A? (28)
2021-11-21 09:41:07.879486 IP > 31736 1/0/0 A (44)
2021-11-21 09:41:07.884223 IP > 58878+ AAAA? (28)
2021-11-21 09:41:07.899259 IP > 58878 1/0/0 AAAA 2607:f8b0:400a:806::200e (56)

So why does the server appear to be local? By default Ubuntu runs a local resolver for buffering dns records and such:

doug@s19:~$ sudo ss -tulpn | grep ":53"
Netid  State  Recv-Q  Send-Q         Local Address:Port  Peer Address:Port                         Process
udp    UNCONN  0       0      *      users:(("systemd-resolve",pid=834,fd=12))
tcp    LISTEN  0       4096   *      users:(("systemd-resolve",pid=834,fd=13))

see also results from sudo systemctl status systemd-resolved and the related man pages.

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.