0

I am running a NGINX based loadbalancer on Ubuntu 16.04.2 LTS.

I have configured the firewall using UFW.

ufw allow to X.X.X.X port 6633 proto tcp 
ufw allow to X.X.X.X port 80 proto tcp
ufw allow to X.X.X.X port 443 proto tcp

The port are accessible from the world.

Here is a line from my /var/log/syslog:

May 11 06:55:26 FELB08 kernel: [735361.703709] [UFW BLOCK] IN=eth0 OUT= MAC=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX SRC=X.X.X.X DST=X.X.X.X LEN=40 TOS=0x08 PREC=0x20 TTL=52 ID=51446 DF PROTO=TCP SPT=2022 DPT=80 WINDOW=4096 RES=0x00 ACK RST URGP=0
May 11 07:34:53 FELB08 kernel: [737729.068015] [UFW BLOCK] IN=eth0 OUT= MAC=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX SRC=X.X.X.X DST=X.X.X.X LEN=40 TOS=0x08 PREC=0x20 TTL=52 ID=54132 DF PROTO=TCP SPT=1722 DPT=80 WINDOW=4096 RES=0x00 ACK RST URGP=0

My question is why do I see entries from UFW in syslog about ports being blocked even though the ports are open and working?

I thought it might be some kind of rate limit on connections to prevent DDOS or something similar but there are no limits set.

What am I missing?

I saw that this question was already asked in couple of variations but never marked answered, So I am trying my luck...

Thanks, Tal

Tal.Z
  • 3

1 Answers1

1

It is important to note the TCP flags in your example syslog lines, "ACK RST".

It is also important to know that 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, instead of a full 4 way FIN-ACK handshake. (although in this case it seems to have been a reset (RST) packet).

The blocked packets are likely due to some extra packets at the end of a TCP session where the connection tracking table has already forgotten about the session, and therefore they are considered to be incorrectly formed NEW packets. They are nothing to worry about, and the actual TCP session likely worked just fine.

Doug Smythies
  • 16,146