Thank you very much for all the answers. Now I understand the reason for the dependency in the nftables unit file. Maybe I should explain my question or my problem properly. On my system, I have an ethernet network eth0 and a bridge eth0_bridge and several vlan interfaces(vlan.x) assigned to eth0. The problem that I am facing is that the behavior of tcpdump on eth0 is inconsistent before and after I restart the nftables.service. This is the rule that I have to redirect the destination of the vlan tagged packets coming from VLAN interfaces. iifname vlan.1 ip protocol udp ip daddr set $dst_ip udp dport set $dst_port1 iifname vlan.2 ip protocol udp ip daddr set $dst_ip udp dport set $dst_port2 iifname vlan.3 ip protocol udp ip daddr set $dst_ip udp dport set $dst_port3 iifname vlan.4 ip protocol udp ip daddr set $dst_ip udp dport set $dst_port4 After a reboot, the ruleset is applied properly when I ran nft list ruleset and tcpdump(tcpdump -nei eth0) captures the raw UDP packets that are not redirected. vlan 1, x.x.x.x.12345 > x.x.x.x.54321: UDP vlan 2, x.x.x.x.12345 > x.x.x.x.54321: UDP vlan 3, x.x.x.x.12345 > x.x.x.x.54321: UDP vlan 4, x.x.x.x.12345 > x.x.x.x.54321: UDP However, after I restart the nftables.service manually(basically flush and reload the rules), the output of exactly the same tcpdump command on eth0 looks different. It seems like tcpdump is getting the redirected packets with $dst_ip, $dst_port, but it looks random and does not match the 1-1 correspondence in the nft rules. vlan 1, x.x.x.x.12345 > $dst_ip.$dst_port3: UDP vlan 2, x.x.x.x.12345 > $dst_ip.$dst_port3: UDP vlan 3, x.x.x.x.12345 > $dst_ip.$dst_port1: UDP vlan 4, x.x.x.x.12345 > $dst_ipx.$dst_port1: UDP vlan 1, x.x.x.x.12345 > $dst_ip.$dst_port1: UDP vlan 2, x.x.x.x.12345 > $dst_ip.$dst_port4: UDP vlan 3, x.x.x.x.12345 > $dst_ip.$dst_port4: UDP vlan 4, x.x.x.x.12345 > $dst_ipx.$dst_port2: UDP On the other hand, if I listen to eth0_bridge, the tcpdump output is consistent before and after nftables.service and I am getting the correct 1-1 match according to the nft ruleset. Does this behavior make sense? Or is tcpdump not the right tool to use in this case? Best regards, You-Yu Lu On Fri, 1 Dec 2023 at 12:50, You Yu Lu <zxc70208@xxxxxxxxx> wrote: > > Hello netfilter community, > > I have a question regarding the dependency of nftables.service. > OS version: Ubuntu 22.04.1 LTS > nftable package version: 1.0.2-1ubuntu2 > > In the default nftables.service unit file, it has a default dependency > that it needs to be started before network-pre.target at boot. Based > on my understanding, nftable rule are loaded before the network > interfaces are configured. > # /lib/systemd/system/nftables.service > [Unit] > Description=nftables > Documentation=man:nft(8) http://wiki.nftables.org > Wants=network-pre.target > Before=network-pre.target shutdown.target > Conflicts=shutdown.target > DefaultDependencies=no > > What is the reason to start nftable service before networkd configured > by default? > Is this the intended behavior for nftable? Or is it fine to modify the > service unit file and change the dependency to fit different use > cases? > > Thank you in advance. > > Best regards, > You-Yu Lu
