On my Ubuntu 16.04 machine, I have configured UFW like this:

$ sudo apt-get install ufw

$ sudo ufw limit 22/tcp
$ sudo ufw allow 80/tcp
$ sudo ufw allow 443/tcp

$ sudo ufw enable

Now if I run sudo ufw status verbose, the output is the following:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     LIMIT IN    Anywhere                  
80/tcp                     ALLOW IN    Anywhere                  
443/tcp                    ALLOW IN    Anywhere                  
22/tcp (v6)                LIMIT IN    Anywhere (v6)             
80/tcp (v6)                ALLOW IN    Anywhere (v6)             
443/tcp (v6)               ALLOW IN    Anywhere (v6)

Which looks good, as far as I can see: It allows SSH (throttled) and also HTTP and HTTPS. Which is what was desired.

But after a few days, looking into /var/log/ufw.log reveals quite a few entries like the following examples:

Jan 1 00:00:00 <SERVER_NAME> kernel: [<UPTIME>] [UFW BLOCK] IN=eth0 OUT= MAC=<41_CHARACTERS> SRC=<IP_V4> DST=<IP_V4> LEN=40 TOS=0x00 PREC=0x00 TTL=56 ID=1234 DF PROTO=TCP SPT=17708 DPT=443 WINDOW=0 RES=0x00 RST URGP=0

Jan 2 23:59:59 <SERVER_NAME> kernel: [<UPTIME>] [UFW BLOCK] IN=eth0 OUT= MAC=<41_CHARACTERS> SRC=<IP_V4> DST=<IP_V4> LEN=52 TOS=0x00 PREC=0x00 TTL=51 ID=23456 DF PROTO=TCP SPT=29199 DPT=443 WINDOW=1061 RES=0x00 ACK FIN URGP=0

As per DPT=443, is UFW blocking some HTTPS requests? Why is that? HTTPS (i.e. port 443 via TCP) is explicitly allowed in the UFW configuration, as seen above, isn’t it? What other reasons could there be for UFW to block these requests?

(UFW clearly doesn’t block all HTTPS requests, as I can open my website via HTTPS in the browser when I try it.)

1 Answer 1


Your two example log entries are actually tcp session termination type packets. For TCP connections, Linux tends to use a "half-duplex" close sequence where either side of the session can initiate connection termination via a single 2 way FIN-ACK handshake (which puts the connection into the CLOSE_WAIT state), instead of a full 4 way FIN-ACK handshake. What very often happens, particularly with a router in between, is one side thinks the session has been closed and the other doesn't. Your computer has terminated and forgotten about the session, and so considers the packets as invalid new session opening packets and blocks them. No harm done, the actual session worked fine.

The important information here are the TCP flags, "RST" (Reset), and "ACK FIN" for your two examples.

  • Thanks! Wouldn’t have expected the firewall to handle (and log) this. Instead, I would have expected this would happen at a lower level and all be done when things reach UFW. Anyway, this happening regularly (not just once or twice a day) is no problem, either?
    – caw
    Nov 11, 2019 at 22:11
  • 1
    @caw : Yes this happens a lot. Actually, some bad guys seem to try to open TCP sessions often without a proper opening packet, with proper SYN flag. I don't know why. I had 732 occurrences last week, and my site is extremely not busy. Myself, I do expect the firewall to log these. Note: I do not use UFW, I only use iptables directly. Nov 11, 2019 at 22:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.