Thermalcircle

climbing the thermals

User Tools

Site Tools

blog:linux:connection_tracking_1_modules_and_hooks

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
blog:linux:connection_tracking_1_modules_and_hooks [2022-06-23] – fixed some typos Andrej Stenderblog:linux:connection_tracking_1_modules_and_hooks [2025-10-16] (current) – INT_MAX is signed and not unsigned Andrej Stender
Line 4: Line 4:
 date created = 2021-04-04  date created = 2021-04-04 
 ~~ ~~
- 
-~~NOTOC~~ 
- 
  
 With this article series I like to take a closer look at the connection tracking subsystem of the Linux kernel, With this article series I like to take a closer look at the connection tracking subsystem of the Linux kernel,
Line 36: Line 33:
 nft add rule ip filter forward iif eth0 ct state established accept nft add rule ip filter forward iif eth0 ct state established accept
 </code> </code>
-<caption>Example, adding Nftables rules with //CONNTRACK EXPRESSIONS// to a fictive //forward// chain((Obviously you first would have to create that chain and a table ...+<caption>Example, adding Nftables rules with //CONNTRACK EXPRESSIONS// to a chain named //forward//((Obviously you first would have to create that chain and a table ...
 <code bash> <code bash>
 nft add table ip filter nft add table ip filter
Line 78: Line 75:
 ===== Netfilter hooks ===== ===== Netfilter hooks =====
 Like Iptables and Nftables, the ct system is built on top of the Netfilter framework. It implements hook functions to be able to observe network packets and registers those with the Netfilter hooks. Like Iptables and Nftables, the ct system is built on top of the Netfilter framework. It implements hook functions to be able to observe network packets and registers those with the Netfilter hooks.
-If you are not yet very familiar with Netfilter hooks, better first take a look at my other article [[nftables_packet_flow_netfilter_hooks_detail|Nftables - Packet flow and Netfilter hooks in detail]], before proceeding here. From the bird's eye view, the famous //Netfilter Packet Flow// image shown in Figure {{ref>nfpackflowofficial}} already gives a good hint on what is going on.+If you are not yet very familiar with Netfilter hooks, better first take a look at my other article [[nftables_packet_flow_netfilter_hooks_detail|Nftables - Packet flow and Netfilter hooks in detail]], before proceeding here. From the bird's eye view, the //Netfilter Packet Flow// image shown in Figure {{ref>nfpackflowofficial}}, which has been created by Netfilter developers and thereby can be considered official documentation, already gives a good hint on what is going on. 
  
 <figure nfpackflowofficial> <figure nfpackflowofficial>
