5 Tuple Firewall
You set up a 5 tuple firewall by writing rules that match five packet values. Those values are source IP, destination IP, source port, destination port, and protocol. Network teams use these rules to control traffic between subnets, servers, and cloud networks. Still, broad port and IP rules often allow too much access once a packet passes. How a 5 tuple firewall inspects network packets Every network packet carries a header with basic routing facts. The firewall reads five core fields from t
Firewall Configuration: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a 5 tuple firewall by writing rules that match five packet values. Those values are source IP, destination IP, source port, destination port, and protocol. Network teams use these rules to control traffic between subnets, servers, and cloud networks. Still, broad port and IP rules often allow too much access once a packet passes.
How a 5 tuple firewall inspects network packets
Every network packet carries a header with basic routing facts. The firewall reads five core fields from this header as traffic arrives. First, it checks the source IP address to see where the packet started. Second, it checks the source port number assigned by the sending machine.
Third, the firewall reads the destination IP address to see where the packet goes. Fourth, it checks the destination port, which points to a specific service or app. Fifth, it identifies the transport protocol, such as TCP, UDP, or ICMP. Together, these five pieces of data form a unique network session identifier.
Stateless filters check each packet on its own against an ordered rule list. Stateful filters track active sessions in a state table after the first packet matches. Return traffic from an approved session passes back through without needing a separate rule. If a packet does not match any allow rule, the firewall drops it right away.
What network rules solve and what they miss
Five tuple rules are fast and simple to run at the network edge. They stop outside hosts from reaching private database ports or internal admin services. Teams use them to split production networks from staging and office networks. This blocks random port scans and limits how far an attacker can move.
Still, network headers only tell you which machine sent a packet to which port. They do not tell you which person or service account is behind that traffic. In cloud setups, IP addresses change often as containers and virtual machines start and stop. Relying on static IP rules leads to wide subnet permissions and stale firewall rules.
Firewall Configuration: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Even worse, a five tuple check stops working once the port is open. The firewall decides who can reach the port, not what happens inside the session. It cannot read database queries, shell commands, or API requests moving over an allowed port. A user on an approved IP can run a drop table command without being blocked.
Why teams pair packet filters with deeper controls
To fix this gap, teams keep network rules as a basic first layer. Network filters block unwanted ports, while session controls check user identity and individual commands. When an engineer runs a query, the system checks their role before running the statement. Sensitive fields like emails, phone numbers, card numbers, and national IDs get rewritten in results.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What are the five fields in a 5 tuple firewall rule?
The five fields are source IP address, source port, destination IP address, destination port, and transport protocol. Together, they identify a specific network flow between two machines.
What is the difference between stateless and stateful 5 tuple filtering?
A stateless filter checks every single packet against the rule list in isolation. A stateful filter remembers active sessions and lets return traffic pass back through by default.
Can a 5 tuple firewall block bad SQL queries or shell commands?
No, it only inspects network layer headers and port numbers. Once traffic passes the allowed port, the firewall cannot read or block commands inside the session.