* nftables drops related traffic
@ 2020-06-13 21:21 Robin Kuiper
2020-06-14 1:17 ` kfm
0 siblings, 1 reply; 3+ messages in thread
From: Robin Kuiper @ 2020-06-13 21:21 UTC (permalink / raw)
To: netfilter
Hi,
I'm running into an issue where nftables drops all related traffic,
even if it should accept it.
When using, for example, an [archwiki example nftables ruleset][1] it
contains the line `ct state established,related accept`. This is
supposed to accept related and established traffic.
Established works: otherwise, I wouldn't be able to browse the web!
Related however, doesn't appear to work.
My proof is my TFTP server: if you [look at the protocol][2], its a
simple example of related traffic. However, it only works when my
firewall is disabled. TCPdumping the server shows that my server sends
the data packet, but never receives an ACK. ([wiki example][2] image
R2/R3)
Any help would be greatly appreciated!
[1]: https://wiki.archlinux.org/index.php/Nftables#Workstation
[2]:
https://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol#Details
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: nftables drops related traffic
2020-06-13 21:21 nftables drops related traffic Robin Kuiper
@ 2020-06-14 1:17 ` kfm
2020-06-14 8:38 ` Robin Kuiper
0 siblings, 1 reply; 3+ messages in thread
From: kfm @ 2020-06-14 1:17 UTC (permalink / raw)
To: Robin Kuiper, netfilter
On 13/06/2020 22:21, Robin Kuiper wrote:
> Hi,
>
> I'm running into an issue where nftables drops all related traffic,
> even if it should accept it.
>
> When using, for example, an [archwiki example nftables ruleset][1] it
> contains the line `ct state established,related accept`. This is
> supposed to accept related and established traffic.
>
> Established works: otherwise, I wouldn't be able to browse the web!
> Related however, doesn't appear to work.
>
> My proof is my TFTP server: if you [look at the protocol][2], its a
> simple example of related traffic. However, it only works when my
It's not so simple. Note that the TFTP reply packet "[...] is sent from
a randomly allocated ephemeral port, and all future packets to host S
should be directed to this port." This is sufficient to defeat the
rudimentary connection tracking that Netfilter implements for UDP, which
is, after all, a stateless protocol.
If you want to be able to rely exclusively on the related ct_state to
allow such packets to pass, check that your kernel has
CONFIG_NF_CONNTRACK_TFTP enabled. It's usually enabled as a loadable
kernel module so, if you are able to "modprobe nf_conntrack_tftp" and
observe that the module is listed by "lsmod", you should be in good
standing.
The other thing you should know is that nftables has a specific syntax
to register connection tracking helpers and to attach them to a given
rule. The man page contains an example for FTP, which should be
straightforward to adapt:
https://git.netfilter.org/nftables/tree/doc/stateful-objects.txt#n29
The alternative course of action would be define a rule that allows all
inbound UDP traffic from the TFTP server in question, perhaps within the
bounds of the supported port range.
> firewall is disabled. TCPdumping the server shows that my server sends
> the data packet, but never receives an ACK. ([wiki example][2] image
> R2/R3)
>
> Any help would be greatly appreciated!
>
>
> [1]: https://wiki.archlinux.org/index.php/Nftables#Workstation
> [2]:
> https://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol#Details
>
--
Kerin Millar
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: nftables drops related traffic
2020-06-14 1:17 ` kfm
@ 2020-06-14 8:38 ` Robin Kuiper
0 siblings, 0 replies; 3+ messages in thread
From: Robin Kuiper @ 2020-06-14 8:38 UTC (permalink / raw)
To: kfm, netfilter
On Sun, 2020-06-14 at 02:17 +0100, kfm@plushkava.net wrote:
> If you want to be able to rely exclusively on the related ct_state
> to
> allow such packets to pass, check that your kernel has
> CONFIG_NF_CONNTRACK_TFTP enabled. It's usually enabled as a loadable
> kernel module so, if you are able to "modprobe nf_conntrack_tftp"
> and
> observe that the module is listed by "lsmod", you should be in good
> standing.
>
> The other thing you should know is that nftables has a specific
> syntax
> to register connection tracking helpers and to attach them to a
> given
> rule. The man page contains an example for FTP, which should be
> straightforward to adapt:
>
> https://git.netfilter.org/nftables/tree/doc/stateful-objects.txt#n29
Both solutions worked, but for both I needed to enable helpers by
running `sysctl net/netfilter/nf_conntrack_helper=1`, as specified in:
https://wiki.nftables.org/wiki-nftables/index.php/Setting_packet_connection_tracking_metainformation
Thanks for your help!
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-06-14 8:38 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-13 21:21 nftables drops related traffic Robin Kuiper
2020-06-14 1:17 ` kfm
2020-06-14 8:38 ` Robin Kuiper
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.