UFW drops sane multicast traffic
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ufw |
Fix Released
|
Low
|
Jamie Strandboge | ||
ufw (Ubuntu) |
Fix Released
|
Low
|
Jamie Strandboge | ||
Natty |
Fix Released
|
Low
|
Jamie Strandboge |
Bug Description
UFW silently drops ICMPv6 traffic from multicast echo request.
-------
$ ufw --version
ufw 0.30.0-1ubuntu2
Copyright 2008-2010 Canonical Ltd.
-------
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.10
Release: 10.10
Codename: maverick
-------
Facts:
$ ping6 ff02::1%eth0
PING ff02::1%
64 bytes from fe80::219:
fe80::219:
while wireshark and tcpdump show me a lot of them. With ufw off, ping6 reports all other link-local addresses.
Plus, Neighbor discovery protocol is working since ip -6 neigh reports several link-local addresses.
Thus ICMPv6 Echo Reply messages are dropped by ufw. I found a way to fix this behavior by adding a rule and changing
their order in /etc/ufw/
Here is the diff -u:
--- before6.rules 2011-02-17 10:38:09.106701972 +0100
+++ before6.rules.FIXED 2011-02-17 10:26:19.658701976 +0100
@@ -27,6 +27,14 @@
-A ufw6-before-input -p icmpv6 --icmpv6-type router-solicitation -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p icmpv6 --icmpv6-type router-
+# ok icmp codes
+-A ufw6-before-input -p icmpv6 --icmpv6-type destination-
+-A ufw6-before-input -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
+-A ufw6-before-input -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT
+-A ufw6-before-input -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT
+-A ufw6-before-input -p icmpv6 --icmpv6-type echo-request -j ACCEPT
+-A ufw6-before-input -p icmpv6 --icmpv6-type echo-reply -j ACCEPT
+
# quickly process packets for which we already have a connection
-A ufw6-before-input -m state --state RELATED,ESTABLISHED -j ACCEPT
-A ufw6-before-output -m state --state RELATED,ESTABLISHED -j ACCEPT
@@ -35,13 +43,6 @@
-A ufw6-before-input -m state --state INVALID -j ufw6-logging-deny
-A ufw6-before-input -m state --state INVALID -j DROP
-# ok icmp codes
--A ufw6-before-input -p icmpv6 --icmpv6-type destination-
--A ufw6-before-input -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
--A ufw6-before-input -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT
--A ufw6-before-input -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT
--A ufw6-before-input -p icmpv6 --icmpv6-type echo-request -j ACCEPT
-
# allow dhcp client to work
-A ufw6-before-input -p udp --sport 67 --dport 68 -j ACCEPT
-------
Other Remarks:
I believe that ff00::1/8 or ff00::2/8 means nothing but ff00::/8, hence duplicate rules...
Indeed:
$ ip6tables -L -n
(....)
Chain ufw6-before-input (1 references)
(...)
ACCEPT icmpv6 ff00::/8 ::/0
ACCEPT icmpv6 ::/0 ff00::/8
ACCEPT icmpv6 ff00::/8 ::/0
ACCEPT icmpv6 ::/0 ff00::/8
(...)
Thus:
# allow MULTICAST
--A ufw6-before-input -p icmpv6 -s ff00::1/8 -j ACCEPT
--A ufw6-before-input -p icmpv6 -d ff00::1/8 -j ACCEPT
--A ufw6-before-input -p icmpv6 -s ff00::2/8 -j ACCEPT
--A ufw6-before-input -p icmpv6 -d ff00::2/8 -j ACCEPT
+-A ufw6-before-input -p icmpv6 -s ff00::/8 -j ACCEPT
+-A ufw6-before-input -p icmpv6 -d ff00::/8 -j ACCEPT
would be enough I guess.
Thanks for your attention.
Related branches
Changed in ufw (Ubuntu): | |
status: | In Progress → Fix Committed |
Changed in ufw (Ubuntu Lucid): | |
status: | New → Triaged |
importance: | Undecided → Low |
Changed in ufw (Ubuntu Maverick): | |
status: | New → Triaged |
importance: | Undecided → Low |
no longer affects: | ufw (Ubuntu Lucid) |
no longer affects: | ufw (Ubuntu Maverick) |
No news about this one? Jeez, it's important though!