tcpdump output changes after restarting nftable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello netfilter community,

On my system, I have an ethernet network eth0 and a bridge eth0_bridge
and several vlan interfaces(vlan.x) assigned to eth0.

OS: Ubuntu 22.04.1 LTS
kernel: 5.15.0-43
tcpdump: 4.99.1
nftable: 1.0.2-1ubuntu2

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 run the 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
verify the nftable rule
in this case?

Best regards,
You-Yu Lu




[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux