← Back to team overview

gufw-developers team mailing list archive

[Bug 1650489] Re: ufw broken on Linux Mint 17.3

 

Hi,

"- there are already rules for avahi (bonjour) to make discovery work,
but connections to the discovered services would need rules allowing the
connection"

Then connection to port 8612 should work, but it doesn't. PC talks to
8612 of the printer, and then the printer replies from 8612. And this
reply gets blocked. It does not matter whether ufw gets stateful for
sane or not.

ufw may get this wrong, because the communication starts out as a
multicast, thus the recipient address is different than the address that
answers. But:

It gets even blocked, when a new rule is introduced to allow ALL inbound
traffic to 8612, so this rule just simply doesn't work.

Adding nf_conntrack_sane DOES NOT fix the problem... I have added
nf_conntrack_sane. And yes, I have restarted ufw...

This printer/scanner, btw, is not an Epson, but a Canon MX 925. And yes,
I have added the BJNP protocol to Sane. But it's not only Sane that does
not discover the scanner, also Vuescan does not discover it, and
Vuetracks author Ed Hamrick advises me to sniff the packets...

Syslog excerpt of an attempted network discovery:
.31 is the PC, .251 is the printer, .254 would be the router to the internet (not used here, of course).

Dec 17 16:56:09 FSC-neu kernel: [255876.935983] [UFW ALLOW] IN= OUT=eth0
SRC=192.168.1.31 DST=224.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=1 ID=12815
DF PROTO=UDP SPT=59438 DPT=8612 LEN=24

PC multicast to (all) printers port 8612, ALLOWed

Dec 17 16:56:09 FSC-neu kernel: [255876.936015] [UFW ALLOW] IN=eth0 OUT=
MAC= SRC=192.168.1.31 DST=224.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=1
ID=12815 DF PROTO=UDP SPT=59438 DPT=8612 LEN=24

Another multicast...

Dec 17 16:56:09 FSC-neu kernel: [255876.937195] [UFW BLOCK] IN=eth0 OUT=
MAC=90:1b:0e:18:56:e3:60:12:8b:46:ce:55:08:00 SRC=192.168.1.251
DST=192.168.1.31 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=26547 PROTO=UDP
SPT=8612 DPT=59438 LEN=40

Printers reply from 8612 gets BLOCKed

Dec 17 16:56:10 FSC-neu kernel: [255877.438000] [UFW BLOCK] IN=eth0 OUT=
MAC=90:1b:0e:18:56:e3:60:12:8b:46:ce:55:08:00 SRC=192.168.1.251
DST=192.168.1.31 LEN=146 TOS=0x00 PREC=0x00 TTL=64 ID=51278 PROTO=UDP
SPT=5353 DPT=59438 LEN=126

Dec 17 16:56:10 FSC-neu kernel: [255877.487316] [UFW ALLOW] IN= OUT=eth0 SRC=192.168.1.31 DST=224.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=1 ID=12879 DF PROTO=UDP SPT=59438 DPT=8612 LEN=24 
Dec 17 16:56:10 FSC-neu kernel: [255877.487333] [UFW ALLOW] IN=eth0 OUT= MAC= SRC=192.168.1.31 DST=224.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=1 ID=12879 DF PROTO=UDP SPT=59438 DPT=8612 LEN=24 

PC repeating the mulicast to the printer

Dec 17 16:56:10 FSC-neu kernel: [255877.488620] [UFW BLOCK] IN=eth0 OUT=
MAC=90:1b:0e:18:56:e3:60:12:8b:46:ce:55:08:00 SRC=192.168.1.251
DST=192.168.1.31 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=59770 PROTO=UDP
SPT=8612 DPT=59438 LEN=40

Printers responsed BLOCKed again...

Dec 17 16:56:10 FSC-neu kernel: [255877.986032] [UFW BLOCK] IN=eth0 OUT=
MAC=90:1b:0e:18:56:e3:60:12:8b:46:ce:55:08:00 SRC=192.168.1.251
DST=192.168.1.31 LEN=146 TOS=0x00 PREC=0x00 TTL=64 ID=53766 PROTO=UDP
SPT=5353 DPT=59438 LEN=126

Communication from the AVAHI port gets BLOCKed also, despite the rule
that should allow that

