I'm using nftables on a router running NixOS 22.11 (with the latest XanMod kernel patches and acpid as well as irqbalance enabled). The machine has 3 interfaces: enp4s0 which is connected to the internet and two local WiFi access points serving distinct IP LANs, wlp1s0 and wlp5s0.

My nftables configuration is the following: I just allow inbound DNS, DHCP and SSH traffic on the the local networks, and as allow outbound and forwarded traffic to the internet along with SNAT.

table ip filter {
    chain conntrack {
        ct state vmap { invalid : drop, established : accept, related : accept }
    chain dhcp {
        udp sport 68 udp dport 67 accept comment "dhcp"
    chain dns {
        ip protocol { tcp, udp } th sport 53 th sport 53 accept comment "dns"
    chain ssh {
        ip protocol tcp tcp dport 22 accept comment "ssh"

    chain in_wan {
        jump dns
        jump dhcp
        jump ssh
    chain in_iot {
        jump dns
        jump dhcp
    chain inbound {
        type filter hook input priority filter; policy drop;
        icmp type echo-request limit rate 5/second accept
        jump conntrack
        iifname vmap { "lo" : accept, "wlp1s0" : goto in_wan, "enp4s0" : drop, "wlp5s0" : goto in_iot }

    chain forward {
        type filter hook forward priority filter; policy drop;
        jump conntrack
        oifname "enp4s0" accept

table ip nat {
    chain postrouting {
        type nat hook postrouting priority srcnat; policy accept;
        oifname "enp4s0" snat to

table ip6 global6 {
    chain input {
        type filter hook input priority filter; policy drop;

    chain forward {
        type filter hook forward priority filter; policy drop;

With this simple configuration, I expected KDE Connect to not work as it requires ports 1714-1764 to be open. And indeed, if I connect my computer to wlp1s0 and my phone to wlp5s0 (so different interfaces), the devices cannot see each other, and I can see the packets through tcpdump as well as through nftables, either using logging rules or nftrace.

But somehow if I now put both machines on the same interface, e.g. wlp1s0, KDE Connect works perfectly and the devices see each other. My best guess was that this happens because of connection tracking, but even if I add

    chain trace_wan {
        type filter hook prerouting priority filter - 1; policy accept;
        iifname "wlp1s0" oifname "wlp1s0" meta nftrace set 1

to the filter table, I can't see any packets when running nft monitor trace. Similarly I can't see any packets in the system journal when inserting a logging rule at index 0 in the forward chain. And yet when running tcpdump -i wlp1s0 port 1716 I can see packets I expected nftables to see as well:

14:33:59.943462 IP > Flags [.], ack 20422, win 501, options [nop,nop,TS val 3319725685 ecr 2864656484], length 0
14:33:59.957101 IP > Flags [P.], seq 20422:20533, ack 1, win 285, options [nop,nop,TS val 2864656500 ecr 3319725685], length 111

Why can nftables not see those packets when the two devices are connected on the same interface ? How can I make nftables actually drop all these forwarded packets by default ?

Additional information requested in the comments:

❯ ip -br link
lo               UNKNOWN         <LOOPBACK,UP,LOWER_UP>
enp2s0           DOWN            <BROADCAST,MULTICAST>
enp3s0           DOWN            <BROADCAST,MULTICAST>
enp4s0           UP              <BROADCAST,MULTICAST,UP,LOWER_UP>
wlp5s0           UP              <BROADCAST,MULTICAST,UP,LOWER_UP>
wlp1s0           UP              <BROADCAST,MULTICAST,UP,LOWER_UP>

❯ ip -4 -br address
lo               UNKNOWN
enp4s0           UP   
wlp5s0           UP   
wlp1s0           UP   

❯ bridge link

❯ ip route
default via dev enp4s0 proto static dev enp4s0 proto kernel scope link src dev enp4s0 proto static scope link dev wlp1s0 proto kernel scope link src dev wlp5s0 proto kernel scope link src

❯ sysctl net.bridge.bridge-nf-call-iptables
sysctl: error: 'net.bridge/bridge-nf-call-iptables' is an unknown key
  • Are wlp1s0 and wlp5s0 serving two different IP LAN or the same IP LAN? If it's the last case, are they bridged or proxy arp is in use? Last but not least, do you run additional software affecting networking such as Docker or Kubernetes on this router? Won't change much an answer but allows to tie up all loose ends.
    – A.B
    Commented May 14, 2023 at 14:12
  • Actually just providing results of these commands should be enough to clearly answer my previous questions (feel free to obfuscate a public IP address or MAC addresses, but not beyond readability): ip -br link; ip -4 -br address; bridge link; ip route + sysctl net.bridge.bridge-nf-call-iptables (this one can give an error, it's also a possible output, and yes there's iptables in it while this question is about nftables, I'm aware of this).
    – A.B
    Commented May 14, 2023 at 14:16
  • They're serving different IP LANs, and I'm only running dhcpd4, fail2ban, hostapd, sshd and unbound.
    – Quentin
    Commented May 14, 2023 at 20:35

1 Answer 1


Warning: this is a generic Linux answer. What won't be covered in this answer is specific integration with NixOS and its own method for configuring network or how to call arbitrary commands from its configuration.


In OP's first case (two different interfaces), the router is actually routing between the two interfaces wlp1s0 and wlp5s0: forwarded IPv4 traffic is seen in nftables' family ip, filter forward hook.

In the second case, the traffic is bridged by the router's Access Point interface wlp1s0: nftables' family ip table doesn't see bridged traffic, only IPv4 traffic.

In addition this bridging doesn't even happens at standard Linux bridge level, but is done directly by the Access Point (AP)'s driver (and/or hardware accelerated): two Wifi devices will communicate between themselves (still through the AP) without their frames reaching the actual network stack.

In order for the system to actually filter this traffic, three things must be done:

  1. change the AP's settings so that traffic goes through the network stack
  2. have a Linux bridge associated to the AP so that frames aren't dropped by the network stack and so that nftables can see them at the bridge level
  3. have adequate nftables rules in the bridge family. For IP stateful firewalling in the bridge family, this also requires Linux kernel >= 5.3 (NixOS 22.11 is good enough).

Other options not pursued:

  • alternatively to 2+3, and without possible stateful firewalling, one might imagine using nftables' netdev family with ingress and possibly egress (requires Linux kernel >= 5.17 for egress fwd) but there would be many corner cases to handle: better not

  • instead of 3, use old bridge netfilter code intended for stateful firewalling in bridge path by iptables (and used by Docker) to have all rules in the same table

    nftables, which is also affected by it, aims to not depend on this code and thus lacks features for its proper use (mostly it lacks the equivalent of iptables' physdev module for one way to distinguish bridged traffic from routed traffic in the same ruleset). This would make things still rely on iptables and would thus still need multiple tables. (Example of such complex use along Docker: nftables whitelisting docker).

    As a warning, should Docker be added on the router, expect disruption of the setup presented below.


  1. change hostapd settings

    Two related settings must be changed on the hostapd setup:

    • tell that frames must be handled by the network stack rather than being short-circuited by the driver

      The configuration of hostapd for wlp1s0 must be changed. If somehow a single configuration existed for the two Wifi interfaces, chances are there should now be two separate configurations. I won't address such integration in this answer and will concentrate on the single interface wlp1s0.

      AP isolation must be enabled in hostapd.conf:


      Now frames between two station clients (STA) will reach the network stack rather than being handled directly by the AP driver.

    • Configure hostapd to use a bridge and set the wireless interface as bridge port

      With only the previous setting, only the frames to or from the router would be handled by the routing stack part of the network stack. Frames not intended for or coming from the router would simply be dropped, as would happen if an Ethernet interface received unicast frames not intended for its MAC address. That's also why the setting is named ap_isolate: by default STAs become isolated between themselves.

      A bridge is required to handle this. Tell hostapd to set wlp1s0 as bridge port as soon as it configured it in AP mode. It will either create a bridge or (to be preferred) reuse an existing bridge with the provided name and set the interface as bridge port when running. I chose the arbitrary name brwlan1.

      Configure the bridge in hostapd.conf:

  2. change network settings related to using a bridge

    • configure the bridge with no attached port and no delay

      Manually that would just be:

      ip link add name brwlan1 up type bridge forward_delay 0

      Note: hostapd is the tool that will attach the Wifi interface to the bridge, because it must be set as AP first before being allowed to be set as bridge port.

    • move any routing (layer 3) setup about wlp1s0 to brwlan1:

      ip addr delete dev wlp1s0
      ip addr add dev brwlan1

      This also includes changing any interface reference in various applications, for example in the DHCP settings.

      ...and also nftables but this will be dealt in the next part.

    • have hostapd running

      Verify that once its wlp1s0 instance is running, wlp1s0 is set as brwlan1 bridge port:

      One should see something similar to:

      # bridge link show dev wlp1s0
      6: wlp1s0 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master brwlan1 state forwarding priority 32 cost 100 
    • then enable hairpin mode on the single bridge port

      For now, there still can't be STA-to-STA communication, but only STA-to-AP or AP-to-STA: STA-to-STA requires a frame arriving on the single bridge port wlp1s0 to be re-emitted on this same bridge port. Even if there's now a bridge to forward such frames, they won't be yet: by default an Ethernet bridge (or switch) disables forwarding back to the originating port because it doesn't make much sense in normal wired setup.

      So hairpin must be enabled on wlp1s0 so a frame received on this port can be re-emitted on this same port. Currently only development version (branch main) of hostapd accepts the new configuration parameter bridge_hairpin=1 to do this automatically (version 2.10 is not recent enough). This can be done manually using the bridge command (the obsolete brctl command doesn't support this feature):

      bridge link set dev wlp1s0 hairpin on

      This part requires proper OS integration: it must be done only after hostapd attached wlp1s0 as bridge port, because it's usable only on a bridge port. I would expect hostapd to set wlp1s0 as bridge port before daemonizing and letting the network configuration tool then run the command. Should that not be the case and a race condition happen, one can consider simply inserting a delay (eg: sleep 3; ) before this command to be sure the interface is a bridge port when the command runs. Should wlp1s0 be detached/reattached with the bridge (eg: restart of hostapd), this command must be run again: it should be called from network configuration.

  3. adapt nftables ruleset

    ... using the bridge family instead of the ip family. It's quite similar to routing. Frames intended for the router are seen in input hook, frames from the router are seen in output hook, STA-to-STA frames are seen in the forward hook.

    As objects namespace is per table, there can't be any rule reused between both, so some duplication will be needed. I just copied and adapted the relevant parts of the routing rules related to forwarding. As an example I enabled ping and the ports for KDE connect, with a few counters. Some of the boiler-plate is not really needed (eg: ether type ip ip protocol tcp tcp dport 1714 can be replaced with just tcp dport 1714 if there's a generic drop rule for IPv6 first. Internally the nft command inserts any needed boiler-plate when presenting the rules to the kernel).

    table bridge filter        # for idempotence
    delete table bridge filter # for idempotence
    table bridge filter {
        chain conntrack {
            ct state vmap { invalid : drop, established : accept, related : accept }
        chain kdeconnect {
            udp dport 1714-1764 counter accept
            tcp dport 1714-1764 counter accept
        chain forward {
            type filter hook forward priority filter; policy drop;
            jump conntrack
            ether type ip6 drop     # just like OP did: drop any IPv6
            icmp type echo-request counter accept
            jump kdeconnect
            ether type arp accept   # mandatory for IPv4 connectivity

    Should wlp5s0 be later configured likewise with its own separate bridge, then filtering per bridge port or per bridge will become needed (eg: iifname wlp1s0 or ibrname brwlan1 etc. where needed).

    Other cases are still handled by standard routing in OP's initial ruleset: the input and output filter hooks are not configured so will accept traffic, either to/from the router, or to be routed to/from other interfaces.

    OP's nftables for routing must be adapted too. Wherever in table ip filter the word wlp1s0 appears, it must be replaced by brwlan1 which is now the interface participating in routing.

  • A question: you only mention wlp1s0 but I assume I'll have to do the same thing with wlp5s0 if I also want to filter traffic from wlp5s0 to itself, right ? Any peculiarities I should be aware on if I do that ?
    – Quentin
    Commented May 16, 2023 at 6:47
  • That's right. I already wrote what to care about 1/ be sure two hostapd instances have their own separate configuration because at least the bridge= parameter will differ (maybe unless you opt to merge the two IP LANs and together and have more filtering done at the bridge level, if 2 hostapd accept to use the same bridge) 2/ add adequate iifname/oifname/ibrname/obrname to bridge rules when needed. The good news is that rule reuse can be done once again within the bridge table, with chains, sets maps etc.
    – A.B
    Commented May 16, 2023 at 9:08
  • Btw,until a new hostapd release including hairpin management exists, hairpin mode might unexpectedly disappear maybe sometimes after several days, as explained in the hostapd commit (linked in the answer) that motivated the addition of the option,due to DFS (it's related to detecting a radar in the current frequency) and the fact that the wifi interface is temporarily removed from the bridge. If you don't want this to happen, you should configure hostapd to never use DFS channels. some DFS refs there: en.wikipedia.org/wiki/…
    – A.B
    Commented May 20, 2023 at 11:30
  • So forwarded traffic within a bridge should be filtered within the bridge family, but forwarded traffic between the two different bridges should be filtered within the IP family ?
    – Quentin
    Commented Jun 17, 2023 at 18:57
  • @Quentin you're looking at the wrong layer. The traffic is forwarded between the two bridge interfaces themselves, which are participating in routing between themselves not in bridging. If these interfaces were not bridges, that would be exactly the same: like what happened in your initial question between wlp1s0 and wlp5s0 and still happens at the end of my answer between brwlan1 and wlp5s0. the bridge interface itself participates in routing like all other interfaces that are not set as bridge ports.
    – A.B
    Commented Jun 17, 2023 at 19:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .