ufw

Comment 2 for bug 1650489

Revision history for this message
Oliver (ok23) wrote : 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