This tracking is usually implemented as a big table, with at least 6 columns: protocol (usually TCP or UDP), source IP, source port, destination IP, destination port and connection state. To fill such gaps all the operating systems implemented connection tracking inside their firewalls. The canonical example is assessment of ACK packets - it's impossible to say if an ACK packet is legitimate or part of a port scanning attempt, without tracking the connection state. You see, there are certain things that can't be expressed in a stateless way. The stateless design gave some basic network security, but was quickly deemed insufficient. They could express only basic logic, like: allow SYN packets to port 80 and 443, and block everything else.

To put that into perspective: early firewalls were entirely stateless. 'Conntrack' is a part of Linux network stack, specifically part of the firewall subsystem. But we weren't confident - can we just enable conntrack and move on? How does it actually work? I volunteered to help the team understand the dark corners of the 'conntrack' subsystem. One of our new products had a reasonable need for it. This brought great benefits - it simplified our iptables firewall setup, sped up the system a bit and made the inbound packet path easier to understand.īut eventually our needs changed. For example, years ago we decided to avoid using Linux's 'conntrack' - stateful firewall facility. Their needs often challenge the architectural assumptions we made in the past. At Cloudflare we develop new products at a great pace.

Iptables examples