2

I'd like to take a default drop approach to my firewall rules. I've created some rules for testing purposes:

table bridge vmbrfilter {
    chain forward {
        type filter hook forward priority -100; policy drop;
        ip saddr 192.168.1.10 ip daddr 192.168.1.1 accept;
        ip saddr 192.168.1.1 ip daddr 192.168.1.10 accept;
    }
}

However traffic between 192.168.1.1 and 192.168.1.10 is still blocked. To see if it is a syntax issue, I tried:

table bridge vmbrfilter {
    chain forward {
        type filter hook forward priority -100; policy accept;
        ip saddr 192.168.1.10 ip daddr 192.168.1.1 drop;
        ip saddr 192.168.1.1 ip daddr 192.168.1.10 drop;
    }
}

This however succeeds in blocking traffic between the two IPs. So I don't have a clue as to why my accept rules aren't being hit. The nftables wiki says:

The drop verdict means that the packet is discarded if the packet reaches the end of the base chain.

But I literally have accept rules in my chain which should be matching.

Have I not understood something correctly? Thanks in advance for any help.

Update: A.B's ARP rule suggestion is helping. However I've discovered that my VLAN tagging is causing issues with my firewall rules. The ARP rule allows tagged traffic in through the physical NIC, the ARP replies are making it over the bridge but get blocked on exit from the physical NIC.

3
  • Have you removed old rules, from the table? – ctrl-alt-delor Jan 30 at 10:28
  • I do have the flush ruleset command at the top of the config file. I have the one table, with the forward chain and an anti-lockout input chain. – Synthetic Ascension Jan 30 at 10:52
  • Mine starts #!/usr/sbin/nft -f table ip my_table {}; flush table my_table; (table … starts the 2nd line) – ctrl-alt-delor Jan 30 at 11:13
0

IPv4 over Ethernet relies on ARP to resolve the Ethernet MAC address of the peer in order to send later unicast packets to it.

As you're filtering any ARP request since there's no exception for it, those requests can't succeed and after a typical 3s timeout you'll get the standard "No route to host". There won't be any IPv4 packet sent from 192.168.1.10 to 192.168.1.1 or from 192.168.1.1 to 192.168.1.10, since the previous step failed.

So add this rule for now, and see later how to fine-tune it if you really need:

nft add rule bridge vmbrfilter forward ether type arp accept

If the bridge is VLAN aware (vlan_filtering=1) or probably even if not (ie: a bridge manipulating frames and not really knowing more about them, which is probably not good if two frames from two different VLANs have the same MAC address) then here's a rule to allow ARP packets within VLAN tagged frames:

nft add rule bridge vmbrfilter forward ether type vlan vlan type arp accept

But anyway, IP will have the same kind of problem without adaptation. This requires more information of the VLAN setup.

Here's a ruleset allowing tagged and non tagged frames alike, requiring duplication of rules. ARP having no further expression to filter it thus auto-selecting the protocol/type, it requires an explicit vlan type arp.

table bridge vmbrfilter        # for idempotency
delete table bridge vmbrfilter # for idempotency

table bridge vmbrfilter {
    chain forward {
        type filter hook forward priority -100; policy drop;
        ip saddr 192.168.1.10 ip daddr 192.168.1.1 accept
        ip saddr 192.168.1.1 ip daddr 192.168.1.10 accept
        ether type arp accept

        ether type vlan ip saddr 192.168.1.10 ip daddr 192.168.1.1 accept
        ether type vlan ip saddr 192.168.1.1 ip daddr 192.168.1.10 accept
        ether type vlan vlan type arp accept
    }
}

Also older versions of nftables (eg: OP's 0.9.0) might omit mandatory filter expressions in the output when they don't have additional filters (eg, but not present in this answer: ether type vlan arp htype 1 (display truncated) vs vlan id 10 arp htype 1) , so their output should not be reused as input in configuration files. One can still tell the difference and know the additional filter expression is there by using nft -a --debug=netlink list ruleset.

As far as I know there's no support yet for arbitrary encapsulation/decapsulation of protocols in nftables, so duplication of rules appears unavoidable (just look at the bytecode to see how same fields are looked up for the VLAN and non-VLAN cases: different offset).

8
  • I added a rule to accept ARP, however traffic still does not pass as it should. I tried allowing other ether types but realised that they were accepting all the traffic going through the filter. I can now see ARP replies from the bridge (using tcpdump) but I'm not seeing them leave my physical NIC. – Synthetic Ascension Jan 30 at 10:47
  • Upon further investigation, using nft monitor to debug my rules, it seems that my VLAN tagging is not working well with my firewall rules. The final output from my physical NIC is being blocked because the ether type is both 0x0806 (ARP) and 0x8100 (802.1Q). The ARP rule allows requests in, but for some reason doesn't allow replies out. – Synthetic Ascension Jan 30 at 14:00
  • I should have thought to mention the VLAN part, sorry! I tried the htype rule and checked with nft list ruleset. The ether type vlan part disappears and the rule just becomes arp htype 1 accept. – Synthetic Ascension Jan 30 at 14:29
  • I'm using nftables 0.9.8. nftables version can change results. Anyway I found the actual syntax and changed the answer – A.B Jan 30 at 14:31
  • with ntables 0.9.8 adding ether type vlan vlan type arp acceptdecodes back the same ether type vlan vlan type arp accept. – A.B Jan 30 at 14:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.