DNS replies are blocked by UFW default settings

[jan]

DNS replies are blocked by UFW default settings, with no documented way to recover this.
Ufw.log on my Ubuntu PC (192.168.2.237) is flooded with replies from my nameserver (192.168.2.1).
In the graphical interface to ufw, I see no way to let return UDP packets pass.
I have enabled port 53 in the graphical user interface, but no improvement.

Thus, I'd like to report a bug in either the configuration of ufw, or its inner workings.
A workaroubnd would be a way to let these packets pass.

Feb 5 21:14:54 his10 kernel: [42776.445851] [UFW BLOCK] IN=wlan2 OUT= MAC=94:44:52:8d:9d:cb:00:21:04:4e:fd:ba:08:00 SRC=192.168.2.1 DST=192.168.2.237 LEN=58 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=53 DPT=46507 LEN=38
Feb 5 21:15:06 his10 kernel: [42788.500267] [UFW BLOCK] IN=wlan2 OUT= MAC=94:44:52:8d:9d:cb:00:21:04:4e:fd:ba:08:00 SRC=192.168.2.1 DST=192.168.2.237 LEN=58 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=53 DPT=52822 LEN=38
Feb 5 21:15:09 his10 kernel: [42791.585554] [UFW BLOCK] IN=wlan2 OUT= MAC=94:44:52:8d:9d:cb:00:21:04:4e:fd:ba:08:00 SRC=192.168.2.1 DST=192.168.2.237 LEN=58 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=53 DPT=46507 LEN=38
Feb 5 21:15:14 his10 kernel: [42796.482442] [UFW BLOCK] IN=wlan2 OUT= MAC=94:44:52:8d:9d:cb:00:21:04:4e:fd:ba:08:00 SRC=192.168.2.1 DST=192.168.2.237 LEN=58 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=53 DPT=52653 LEN=38
Feb 5 21:15:21 his10 kernel: [42803.664466] [UFW BLOCK] IN=wlan2 OUT= MAC=94:44:52:8d:9d:cb:00:21:04:4e:fd:ba:08:00 SRC=192.168.2.1 DST=192.168.2.237 LEN=58 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=53 DPT=48775 LEN=38

$ ufw --version
ufw 0.30pre1-0ubuntu2
Copyright 2008-2010 Canonical Ltd.

$ uname -a
Linux 2.6.32-28-generic-pae #55-Ubuntu SMP Mon Jan 10 22:34:08 UTC 2011 i686 GNU/Linux

[Jamie Strandboge (jdstrand)]

Thank you for reporting a bug and helping to make Ubuntu better.

When enabled, ufw by default will allow all outgoing connections with connection tracking. This means when your host connects to your DNS server, your DNS server's response will be allowed. Either your /etc/ufw/before.rules file was altered (you can compare it with /usr/share/ufw/before.rules, these packets are not associated with an established connection, or an earlier ufw rule is blocking the connection (or you've exhausted the memory for connection tracking, but that is highly unlikely). As a workaround until you can find the root cause, you can use the following rule:
$ sudo ufw allow from 192.168.2.1 port 53

I am going to mark this bug as Invalid for now, since ufw is known to work properly with DNS. Feel free to reopen if you find more details to describe the bug. Thanks again!

[jan (jan-ubuntu-h-i-s)]

Thanks. I've added the rule. I presume that my log will be clean now.
Actually, I expect a problem in the connection tracking to be a root cause.
How could I have debugged that ?

I know that my wlan connection sometimes disconnects / reconnects this may be different from other test situations.

sudo diff /etc/ufw/before.rules /usr/share/ufw/before.rules
yields no differences.

Furthermore, the UFW DNS message appears in several other logs in launchpad.

https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/627055/+activity
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/622050
https://answers.launchpad.net/launchpad/+question/136376

In all cases, it is the UDP protocol. It will be invisible to the user, as DNS will retry, either by UDP or TCP.
Thus, the problem may be mostly visible in the ufw log, and not in DNS behavior.
Based on the above, I'd like to get the status back to incomplete.

[Jamie Strandboge (jdstrand)]

Thanks for the additional information, but it doesn't show that ufw is doing anything wrong with regard to logging. If your connection is unstable, then this sort of thing can happen:
1. client sends dns request to server
2. client interface goes down then up
3. packets are received from the server-- not associated with a valid connection, and are blocked

If you don't want these logged, you can also adjust the log level to 'low' (sudo ufw logging low), which should ignore INVALID packets (like incoming packets not associated with a connection). If you still want a higher loglevel, feel free to add a rule to /etc/ufw/before.rules to ignore these without logging (or comment out the first INVALID rule). I recommend reading the iptables man page about INVALID packets, and also examining tcpdump output on your client and server to see why your client is receiving the INVALID packets.

[Paul Graydon (twirrim)]

I'm seeing exactly the same behaviour on my VPS. Perfectly stable internet connection, but DNS is being blocked when UFW is enabled. Connection tracking does not seem to be working for it.