Line 90: Line 87:
 Let's get back to the example above and take a look at the kernel module of the ct system itself. When the first Nftables rule containing a //CONNTRACK EXPRESSION// is being added to the ruleset of your current network namespace, the Nftables code (indirectly) triggers loading of kernel module ''nf_conntrack'' as described above, if not already loaded. After that, the Nftables code calls Let's get back to the example above and take a look at the kernel module of the ct system itself. When the first Nftables rule containing a //CONNTRACK EXPRESSION// is being added to the ruleset of your current network namespace, the Nftables code (indirectly) triggers loading of kernel module ''nf_conntrack'' as described above, if not already loaded. After that, the Nftables code calls
  ''[[https://elixir.bootlin.com/linux/v5.10.19/source/net/netfilter/nf_conntrack_proto.c#L583|nf_ct_netns_get()]]''. This is a function which is exported (=provided) by the just loaded ''nf_conntrack'' module. When called, it registers the hook functions of the ct system with the Netfilter hooks of the current network namespace.  ''[[https://elixir.bootlin.com/linux/v5.10.19/source/net/netfilter/nf_conntrack_proto.c#L583|nf_ct_netns_get()]]''. This is a function which is exported (=provided) by the just loaded ''nf_conntrack'' module. When called, it registers the hook functions of the ct system with the Netfilter hooks of the current network namespace.
-The Nftables rules shown in the example above specify //address family// ''ip''. Thus, in that case the ct system registers the four hook functions shown in Figure {{ref>nfcthooks1}} with the IPv4 Netfilter hooks. In case of //address family// ''ip6'', the ct system instead would register the same four hook functions with the Netfilter hooks of IPv6. In case of //address family// ''inet'', it would register its hook functions with both the IPv4 and the IPv6 Netfilter hooks.+The Nftables rules shown in Figure {{ref>nftctex1}} specify //address family// ''ip''. Thus, in that case the ct system registers the four hook functions shown in Figure {{ref>nfcthooks1}} with the IPv4 Netfilter hooks. In case of //address family// ''ip6'', the ct system instead would register the same four hook functions with the Netfilter hooks of IPv6. In case of //address family// ''inet'', it would register its hook functions with both the IPv4 and the IPv6 Netfilter hooks.
  
 <figure nfcthooks1> <figure nfcthooks1>
Line 103: Line 100:
  
 ==== The main ct hook functions ==== ==== The main ct hook functions ====
-The two hook functions which get registered with priority -200 in the //Prerouting// hook and in the //Output// hook in Figure {{ref>nfcthooks1}} are the very same //conntrack// hook functions shown in the official //Netfilter Packet Flow image// in Figure {{ref>nfpackflowofficial}}. Internally, both of them (nearly) do the same thing. Wrapped by some outer functions which do slightly different things, the major function called by both of them is ''[[https://elixir.bootlin.com/linux/v5.10.19/source/net/netfilter/nf_conntrack_core.c#L1793|nf_conntrack_in()]]''. Thus, the major difference between both merely is their placement... the one in the //Prerouting// hook handles packets received on the network while the one in the //Output// hook handles outgoing packets generated on this host. These two can be considered the "main" hook functions of the ct system, because most of what the ct system does with traversing network packets happens inside them... analyzing and associating packets with tracked connections, then supplying those packets with a reference (pointer) to tracked connection instances... . I'll elaborate in more detail on that in the sections below.+The two hook functions which get registered with priority -200 in the //Prerouting// hook and in the //Output// hook in Figure {{ref>nfcthooks1}} are the very same //conntrack// hook functions shown in the official //Netfilter Packet Flow image// in Figure {{ref>nfpackflowofficial}}. Internally, both of them (nearly) do the same thing. Wrapped by some outer functions which do slightly different things, the major function called by both of them is ''[[https://elixir.bootlin.com/linux/v5.10.19/source/net/netfilter/nf_conntrack_core.c#L1793|nf_conntrack_in()]]''. Thus, the major difference between both merely is their placement... the one in the //Prerouting// hook handles packets received on the network while the one in the //Output// hook handles outgoing packets generated on this host. These two can be considered the "main" hook functions of the ct system, because most of what the ct system does with traversing network packets happens inside them... analyzing and associating packets with tracked connections, then supplying those packets with a reference (pointer) to tracked connection instances... . I'll elaborate on that in more detail in the sections below.
  
  
Line 109: Line 106:
 Another two hook functions get registered with MAX priority in the //Input// Another two hook functions get registered with MAX priority in the //Input//
 hook and in the //Postrouting// hook in Figure {{ref>nfcthooks1}}. Priority hook and in the //Postrouting// hook in Figure {{ref>nfcthooks1}}. Priority
-MAX means the highest possible unsigned integer value. A hook function with this+MAX means the highest possible signed integer value. A hook function with this
 priority will be traversed as the very last one within the Netfilter hook and no priority will be traversed as the very last one within the Netfilter hook and no
 other hook function can get registered to be traversed after it. Those two hook functions other hook function can get registered to be traversed after it. Those two hook functions
Line 139: Line 136:
  
 ===== Modules nf_defrag_ipv4/6 ===== ===== Modules nf_defrag_ipv4/6 =====
-As shown above, module ''nf_conntrack'' depends on the modules ''nf_defrag_ipv4'' and ''nf_defrag_ipv6''. What is important to know here is, that those take care about re-assembling (=defragment) IPv4 and IPv6 fragments respectively, if those occur. Usually, defragmentation is supposed to happen at the receiving communication endpoint and not along the way through the hops between both endpoints. However, in this case it is necessary.  Connection tracking can only do its job, if ALL packets of a connection can be identified and no packet can slip through the fingers of the ct system. The problem with fragments is, that they do not all contain the necessary protocol header information which would be required to identify and associate them with a tracked connection.+As shown in Figure {{ref>nft_ct_depends}}, module ''nf_conntrack'' depends on the modules ''nf_defrag_ipv4'' and ''nf_defrag_ipv6''. What is important to know here is, that those take care about re-assembling (=defragment) IPv4 and IPv6 fragments respectively, if those occur. Usually, defragmentation is supposed to happen at the receiving communication endpoint and not along the way through the hops between both endpoints. However, in this case it is necessary.  Connection tracking can only do its job, if ALL packets of a connection can be identified and no packet can slip through the fingers of the ct system. The problem with fragments is, that they do not all contain the necessary protocol header information required to identify and associate them with a tracked connection.
  
 <figure nfdefraghooks1> <figure nfdefraghooks1>
Line 182: Line 179:
 ===== How it works... ===== ===== How it works... =====
 I know... so far I kept beating around the bush. Now let's finally talk about how the ct system actually operates and what it does to network packets traversing its hook functions. Please be aware that what I describe in this section are the basics and does not cover all what the ct system actually does. The ct system maintains the connections which it is tracking in a central table. Each tracked connection is represented by an instance of ''[[https://elixir.bootlin.com/linux/v5.10.19/source/include/net/netfilter/nf_conntrack.h#L58|struct nf_conn]]''. That structure contains all necessary details the ct system learns about the connection over time while tracking it. From the ct system's point of view, every network packet which traverses one of its main hook functions (those with priority -200) is one of four possible things: I know... so far I kept beating around the bush. Now let's finally talk about how the ct system actually operates and what it does to network packets traversing its hook functions. Please be aware that what I describe in this section are the basics and does not cover all what the ct system actually does. The ct system maintains the connections which it is tracking in a central table. Each tracked connection is represented by an instance of ''[[https://elixir.bootlin.com/linux/v5.10.19/source/include/net/netfilter/nf_conntrack.h#L58|struct nf_conn]]''. That structure contains all necessary details the ct system learns about the connection over time while tracking it. From the ct system's point of view, every network packet which traverses one of its main hook functions (those with priority -200) is one of four possible things:
-  - It is either is part of or related to one of its tracked connections. +  - It is either part of or related to one of its tracked connections. 
-  - It is the first packet of a new connection which is not yet tracked.+  - It is the first seen packet of a connection which is not yet tracked.
   - It is an invalid packet, which is broken or doesn't fit in somehow.   - It is an invalid packet, which is broken or doesn't fit in somehow.
   - It is marked as NOTRACK, which tells the ct system to ignore it.   - It is marked as NOTRACK, which tells the ct system to ignore it.
Line 219: Line 216:
 being the first one representing a new connection which is not yet tracked by the ct system. being the first one representing a new connection which is not yet tracked by the ct system.
 When that packet traverses the main //conntrack// hook function (the one with priority -200), let's assume that When that packet traverses the main //conntrack// hook function (the one with priority -200), let's assume that
-it passes the already mentioned validity checks. However, in this case the lookup in the ct table (1) does not find a matching connection. As a result, the ct system considers the packet to be the first one of a new connection. A new instance of ''struct nf_conn'' is created (2) and member ''%%skb->_nfct%%'' of the packet is initialized to point to that instance. The ct system considers the new connection as "unconfirmed" at this point. Thus, the new connection instance is not yet being added to the central table. It is temporarily parked on the so-called //unconfirmed list//. +it passes the already mentioned validity checks. However, in this case the lookup in the ct table (1) does not find a matching connection. As a result, the ct system considers the packet to be the first one of a new connection((To be precise: The first one the ct system has //seen// from that connection. That does not necessarily mean that this always must be the actual very first packet of a new connection, because there might be cases where the ct system for whatever reason did not see the first few packets of an actual connection and kind-of starts tracking in the middle of an already existing connection.)). A new instance of ''struct nf_conn'' is created (2) and member ''%%skb->_nfct%%'' of the packet is initialized to point to that instance. The ct system considers the new connection as "unconfirmed" at this point. Thus, the new connection instance is not yet being added to the central table. It is temporarily parked on the so-called //unconfirmed list//. 
 Further, the OSI layer 4 protocol of the packet is now being analyzed and protocol state and details are saved to its tracked connection instance. Then the packet continues on its way through other hook functions and the network stack.  Further, the OSI layer 4 protocol of the packet is now being analyzed and protocol state and details are saved to its tracked connection instance. Then the packet continues on its way through other hook functions and the network stack. 
 Figure {{ref>nfct-new}} also shows an example Nftables chain with priority 0 in the //Prerouting// hook. If you would place a rule with expression ''ct state new'' in that chain, it would match. Figure {{ref>nfct-new}} also shows an example Nftables chain with priority 0 in the //Prerouting// hook. If you would place a rule with expression ''ct state new'' in that chain, it would match.
Line 225: Line 222:
 But even if a client, who is trying to establish e.g. a TCP connection by sending a TCP SYN packet, is behaving normally, it would still send out several TCP SYN packets as retransmissions if it does not receive any reply from the peer side. Thus, if you have a ''ct state new drop'' rule in place, this mechanism ensures, that the ct system intentionally does not remember this (denied!) connection and thereby treats all succeeding TCP SYN packets (retransmissions) again as new packets and those then will be dropped by the same ''ct state new drop'' rule. But even if a client, who is trying to establish e.g. a TCP connection by sending a TCP SYN packet, is behaving normally, it would still send out several TCP SYN packets as retransmissions if it does not receive any reply from the peer side. Thus, if you have a ''ct state new drop'' rule in place, this mechanism ensures, that the ct system intentionally does not remember this (denied!) connection and thereby treats all succeeding TCP SYN packets (retransmissions) again as new packets and those then will be dropped by the same ''ct state new drop'' rule.
  
-The third possibility is, that the ct system considers a packet as //invalid//. This e.g. happens, when a packet does not pass the mentioned initial validity checks of the main conntrack hook function in the //Prerouting// hook in Figure {{ref>nfct-lookup}} or {{ref>nfct-new}}, e.g. because of a broken or incomplete protocol header which cannot not be parsed. This further can happen when a packet fails the detailed analysis of its OSI layer 4 protocol. E.g. in case of TCP the ct system observes receive window and sequence numbers and a packet which does not match regarding its sequence numbers would be considered //invalid//.+The third possibility is, that the ct system considers a packet as //invalid//. This e.g. happens, when a packet does not pass the mentioned initial validity checks of the main conntrack hook function in the //Prerouting// hook in Figure {{ref>nfct-lookup}} or {{ref>nfct-new}}, e.g. because of a broken or incomplete protocol header which cannot be parsed. This further can happen when a packet fails the detailed analysis of its OSI layer 4 protocol. E.g. in case of TCP the ct system observes receive window and sequence numbers and a packet which does not match regarding its sequence numbers would be considered //invalid//.
 However, it is not the job of the ct system to drop invalid packets((However, there are a few rare cases, like an overflow of the ct table, where it indeed drops packets.)). The ct system leaves that decision to other parts of the kernel network stack. If it considers a packet as //invalid//, the ct system simply leaves ''%%skb->_nfct=NULL%%''. If you would place an Nftables rule with expression ''ct state invalid'' in the example chain in Figure {{ref>nfct-lookup}} or {{ref>nfct-new}}, then that rule would match. However, it is not the job of the ct system to drop invalid packets((However, there are a few rare cases, like an overflow of the ct table, where it indeed drops packets.)). The ct system leaves that decision to other parts of the kernel network stack. If it considers a packet as //invalid//, the ct system simply leaves ''%%skb->_nfct=NULL%%''. If you would place an Nftables rule with expression ''ct state invalid'' in the example chain in Figure {{ref>nfct-lookup}} or {{ref>nfct-new}}, then that rule would match.
  
Line 286: Line 283:
  
  
-//published 2021-04-04//, //last modified 2022-06-23//+//published 2021-04-04//, //last modified 2025-10-16//
  
blog/linux/connection_tracking_1_modules_and_hooks.1655983588.txt.gz · Last modified: 2022-06-23 by Andrej Stender