Dec 17 16:56:10 FSC-neu kernel: [255878.035296] [UFW ALLOW] IN= OUT=eth0 SRC=192.168.1.31 DST=224.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=1 ID=12957 DF PROTO=UDP SPT=59438 DPT=8612 LEN=24 
Dec 17 16:56:10 FSC-neu kernel: [255878.035318] [UFW ALLOW] IN=eth0 OUT= MAC= SRC=192.168.1.31 DST=224.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=1 ID=12957 DF PROTO=UDP SPT=59438 DPT=8612 LEN=24 
Dec 17 16:56:10 FSC-neu kernel: [255878.036566] [UFW BLOCK] IN=eth0 OUT= 
MAC=90:1b:0e:18:56:e3:60:12:8b:46:ce:55:08:00 SRC=192.168.1.251 DST=192.168.1.31 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=11059 PROTO=UDP SPT=8612 DPT=59438 LEN=40 

And the printer gets BLOCKed one more time.

So the questions remaining are:
a) ufw seems unaware of a protocol that starts multicast, and gets unicast replies.
b) ufw ignores rules that completely open up an incoming port

Yours
Oliver

** This bug is no longer a duplicate of bug 1595046
   UFW and saned... not working togheter...

-- 
You received this bug notification because you are a member of Gufw
Developers, which is subscribed to Gufw.
https://bugs.launchpad.net/bugs/1650489

Title:
  ufw broken on Linux Mint 17.3

Status in Gufw:
  New
Status in Linux Mint:
  New
Status in ufw:
  New

Bug description:
  Hi,

  on my Linux Mint 17.3 x64 Cinnamon, ufw appears to be broken (0.34~rc-
  0ubuntu2).

  Networking seemed to work alright, surfing was no problem, also FTP
  and SSH worked. But not Bonjour, which I need to use the scanner that
  is inside my Canon MX925. So I used gufw (14.04.2-0ubuntu1.2) to add
  rules that allow packets sent to ports 8610 and 8612, and packets
  coming from 5353 (Bonjour). But still, some of these packets get
  blocked, according to syslog.

  Looking deeper inside the matter, I realised that the default inbound
  policy is deny. So surfing should not be possible, but it works
  alright.

  sudo ufw status verbose

  Status: Aktiv
  Protokollierung: on (medium)
  Voreinstellung: reject (eingehend), allow (abgehend), disabled (gesendet)
  Neue Profile: skip

  Zu                         Aktion      Von
  --                         ------      ---
  8612                       ALLOW IN    Anywhere (log)
  5353                       ALLOW IN    Anywhere (log)
  8612 (v6)                  ALLOW IN    Anywhere (v6) (log)
  5353 (v6)                  ALLOW IN    Anywhere (v6) (log)

  8610                       ALLOW OUT   Anywhere (log)
  8612                       ALLOW OUT   Anywhere (log)
  8610 (v6)                  ALLOW OUT   Anywhere (v6) (log)
  8612 (v6)                  ALLOW OUT   Anywhere (v6) (log)

  Bonjour should be the only thing working, but in fact, it's the only
  thing NOT working. So I looked at those predefined sets of rules that
  ufw should come with, according to

  http://www.larrytalkstech.com/ufw-the-linux-uncomplicated-firewall/

  but most of the ones mentioned there are missing.

  sudo ufw app list

  Verfügbare Anwendungen:
    CUPS
    Samba

  Only CUPS and Samba are known? Not even DNS or tcp/80 ? Since surfing
  works alright, my guess is that ufw does not really work together with
  iptables, which to my understanding is the "real firewall" that (g)ufw
  is only a frontend for. So ufw does not show all rules that are in
  force, and ufw does not correctly apply new rules at the correct
  position in the chain, so they get defeated by the existing rules,
  thus Bonjour gets broken.

  Dec 15 14:00:30 FSC-neu kernel: [72537.358551] [UFW BLOCK] IN=eth0
  OUT= MAC=90:1b:0e:18:56:e3:60:12:8b:46:ce:55:08:00 SRC=192.168.1.251
  DST=192.168.1.31 LEN=146 TOS=0x00 PREC=0x00 TTL=64 ID=63636 PROTO=UDP
  SPT=5353 DPT=36762 LEN=126

  Thanks
  Oliver

To manage notifications about this bug go to:
https://bugs.launchpad.net/gui-ufw/+bug/1650489/+subscriptions


References