Hi David,
thanks for spotting this. As an IPv6 user, I should have seen and
noticed that myself.
I have drafted a fix in zg/icmpv6,
https://salsa.debian.org/debian/ferm/-/tree/zg/icmpv6?ref_type=heads,
but didnt get around yet to fixing it. Would you want to try?
Greetings
Marc
On Thu, Sep 24, 2026 at 05:54:12PM +0200, David Härdeman wrote:
Package: ferm
Version: 2.7-9
Severity: normal
Tags: ipv6
Dear Maintainer,
ferm-early.service runs before network-pre.target and ferm.service runs
after network-online.target.
network-online.target might (systemd/Network-Manager) rely on DHCPv6,
but there's no support for DHCPv6 in ferm-early.service, meaning that
network-online.target will hang waiting for a DHCPv6 reply which is
filtered.
DHCPv4 works because DHCPv4 clients will typically use a raw socket and
later unicast (which will be handled by conntracking), but DHCPv6 sends
multicast messages and receives a reply via a link-local address, so
that's not something conntrack can handle.
As a workaround, I've added this as /etc/ferm/ferm-early.d/dhcpv6.conf:
domain ip6 table filter chain INPUT {
proto udp saddr fe80::/10 sport 547 dport 546 ACCEPT;
proto ipv6-icmp ACCEPT;
}
Which works for me (the icmp part isn't strictly necessary, more for
feature-parity with IPv4), but it would be nice if this was supported
correctly out of the box.
--
David Härdeman
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
