In our previous post, we took a broad look at the NAT services available in NSX; in particular, we noted which NAT services are ‘stateful‘ or ‘stateless‘ (that is, identifying which NAT services utilize a ‘state‘ table). As NAT rules in NSX are functionally firewall rules, we wanted to review how stateful and stateless firewalls operate, and what differs between them.
For today’s topic, we will be taking a conceptual look at firewalls; we will depict a generic “firewall” that sits between a “client” and a “server”, and demonstrate the effect of using firewall state (or the lack thereof). While we won’t be looking directly at NSX NAT services today, this discussion lays the foundation for a better understanding of how NSX NAT services function in the future.
Firewalls 101
A firewall uses a series of rules (sometimes referred to as a ‘rule base‘ or ‘policy‘) to allow or deny traffic based on various criteria, such as source IP, destination IP, port, protocol, etc. A packet entering a firewall is evaluated against these rules in order, beginning with the first rule, until there is a match. When the packet successfully matches a rule, any further evaluation of the packet against the rule base is halted, and the action for that rule (ex. ‘allow‘ or ‘deny‘) is taken .
In the above, a packet destined for 172.30.10.100 (to port 22/TCP) from 172.20.10.10 is compared against our rule base, starting with rule 1. As the packet does not match the data in rule 1, it is then compared to rule 2 where it successfully matches. This match results in the ‘Allow‘ action being taken on the packet, and it continues on to 172.30.10.100.
Note: if the packet had not matched in rule 2, it would continue down the list of rules until obtaining a match.
The firewall methodology depicted above is known as a ‘Deny All‘ posture. In this method, the rules of a firewall rule base are configured to explicitly allow traffic that has been deemed appropriate. The final rule of the rule base, a ‘Deny All‘ rule, denies all packets that reach it. In other words, only traffic that has been expressly allowed may successfully traverse the firewall, and everything else is dropped.
Note: Most firewalls possess what is known as an “implicit deny”, which means if a packet does not match any rule in the rule base, it is dropped/discarded. Implicit deny rules typically don’t create log entries, which is why many security professionals elect to craft an explicit ‘Deny All‘ rule to log packets that reach it.
Note: Typically, firewall rules do not consider source port when making an evaluation. Under normal circumstances, a client chooses a random source port numbered 1024 or higher for a connection, which means that any firewall rule evaluating source ports would also need to allow that same range, arguably reducing its security “value”. While NSX and other firewalls can evaluate source port, for our purposes, our firewall will not be evaluating the source port of a connection for rules in the rule base.
Stateful vs Stateless Firewalls
While the above section applies to most firewalls in general, a key differentiator of firewalls is the concept of firewall ‘state‘. Quite simply, a ‘stateful‘ firewall tracks connection state, while a ‘stateless‘ firewall does not. Let’s take a deeper look in the following sections.
Note: For the ‘Stateless Firewalls‘ and ‘Stateful Firewalls‘ sections, presume we are utilizing the ‘Deny All‘ methodology described above.
Stateless Firewalls
A stateless firewall evaluates all packets against the rules of the rule base. While this statement may appear obvious, this means that traffic in each direction (think ‘client-to-server‘ and ‘server-to-client‘) must match a rule in the rule base.
As depicted previously, we can see 172.20.10.10 is accessing 172.30.10.100 on port 22/TCP. As with any TCP communication, our client (172.20.10.10) utilizes a random source port higher than 1024 for this communication (port 23654 in the above example). Rule 2 is configured to allow this traffic (based on source IP, destination IP, and destination port/protocol), this packet is allowed to successfully traverse the firewall.
However, we must also account for the reply traffic from server to client. 172.30.10.100 is replying to the original packet, it uses port TCP/22 as its source port, and sends this packet to 172.20.10.10 on destination port 23654. Since the reply packet’s source IP, destination IP, and destination port/protocol does not match rule 1 or 2, it moves on to match against our final rule, which denies this communication.
For reply traffic to reach 172.20.10.10, we must add a new rule, which sits at number 3 in the above diagram. Notice this rule is configured with 172.30.10.100 as its source, 172.20.10.10 as its destination, and a port/protocol setting of ‘>1024/TCP‘ which means as long as the destination port on 172.20.10.10 is 1024 or higher, TCP traffic from 172.30.10.100 will be allowed. With this rule in place, reply traffic from 172.30.10.100 to 172.20.10.10 successfully traverses the firewall.
Ultimately, we only need to understand that a ‘stateless‘ firewall evaluates all traffic against the rule base, and there must be explicit rules for communication in each direction.
Stateful Firewall
Stateful firewalls solve two specific issues of stateless firewalls. These issues are:
- Comparing all incoming packets against the rule base is computationally expensive
- Traffic flows typically require two unique rules to operate properly
Like a stateless firewall, traffic entering a stateful firewall is processed against the rules in rule base until there is a successful match. The key difference with a stateful firewall is the first packet that successfully matches against a firewall rule results in an entry in the ‘state table‘, which is evaluated for matches before the firewall rule base.
With an entry in a state table, matching traffic in either direction is no longer evaluated against the rules of the firewall rule base. In short, once the first packet of a communication is allowed by a firewall rule, there’s no continued firewall rule evaluation of the remaining packets making up this communication.
Note: Evaluating a packet for a match in a state table is considered to be less computationally intensive than evaluating against firewall rules. Once a single packet in a new communication has been allowed by the firewall policy to create a state table entry, it is less intensive processing-wise for all remaining traffic in this flow to be matched against the state table.
As an entry in the state table will match both ‘client-to-server’ and ‘server-to-client’, we only require a single firewall rule to allow our desired communication. This single firewall rule handles the first packet of the communication (the ‘client-to-server’ traffic) and all reply traffic is allowed by the state table entry.
Here we see 172.20.10.10 is sending a packet to 172.30.10.100 on port 22/TCP, and it’s received by a stateful firewall. The packet is first compared to the state table, where no match exists, as this is the beginning of a new communication. The packet is then compared against the firewall rule base, where a rule to allow this traffic (rule 2) matches. The packet is now sent onward to its destination, and a state table entry is created for this flow.
Now we can see our state table has an entry for this traffic flow. From this point on, until the connection is terminated, all traffic that is considered part of this flow (‘client to server’ as well as the reply ‘server to client’ traffic) will match against the entry in the state table, and is no longer directly processed against the firewall rule base.
In the above, we opted to break down what would match this state table entry. The ‘client-to-server’ (172.20.10.10 to 172.30.10.100) communication is in black, and the ‘server-to-client’ reply (172.30.10.100 to 172.20.10.10) is in red. As the reply packet matches the red data in state table entry, it is allowed through the firewall.
Next Time…
The key takeaway from today’s post is understanding the difference between stateful and stateless firewalls, which ultimately, is the existence and impact of the state table. In our next post, we’ll be looking at Source NAT (SNAT) in NSX, and we’ll see how the state table plays a part in NAT communications.
See you later!
LumberjackWizard 