0

Given the move by many Linux distros from iptables to nftables as default, I am looking to migrate my iptables rules.

I have a Ubuntu server that has two bridges (mainly to accommodate VMs and LXD containers that I run on the server). Both are created in netplan.

The physical NIC eth0 (untagged VLAN10) is bridged in br0. br0 gets an IP in VLAN10. eth0 gets no IP.

VLAN66 (tagged) has separately been configured on eth0, and bridged in br66. No IP is configured on br66 (or VLAN66).

At the moment (being lazy) I have the br_netfilter module loaded so that all filtering is done in iptables, in the standard input, forward, and output chains in the filter table. This is so I can avoid having to separately configure ebtables.

Looking at nftables, I understand this lazy approach won’t work, because bridge filtering happens through a separate family.

My question is: given the interfaces on the server are all bridged, should the main focus of my nftables rules be in the bridge family? So all the rules that are currently configured in the filter table in iptables should be replicated in the bridge family, rather than in the ip/ip6/inet families? Or does there need to be a mix, and if so how is that divided?

Sorry if this is a dumb question.

Edit: Config information added. The veth interfaces are for LXD containers.

netplan:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: false
      dhcp6: false
  bridges:
    br0:
      interfaces: [ eth0 ]
      macaddress: xx:xx:xx:xx:xx:94
      dhcp4: true
      dhcp6: true
      parameters:
        forward-delay: 0
        stp: false
    br66:
      interfaces: [ vlan66 ]
      macaddress: xx:xx:xx:xx:xx:8d
      dhcp4: false
      dhcp6: false
      link-local: [ ]
      accept-ra: false
      parameters:
        forward-delay: 0
        stp: false
  vlans:
    vlan66:
      id: 66
      link: eth0
      dhcp4: false
      dhcp6: false

ip a:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:ee brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:94 brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.10/24 brd 10.10.10.255 scope global dynamic br0
       valid_lft 5022sec preferred_lft 5022sec
    inet6 fdfd:2553:8868:10:xxxx:xxxx:xxxx:xx94/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 86361sec preferred_lft 14361sec
    inet6 2403:xxxx:xxxx:xx10:xxxx:xxxx:xxxx:xx94/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 86361sec preferred_lft 14361sec
    inet6 fe80::xxxx:xxxx:xxxx:xx94/64 scope link 
       valid_lft forever preferred_lft forever
4: br66: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:8d brd ff:ff:ff:ff:ff:ff
5: vlan66@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br66 state UP group default qlen 1000
    link/ether 2c:4d:54:d2:84:ee brd ff:ff:ff:ff:ff:ff
7: veth940fee62@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br66 state UP group default qlen 1000
    link/ether e6:40:d8:1f:7b:93 brd ff:ff:ff:ff:ff:ff link-netnsid 0
9: vethff4da3d7@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br66 state UP group default qlen 1000
    link/ether 3a:ba:7e:c8:49:20 brd ff:ff:ff:ff:ff:ff link-netnsid 1
11: veth0d67113a@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br66 state UP group default qlen 1000
    link/ether 86:65:7f:bc:a0:c6 brd ff:ff:ff:ff:ff:ff link-netnsid 2
13: veth22f981e6@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br66 state UP group default qlen 1000
    link/ether 92:93:15:f6:ed:09 brd ff:ff:ff:ff:ff:ff link-netnsid 3
15: veth1d23d0ca@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br66 state UP group default qlen 1000
    link/ether 6e:8a:7d:48:0a:08 brd ff:ff:ff:ff:ff:ff link-netnsid 4

brctl show:

bridge name     bridge id               STP enabled     interfaces
br0             8000.xxxxxxxxxx94       no              eth0
br66            8000.xxxxxxxxxx8d       no              veth0d67113a
                                                        veth1d23d0ca
                                                        veth22f981e6
                                                        veth940fee62
                                                        vethff4da3d7
                                                        vlan66
Improve this question
5
  • Is your current config in iptables too large to post?
    – number9
    Apr 9, 2021 at 14:30
  • Probably 250 lines for each of iptables and ip6tables? But I’m not sure how important the content is as opposed to getting an understanding of how nftables processes packets in a bridged setup like mine. I can provide more info on the netplan, ip and bridge configs if that helps?
    – Greelan
    Apr 10, 2021 at 4:22
  • Network config information now added to initial post.
    – Greelan
    Apr 11, 2021 at 1:07
  • Actually, while it's not very much documented (because upstream wants to get rid of br_netfilter), br_netfilter has the same effect on nftables as it does on iptables. The main change is after kernel 5.3 where you can use conntrack from bridge path + nftables' bridge family rules directly (not from the bridge path with frames temporarily converted into packets for processing by iptables or nftables in the ip family) and where it would be ill advised to use both at same time. Of course iptables-nft (which you might even be using without knowing) is also affected.
    – A.B
    Apr 17, 2021 at 13:11
  • Thanks for the information. My preference would be to move away from the br_netfilter “hack”, and utilise the inbuilt functionality in nftables, particularly now that conntrack is available in the bridge family. So I just need to get an understanding of how nftables handles packets in a setup like mine so I can construct my rules accordingly. Unfortunately the good packet flow diagrams that are around are centred around iptables.
    – Greelan
    Apr 24, 2021 at 0:24

1 Answer 1

Reset to default
1

Someone in another forum pointed me to this very helpful nftables packet flow diagram:

packet flow diagram

This has helped me greatly in sorting my thinking. I haven’t finalised the rules yet but my thinking is that rules for packets that cross a bridge between member interfaces will go in the forward chain in the bridge family, and then the rules for packets from a bridge interface to the local host will go in the input chain in the inet family and rules for packets between bridges will go in the forward chain in the inet family.

Improve this answer

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.