Constraints on nft expressions and statements in inet ingress chains

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

 



Hi,

Since nftables 0.9.7 and kernel 5.10 we have inet ingress chains. It's great to now be able to share sets and maps among ingress and other inet chains!

I'm wondering about constraints on nft expressions and statements that can be used in inet ingress chains?

Some clearly make no sense, like:
- anything involving an output interface
- anything related to conntrack (I think)
- packet mark (I think)

Not sure about:
- reject statement (pretty sure not)
- ah & esp header expressions?
- raw payload expression?
- extension header expressions?

Seem to work, but are they a good idea this early in processing?:
- tcp header & udp header expressions? If IP datagrams are fragmented, these matches will miss all but first fragment, correct? (Since defragmentation doesn't happen until prerouting?)

My general impression is that inet ingress filtering on L3 IPv4 and IPv6 header expressions like ip saddr, ip daddr is okay, but trying to reach into L4 so early will be problematic...

Thanks for your comments / correction / clarification!

Thanks,
Frank



[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