You are not logged in.
Hi I don't pretend to understand nft. I'm running latest
arch 5.16.3-arch1-1,
nft: nftables v1.0.1 (Fearless Fosdick #3)
avahi-browse: avahi-browse 0.8
/etc/nftables.conf:
#!/usr/bin/nft -f
# vim:set ts=2 sw=2 et:
# IPv4/IPv6 Simple & Safe firewall ruleset.
# More examples in /usr/share/nftables/ and /usr/share/doc/nftables/examples/.
table inet filter
delete table inet filter
table inet filter {
chain input {
type filter hook input priority filter
policy drop
ct state invalid drop comment "early drop of invalid connections"
ct state {established, related} accept comment "allow tracked connections"
iifname lo accept comment "allow from loopback"
ip protocol icmp accept comment "allow icmp"
meta l4proto ipv6-icmp accept comment "allow icmp v6"
tcp dport ssh accept comment "allow sshd"
pkttype host limit rate 5/second counter reject with icmpx type admin-prohibited
counter
}
chain forward {
type filter hook forward priority filter
policy drop
}
}
The problem is this table is blocking the avahi browse. When I drop it with "nft flush ruleset" then my avahi-browse works.
Why does this ruleset need to be there, and what needs to be done to allow avahi to get the packets it needs to see? I did check the journal for drop messages but saw none.
Last edited by mwigzell (2022-02-04 16:36:26)
Offline
It took me some time and some (re-)reading to fully understand your questions.
Hi I don't pretend to understand nft.
O.K.
The problem is this table is blocking the avahi browse.
This is not obvious from the rule set itself - loopback traffic is allowed - but I may have an idea.
When I drop it with "nft flush ruleset" then my avahi-browse works.
O.K.
Why does this ruleset need to be there[...]
I can only guess here. Both iptables and nftables can be enabled via systemd units. Those units contain commands loading default rulesets:
ExecStart=/usr/bin/iptables-restore /etc/iptables/iptables.rules
ExecStart=/usr/bin/nft -f /etc/nftables.conf
The ruleset for iptables is empty:
# Empty iptables rule file
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
The rule set for nftables is not. In fact, this rule set blocks forwarding traffic completely, blocks incoming traffic except SSH and ICMP (v4 and v6) and doesn't do anything regarding outgoing connections. It also limits incoming packets to 5 per second.
[...] what needs to be done to allow avahi to get the packets it needs to see?
I presume by allowing incoming multicast DNS (MDNS) traffic (UDP/TCP port 5353)
I did check the journal for drop messages but saw none.
This rule set does not create log entries.
Here's what I would do: Modify the last line from the input chain to
counter log prefix "input dropped: "
Look out for dropped packets when avahi-browse is active and finally allow those.
Last edited by -thc (2022-02-04 10:35:54)
Offline
Why does this ruleset need to be there
To protect your system out of the box.
Simple firewall
nftables comes with a simple and secure firewall configuration stored in the /etc/nftables.conf file.
The nftables.service will load rules from that file when started or enabled.
Last edited by Lone_Wolf (2022-02-04 12:20:42)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Ah, thanks. I think I see: the default is to drop the packets silently. So I need to log that, but also fashion a statement that will allow the desired packets through.
Makes sense, thanks.
Offline
I discovered that the firewall is actually ok (except that it is not logging what it is doing).
The actual issue was that I was fooling with LXC and switched bridged my adapter so that the LXC container and my host were on same subnet.
This meant that packets from my Lan were no longer coming in from my "enp4s0" but instead from "lxcbr0".
input dropped: IN=lxcbr0 OUT= MAC=01:00:5e:7f:ff:fa:00:0e:58:b2:83:e4:08:00 SRC=192.168.86.29 DST=239.255.255.250 LEN=594 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=UDP SPT=49254 DPT=1900 LEN=574
So I added
iifname lxcbr0 accept comment "allow input from LXC bridge adapter"
to the input filter. And it now works!
Offline
I discovered that the firewall is actually ok (except that it is not logging what it is doing).
Offline