1 
$ufw status numbered
Status: active

 To                         Action      From
 --                         ------      ----
[ 7] Anywhere                   ALLOW IN    192.168.0.0/24             # allow all from LAN
[ 8] Anywhere                   ALLOW IN    192.168.1.0/24             # allow all from LAN
[ 9] OpenSSH                    LIMIT IN    Anywhere                   # allow ssh (limited)
[10] xxxxx                      ALLOW IN    Anywhere                   # allow transmission access
[11] Anywhere                   ALLOW IN    192.168.1.148              # allow all from Samsung TV
[12] Anywhere                   ALLOW IN    192.168.1.252              # allow all from KEF LSX speakers

Why ufw blocks 192.168.1.31 access from 192.168.1.148? all above ufw rules should facilitate that access but why they don't?

$ufwl | grep '192.168'
... [UFW BLOCK] IN=enp1s0 OUT= MAC=68:05:ca:24:83:6c:00:12:fb:74:36:26:08:00 SRC=192.168.1.148 DST=192.168.1.31 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=52235 DPT=25930 WINDOW=0 RES=0x00 RST URGP=0 MARK=0x1
... [UFW BLOCK] IN=enp1s0 OUT= MAC=68:05:ca:24:83:6c:84:17:15:02:86:9f:08:00 SRC=192.168.1.252 DST=192.168.1.31 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=52973 PROTO=TCP SPT=8080 DPT=33658 WINDOW=65535 RES=0x00 RST URGP=0 MARK=0x1

$lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 21.10
Release:        21.10
Codename:       impish

UPDATE
Before the above ufw rules, iptables only have these rules that "deny/block" something (besides the general blocking in case of not explicitly granting access):

Chain ufw-logging-deny (2 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere             ctstate INVALID limit: avg 3/min burst 10
LOG        all  --  anywhere             anywhere             limit: avg 3/min burst 10 LOG level warning prefix "[UFW BLOCK] "

Chain ufw-not-local (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere             ADDRTYPE match dst-type LOCAL
RETURN     all  --  anywhere             anywhere             ADDRTYPE match dst-type MULTICAST
RETURN     all  --  anywhere             anywhere             ADDRTYPE match dst-type BROADCAST
ufw-logging-deny  all  --  anywhere             anywhere             limit: avg 3/min burst 10
DROP       all  --  anywhere             anywhere
Improve this question
7
  • Your rule listing is done via ufw status numbered is that correct? There seem to be other rules up until rule 7. I am no expert but I am pretty sure that ufw rules are checked against sequentially (like iptables, in fact ufw is done via iptables). Now if there is some rule before rule 7, that rejects or drops this connection, then the rules afterward are ignored. Commented Feb 17, 2022 at 20:34
  • the other rules are all “allow” ones and they don’t interfere with these listed above Commented Feb 17, 2022 at 20:38
  • I just realized that your rule for the samsung TV ufw allow from 192.168.1.148 is redundant to rule ufw allow from 192.168.0.0/16 since the latter already includes your TV IP. However that does not explain why the access is blocked. What are your default rules for ufw? I'm assuming ufw default deny incoming and ufw default allow outgoing? Commented Feb 17, 2022 at 20:59
  • “ufw default deny incoming and ufw default allow outgoing” -> yes; the thing is that my ufw log shows few blocked 192.168.1.148; I can though access 192.168.1.31 from e.g. 192.168.1.44. Commented Feb 17, 2022 at 21:03
  • 1
    As others pointed out there could be some iptables rules which interfere with your ufw setup. You can check with iptables -L Commented Feb 17, 2022 at 23:21

2 Answers 2

Reset to default
0

I don't know exactly why this happens but I only guess it relates to the updates I apply from time to time to my XUbuntu. I suspect it so because today the issue happened again but after restarting the system it disappeared. I guess somehow the updates might "reset" UFW to some "default", more restrictive state (some of my rules are dropped).

Improve this answer
1
  • yes, that's probably normal behavior on most ubuntu/debian based distro, eg: if you update/upgrade a specific package that come with their own default config, and your own modified config happen to be on the same path/with the same filename, then it can be replaced, although usually it ask you if you want to replace it through a prompt. Commented Mar 26, 2022 at 15:41
0

I don't know the cause, but ran into a similar problem. Running

ufw reload

fixed the problem.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.