Nftables families - Revision history

Pablo: /* inet */ typo

2024-05-29T17:13:46Z

inet: typo

← Older revision		Revision as of 17:13, 29 May 2024
Line 19:		Line 19:
	Tables of this family see both IPv4 and IPv6 traffic/packets, simplifying dual stack support.		Tables of this family see both IPv4 and IPv6 traffic/packets, simplifying dual stack support.

	Within a table of ''inet'' family, both IPv4 and IPv6 packets traverse the same rules. Rules for IPv4 packets don't affect IPv6 packets and vice-versa. Rules for both layer 3 protocols affect both. Use [[Matching_packet_headers#Matching_transport_protocol\|meta l4proto]] to match on the layer 4 protocol regardless the packet is ~~either~~ IPv4 or IPv6.		Within a table of ''inet'' family, both IPv4 and IPv6 packets traverse the same rules. Rules for IPv4 packets don't affect IPv6 packets and vice-versa. Rules for both layer 3 protocols affect both. Use [[Matching_packet_headers#Matching_transport_protocol\|meta l4proto]] l4proto to match on the layer 4 protocol, regardless of whether the packet is IPv4 or IPv6.

	Examples:		Examples:

Fw: inet ingress was added in d3519cb89f6d (v5.10-rc1)

2024-05-29T11:41:34Z

inet ingress was added in d3519cb89f6d (v5.10-rc1)

← Older revision		Revision as of 11:41, 29 May 2024
Line 34:		Line 34:
	</source>		</source>

	New in nftables 0.9.7 and Linux kernel 4.10 is the inet family [[Netfilter_hooks\|''ingress'']] hook, which filters at the same location as the netdev ''ingress'' hook.		New in nftables 0.9.7 and Linux kernel 5.10 is the inet family [[Netfilter_hooks\|''ingress'']] hook, which filters at the same location as the netdev ''ingress'' hook.

	== arp ==		== arp ==

Pablo: /* inet */ refer to meta l4proto

2021-07-23T16:19:05Z

inet: refer to meta l4proto

← Older revision		Revision as of 16:19, 23 July 2021
Line 19:		Line 19:
	Tables of this family see both IPv4 and IPv6 traffic/packets, simplifying dual stack support.		Tables of this family see both IPv4 and IPv6 traffic/packets, simplifying dual stack support.

	Within a table of ''inet'' family, both IPv4 and IPv6 packets traverse the same rules. Rules for IPv4 packets don't affect IPv6 packets. Rules for both L3 protocols affect both.		Within a table of ''inet'' family, both IPv4 and IPv6 packets traverse the same rules. Rules for IPv4 packets don't affect IPv6 packets and vice-versa. Rules for both layer 3 protocols affect both. Use [[Matching_packet_headers#Matching_transport_protocol\|meta l4proto]] to match on the layer 4 protocol regardless the packet is either IPv4 or IPv6.

	Examples:		Examples:

Fmyhr: "base chain hook" -> "hook", because flowtables also use hooks

2021-03-08T08:26:52Z

"base chain hook" -> "hook", because flowtables also use hooks

← Older revision		Revision as of 08:26, 8 March 2021
Line 1:		Line 1:
	[https://netfilter.org/ Netfilter] enables filtering at multiple [https://en.wikipedia.org/wiki/Internet_protocol_suite networking levels]. With iptables there is a separate tool for each level: ''iptables'', ''ip6tables'', ''arptables'', ''ebtables''. With nftables the multiple networking levels are abstracted into '''families''', all of which are served by the single tool ''nft''.		[https://netfilter.org/ Netfilter] enables filtering at multiple [https://en.wikipedia.org/wiki/Internet_protocol_suite networking levels]. With iptables there is a separate tool for each level: ''iptables'', ''ip6tables'', ''arptables'', ''ebtables''. With nftables the multiple networking levels are abstracted into '''families''', all of which are served by the single tool ''nft''.

	Please note that what traffic/packets you see and at which point in the network stack depends on the ~~[[Configuring_chains#Adding_base_chains\|'''base chain''']]~~ [[Netfilter_hooks\|'''hook''']] you are using.		Please note that what traffic/packets you see and at which point in the network stack depends on the [[Netfilter_hooks\|'''hook''']] you are using.

	Following are descriptions of current nftables families. Additional families may be added in the future.		Following are descriptions of current nftables families. Additional families may be added in the future.

Fmyhr: /* inet */ Added note about new inet ingress hook.

2021-02-24T00:54:10Z

inet: Added note about new inet ingress hook.

← Older revision		Revision as of 00:54, 24 February 2021
Line 33:		Line 33:
	add rule inet filter input udp dport 53 accept		add rule inet filter input udp dport 53 accept
	</source>		</source>

			New in nftables 0.9.7 and Linux kernel 4.10 is the inet family [[Netfilter_hooks\|''ingress'']] hook, which filters at the same location as the netdev ''ingress'' hook.

	== arp ==		== arp ==

Fmyhr: /* netdev */ Edited for clarity, emphasized that netdev is per interface.

2021-02-22T16:22:41Z

netdev: Edited for clarity, emphasized that netdev is per interface.

← Older revision		Revision as of 16:22, 22 February 2021
Line 48:		Line 48:
	== netdev ==		== netdev ==

	~~This~~ family ~~provides~~ the ~~ingress hook,~~ that ~~allows you~~ to ~~classify packets that the driver has just passed up~~ to ~~the networking stack~~. ~~This means you~~ see '''all''' network traffic ~~for your NIC getting in. No~~ assumptions ~~are made~~ about L2 or L3 protocols~~, therefore~~ you can filter ARP traffic from here.		The ''netdev'' family is different from the others in that it is used to create base chains attached to a '''single network interface'''. Such base chains see '''all''' network traffic on the specified interface, with no assumptions about L2 or L3 protocols. Therefore you can filter ARP traffic from here. There is no legacy x_tables equivalent to the ''netdev'' family.

	~~Note that there~~ is ~~no equivalent in~~ the ~~old iptables world~~, ~~this is a~~ new ~~feature available since~~ Linux kernel 4.2 for ~~nftables~~.		The principal (only?) use for this family is for base chains using the [[Netfilter_hooks\|''ingress'' hook]], new in Linux kernel 4.2. Such ''ingress'' chains see network packets just after the NIC driver passes them up to the networking stack. This very early location in the packet path is ideal for dropping packets associated with [https://en.wikipedia.org/wiki/Denial-of-service_attack#Distributed_attack DDoS] attacks. Dropping packets from an ''ingress'' chain is twice as efficient as doing so from a ''prerouting'' chain. (Do note that in an ''ingress'' chain, fragmented datagrams have not yet been reassembled. So, for example, matching ip saddr and daddr works for all ip packets, but matching L4 headers like udp dport works only for unfragmented packets, or the first fragment.)

	~~This location is ideal~~ to ~~drop packets that result from DDOS attacks given this is very early in the packet path~~. ~~Dropping packets from here is much more efficient than from the classic prerouting chain, by a factor of 2x~~.		The ''ingress'' hook provides an alternative to ''tc'' ingress filtering. You still need ''tc'' for traffic shaping/queue management.

	You can also use ~~this new~~ ingress hook for [[load balancing]], including Direct Server Return (DSR), [https://netdevconf.org/1.2/slides/oct6/08_nftables_Load_Balancing_with_nftables_II_Slides.pdf that has been reported to be 10x faster].		You can also use the ''ingress'' hook for [[load balancing]], including Direct Server Return (DSR), [https://netdevconf.org/1.2/slides/oct6/08_nftables_Load_Balancing_with_nftables_II_Slides.pdf that has been reported to be 10x faster].

Fmyhr: /* bridge */

2021-02-22T15:45:30Z

bridge

← Older revision		Revision as of 15:45, 22 February 2021
Line 40:		Line 40:
	== bridge ==		== bridge ==

	Tables of this family ~~will~~ see traffic/packets traversing bridges (i.e. switching). No assumptions are made about L3 protocols.		Tables of this family see traffic/packets traversing [https://wiki.linuxfoundation.org/networking/bridge bridges] (i.e. switching). No assumptions are made about L3 protocols.
	~~The ebtables tool was the equivalent in the old x_tables world.~~
	~~Also, some old x_tables modules such as ''physdev'' will eventually be served natively from this family~~.

	Note that there is no nf_conntrack integration for ~~this~~ family~~. However this may change in the future~~.		The ''ebtables'' tool is the legacy x_tables equivalent. Some old x_tables modules such as ''physdev'' will also eventually be served from the nftables ''bridge'' family.

			Note that there is no nf_conntrack integration for the nftables ''bridge'' family.

	== netdev ==		== netdev ==

Fmyhr: /* arp */ Linked Wikipedia ARP page, edited for clarity.

2021-02-22T15:38:16Z

arp: Linked Wikipedia ARP page, edited for clarity.

← Older revision		Revision as of 15:38, 22 February 2021
Line 36:		Line 36:
	== arp ==		== arp ==

	Tables of this family ~~will~~ see ARP-level (i.e, L2) traffic, before any L3 handling is done by the kernel.		Tables of this family see [https://en.wikipedia.org/wiki/Address_Resolution_Protocol ARP]-level (i.e, L2) traffic, before any L3 handling is done by the kernel. The ''arptables'' tool is the legacy x_tables equivalent.
	The arptables tool ~~was~~ the equivalent ~~in the old x_tables world~~.

	== bridge ==		== bridge ==

Fmyhr: /* inet */ Edited for clarity.

2021-02-22T15:33:50Z

inet: Edited for clarity.

← Older revision		Revision as of 15:33, 22 February 2021
Line 17:		Line 17:
	== inet ==		== inet ==

	Tables of this family ~~will~~ see both IPv4/IPv6 traffic/packets, ~~designed to improve~~ dual stack support.		Tables of this family see both IPv4 and IPv6 traffic/packets, simplifying dual stack support.
	~~Mixing iptables and ip6tables rules in the same box was the equivalent in the old x_tables world~~.

	~~Both~~ IPv4/IPv6 packets ~~will~~ traverse the same rules. Rules for IPv4 packets ~~won~~'t affect IPv6 packets.		Within a table of ''inet'' family, both IPv4 and IPv6 packets traverse the same rules. Rules for IPv4 packets don't affect IPv6 packets. Rules for both L3 protocols affect both.
	Rules for both L3 ~~protocol will~~ affect both.

	Examples:		Examples:
	<source>		<source>
	# ~~this~~ rule only ~~affects~~ IPv4 packets		# This rule affects only IPv4 packets:
	add rule inet filter input ip saddr 1.1.1.1 counter accept		add rule inet filter input ip saddr 1.1.1.1 counter accept
	# ~~this~~ rule only ~~affects~~ IPv6 packets
			# This rule affects only IPv6 packets:
	add rule inet filter input ip6 daddr fe00::2 counter accept		add rule inet filter input ip6 daddr fe00::2 counter accept
	# ~~these~~ rules ~~affects~~ both IPv4/IPv6 packets
			# These rules affect both IPv4 and IPv6 packets:
	add rule inet filter input ct state established,related counter accept		add rule inet filter input ct state established,related counter accept
	add rule inet filter input udp dport 53 accept		add rule inet filter input udp dport 53 accept

Fmyhr: /* ip6 */ Linked Wikipedia IPv6 page, lightly edited for clarity.

2021-02-22T15:23:39Z

ip6: Linked Wikipedia IPv6 page, lightly edited for clarity.

← Older revision		Revision as of 15:23, 22 February 2021
Line 12:		Line 12:
	== ip6 ==		== ip6 ==

	Tables of this family ~~will~~ see IPv6 traffic/packets.		Tables of this family see [https://en.wikipedia.org/wiki/IPv6 IPv6] traffic/packets.
	The ip6tables tool ~~was~~ the equivalent ~~in the old x_tables world~~.		The ''ip6tables'' tool is the legacy x_tables equivalent.

	== inet ==		== inet ==