DNS issue with one of my Linodes

I'd like to understand why it blocks when it seemingly shouldn't.

When dealing with Ubuntu, never discount the fact that it has bugs. When I used Linux (even when I used Ubuntu), I never (ever, EVER) used ufw!

I'd get myself a good book on iptables and educated yourself on how to use it without ufw. There are several (mostly too-expensive) choices available on amazon.com.

If you want to allow all ICMP traffic in your iptables firewall, you can comment out all the entries noted in the /etc/ufw/before.rules file and add the following:

# ok icmp codes for INPUT
-A ufw-before-input -p icmp -j ACCEPT
# ok icmp code for FORWARD
-A ufw-betore-forward -p icmp -j ACCEPT

Hopefully, these will allow all inbound ICMP traffic (including ping). My iptables is a bit rusty these days (FreeBSD has a completely different kind of firewall) so check this with a trusted reference or local source beforehand. If you do this, you can eliminate the cloud firewall configuration for ICMP.

Also, you need to make sure that your IPv4 and IPv6 configurations wrt iptables are in sync. IPv6 firewall rules are managed with ip6tables. My guess is that ufw is probably not dealing with this at all (it's been my experience that Canonical "friendly front-ends" like ufw only begrudgingly support IPv6 -- and they probably wish it would just go away)… ICMP for IPv6 is called ICMP6. ping for IPv6 is performed with ping -6.

As I said before, IPv6 uses ICMP heavily. You probably don't want to block anything but ICMP ECHO (ping).

-- sw

After experimenting a bit more this seems to be some issue with how I have ufw configured. Still trying to figure out the exact details…

If it's a UFW configuration issue, you can use the How to Configure a Firewall with UFW guide to help you out.

Additionally, you may want to check out this earlier post from the Community Questions site about the Temporary Failure in Name Resolution error and, specifically, keeping port 53 open.

Yep I did keep port 53 open. This is the output from ufw status (when I still had it running):

To Action From
-- ------ ----
443 ALLOW Anywhere
22/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere
443/tcp ALLOW Anywhere
53/tcp ALLOW Anywhere
43/tcp ALLOW Anywhere
53/udp ALLOW Anywhere
43/udp ALLOW Anywhere
443 (v6) ALLOW Anywhere (v6)
22/tcp (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)
443/tcp (v6) ALLOW Anywhere (v6)
53/tcp (v6) ALLOW Anywhere (v6)
43/tcp (v6) ALLOW Anywhere (v6)
53/udp (v6) ALLOW Anywhere (v6)
43/udp (v6) ALLOW Anywhere (v6)

My current way of working around this is to disable ufw and set up the same rules in Cloud Firewall, ie block everything and then open the above ports. Not sure why that works while ufw blocks stuff though. I can see, from the ufw logs, that it blocks my icmp data after a ping for example…

I can see, from the ufw logs, that it blocks my icmp data after a ping for example…

ICMP does not have a port number as it is neither UDP nor TCP. You can block ping if you like but you should accept every other kind of ICMP. In particular, IPv6 router solicitation traffic is all ICMP.

The ufw command-line tool will not allow you to block ICMP (because it doesn't have a port number). However, ufw installs iptables rules to block ICMP ECHO (aka ping) by default. In order to allow it, you have to go straight to iptables (ufw is a so-called "friendly front-end" to iptables).

See: https://www.configserverfirewall.com/ufw-ubuntu-firewall/block-pings/ Please note the comment at the bottom of the page:

Note that the UFW command-line tool does not have an option to work with the ICMP protocol directly.

-- sw

P.S., just a hint from someone who's maybe crawled through more trenches than you -- toss ufw and learn to configure iptables. While daunting at first (because of the incredibly obtuse syntax), your life will be much easier…and you'll get the firewall you want…not the one Canonical thinks you want…

Yes, I do have all the ACCEPT entries in my /etc/ufw/before.rules. The ufw block entries in the log look something like this:

Jan 20 11:17:12 kaa kernel: [ 6978.507231] [UFW BLOCK] IN= OUT=eth0 SRC=MY_LINODE_IP_IS_HERE DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=65051 DF PROTO=ICMP TYPE=8 CODE=0 ID=9 SEQ=5

That's me running ping 8.8.8.8. Any ideas why it blocks the data?

See my post above.

-- sw

Yes, I did see/read your post and I am sorry if I missed some crucial part. My point is, I did already previously go through the before.rules file and verify that I have those ACCEPT lines in place. I don't remember where I found the info about them needing to be there but that info lines up with the link you posted above.

I should indeed probably skip ufw and go directly to the iptables level. I am curious though, as I haven't (knowingly) changed anything recently related to firewalls on this linode and obviously something has changed since it cannot do DNS lookups properly at the moment, while it worked well a few weeks ago (ie. the last time I tried to install something on it)…

Do you get the same behavior if you:

• turn off the cloud firewall but leave iptables in place;
• turn off iptables but leave the cloud firewall in place;
• turn off both.

Seems to me that this would be a simple experiment worth trying… FWIW, I don't use a cloud firewall (or Linux either…precisely because of stuff like this…that's another long story for another time).

-- sw

I haven't messed with iptables directly, other than checking the before.rules file, but if I turn off ufw (which, afaik, somehow controls/uses iptables) it works. I actually replicated the rules I previously had in ufw, in the cloud firewall and stuff still seems to work.

I am not sure if I am imagining things or if there is a bit of a delay to some of these things. I could have sworn turning off ufw didn't help the situation this morning, but now I have had it working since afternoon (Finland time).

The moment I turn ufw back on, the problems return though. I guess the cloud firewall is "good enough" for me so it's not that big of a problem but I'd like to understand why it blocks when it seemingly shouldn't.

Very much a Linux newbie here…

Allright, thanks! I'll consider this answered for now.