All of lore.kernel.org
 help / color / mirror / Atom feed
* 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.