To be sure everything is good, I disabled ufw, purged it entirely, flushed the iptables and re-installed:

root@www:~# ufw disable
Firewall stopped and disabled on system startup
root@www:~# ufw reset
Resetting all rules to installed defaults. This may disrupt existing ssh
connections. Proceed with operation (y|n)? y
Backing up 'user.rules' to '/lib/ufw/user.rules.20110612_210210'
Backing up 'after6.rules' to '/etc/ufw/after6.rules.20110612_210210'
Backing up 'user6.rules' to '/lib/ufw/user6.rules.20110612_210210'
Backing up 'before6.rules' to '/etc/ufw/before6.rules.20110612_210210'
Backing up 'after.rules' to '/etc/ufw/after.rules.20110612_210210'
Backing up 'before.rules' to '/etc/ufw/before.rules.20110612_210210'
root@www:~# iptables -F
root@www:~# ip6tables -F
root@www:~# aptitude purge ufw
The following packages will be REMOVED:
  ufw{p}
0 packages upgraded, 0 newly installed, 1 to remove and 11 not upgraded.
Need to get 0 B of archives. After unpacking 840 kB will be freed.
Do you want to continue? [Y/n/?] y
(Reading database ... 39844 files and directories currently installed.)
Removing ufw ...
Purging configuration files for ufw ...
dpkg: warning: while removing ufw, directory '/lib/ufw' not empty so not removed.
Processing triggers for ureadahead ...
Processing triggers for man-db ...

/lib/ufw just contains the old rule files. Out of paranoia:

root@www:~# rm -rf /lib/ufw/

checking iptables shows that UFW is a little naughty and doesn't clean up after itself, leaving a load of chains.

# for i in ufw-track-output ufw-track-input ufw-reject-output ufw-reject-input ufw-reject-forward ufw-before-forward ufw-before-output ufw-before-logging-output ufw-before-logging-input ufw-before-logging-forward ufw-before-input ufw-before-input ufw-after-output ufw-after-logging-output ufw-after-logging-input ufw-after-logging-forward ufw-after-input ufw-after-forward; do iptables -X $i; done
iptables: No chain/target/match by that name.

(not sure what that one was, not important)

root@www:~# for i in ufw6-after-forward ufw6-after-input ufw6-after-logging-forward ufw6-after-logging-input ufw6-after-logging-output ufw6-after-output ufw6-before-forward ufw6-before-input ufw6-before-logging-forward ufw6-before-logging-input ufw6-before-logging-output ufw6-before-output ufw6-reject-forward ufw6-reject-input ufw6-reject-output ufw6-track-input ufw6-track-output; do ip6tables -X $i; done

root@www:~# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

root@www:~# ip6tables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

So we're clean, and clear ...

[Paul Graydon (twirrim)]

Hmm. I think I've found my problem. Stracing that enable:

read(3, "FATAL: Module nf_conntrack_ftp n"..., 8192) = 42
read(3, "FATAL: Module nf_nat_ftp not fou"..., 8150) = 36
read(3, "FATAL: Module nf_conntrack_irc n"..., 8114) = 42
read(3, "FATAL: Module nf_nat_irc not fou"..., 8072) = 36
read(3, "iptables-restore: line 66 failed"..., 8036) = 33
read(3, "iptables-restore: line 30 failed"..., 8003) = 33
read(3, "\n", 7970) = 1
read(3, "Problem running '/etc/ufw/before"..., 7969) = 40
read(3, "Problem running '/etc/ufw/after."..., 7929) = 39

UFW's output is far from helpful!

For what it's worth this is a linode server, running 11.04, kernel 2.6.39-linode33, so my problem is actually with linodes' kernel.

However, I would argue that UFW ought to put up errors / disable itself if necessary modules are missing. If conntrack etc. are missing it ought not to start-up as that's rather critical, surely? Stateless firewalls aren't that useful!

[ClashTheBunny (spam-mason)]

I also had this problem. I disabled and enabled ufw and it started working again. I was facing the same issue with UDP DNS being blocked. I don't know if disabling and enabling clears some kernel parameters, but that fixed it. I don't know how long it was running before running into this, but it could be a buffer limit. It's an ARM with 256 MB of ram running debian and ufw. It's debian testing running ufw 0.30.1-2 and linux 3.1.0.

[Patrick Gerken (do3cc)]

The title is misleading.
Apparently on many virtual servers connection tracking cannot be enabled and thus dns does not work.
http://blog.kylemanna.com/linux/2013/04/26/ufw-vps/
https://www.df.eu/forum/threads/70485-UFW-ERROR-problem-running-ufw-init (I think that the firewall works here, but their "solution" to removing the error message gives me shivers)
I have the same problem with a strato server.
The only error I get on ufw enable is

ERROR: problem running ufw-init

It would be nice if errors during kernel loading would be communicated together with at least a hint that this might be related to the virtual machine configuration