From: You Yu Lu <zxc70208@gmail.com>
To: netfilter@vger.kernel.org
Subject: tcpdump output changes after restarting nftable
Date: Tue, 12 Dec 2023 21:13:46 +0100 [thread overview]
Message-ID: <CAA=+Qij3_FY==-OtG-qoY8b9ZwGyXYCt9Gt+LDn8xPO2caf9og@mail.gmail.com> (raw)
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
reply other threads:[~2023-12-12 20:14 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA=+Qij3_FY==-OtG-qoY8b9ZwGyXYCt9Gt+LDn8xPO2caf9og@mail.gmail.com' \
--to=zxc70208@gmail.com \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).