We'll see here what is a Stateless Firewall, a Statefull Firewall, and how to use the IPv6 Statefull Firewall in manual mode ( ie without IPv6 Simple Security ), using the DLink DIR-626L.
This will be the occasion to test the DLink DIR-626L Statefull Firewall.
What is a Stateless Firewall
Let's start by describing the ancestor of the Statefull Firewall : the Stateless Firewall.
This early type of firewall used ACLs ( Access Control Lists ) : this is a list of static rules, stating which trafic type is allowed or denied for a particular direction ( eg Lan > Wan or Wan > Lan ).
Here is an exemple :
imagine we want PC1 to acces any internet web server. We need two rules :
. Allow all TCP 80 traffic out
. Allow all TCP 80 traffic in
As you can see it, 2 rules are needed. Authorizing TCP 80 out doesn't automatically allow the replies back in : The two directions are memory-less and unrelated. Each time a packet reaches the firewall, it is checked against the ACLs ( Rules lists ). A Stateless Firewall is memoryless.
This type of firewalling obviously gets quit tedious very quick. And what happens if we want to block all unsolicited incomming TCP 80 traffic ?
What is a Statefull Firewall
A Statefull Firewall keeps track of what is happening.
Let's take the same example :
Imagine we want PC1 to acces any internet web server. We need one rules :
. Allow all TCP 80 traffic out
Here is how it works :
If PC1 tries to connect to an internet web server, the Statefull Firewall sees an outboud connection is initiated, checks its rule list, and sees the matching allow rule.
The Statefull Firewall then creates a state ( ie a log ) for this connection, noting source and destination IPs, Ports, and TCP sequence number.
Then, when the reply comes back in, although there is no incoming rule, it can check that there is a log for this connection and allows it back in.
To sum it up : Reply traffic is implicitely allowed.
The Statefull Firewall with more details
The Statefull Firewall performs DPI ( Deep Packets Inspection ), checking more than just IP addresses and ports numbers. It does check the CONTENT of the layer 4, and even sometimes looks at layer 7. But it does this only for the first packet of a connection or stream, eventually allowing the connection / stream and creating the state ( log ) for this connection / stream.
Statefull Firewall functionning is easy with TCP, as TCP is a connection-protocol, whith clear start and end signals ( SYN / FIN-ACK )
For a TCP connection, the first state is created when the initial three-way handshake is done .The state is closed when the two-way connection-end is done is sent.
For UDP, which is connectionless, the state is created with the first SYN, and closed using timers.
For ICMP, which is connectionless and even one-way messages sometimes, things get even more tricky to manage for the Statefull Firewall.
But Statefull Firewalls are very wit things, that are learned in protocols and can manages many layer > 4 types.
One Final note : Statefull Firewalls are a little CPU-intensive at the first packet inspection / state creation for a connection, but very light and fast for the following packets, as they only keep track of the state of the connections ( IP addresses, Ports, and states ).
Stateless Firewalls are more CPU intensive, as the rule matching lookup has to be redone for each packet.
The other type of filtering, Proxy, is more CPU intensive than Statefull FIrewall too.
An IPv6 Statefull Firewall practical implementation
We'll use our trustfull DLink DIR-626L to perform the tests. Please see this post about Firewall Testing methodology.
First, we uncheck IPv6 Simple Security ( and Ingress Filtering ) :
Here is the result of the tests :
Everything behaves as expected, in a very logical way.
We can check the Statefull Nature of this firewall, as a simple ' allow out ' rule does allow the reply trafic back in.
One thing to note, that doesn't show in the table, is that ICMPv6 traffic is affected by the rules in a strict way ( whereas using IPv6 Simple Security, ICMPv6 traffic is allowed, overiding the allow mode restrictive ways. See last post ).
Lets now try some real-life configurations :
We want our internal network computers to be able to freely access the Internet, we want our Web ServerPC1 to be accessible from the outside, and all other inbound ports to be closed.
We can do it either using the allow mode, with two rules :
. Allow everything Lan > Wan
. Allow TCP 80 Wan > Lan
Or using the deny mode, using 3+1 rules :
. Deny TCP 1-79 Wan > Lan
. Deny TCP 81-61535 Wan > Lan
. Deny UDP Wan > Lan
. Deny ICMPv6 Wan > Lan ( Optional )
Here is the tests result :
It looks like there is a problem with the deny mode implementation. Further investigations show that using TCP port 1 or TCP port 65535 in a deny rule totally crashes the TCP Statefull Firewall engine.
Further testings shows some others such bugs in the ' deny mode '.
The DIR-626L firmware is very fresh and new, at its third occurence at the time of this writing ( firmware version 1.03 ). Furthermore, as an entry-level router, testing and fixing such things may be less of a priority for DLink engineers than higher-grades entreprises hardware, that rightfully deserve a top notch service. I'll try to investigate and test more, and update the infos here.
As for now, the deny mode is useless for me, and only the allow mode is usefull.
Screenshots of bug-triggering configurations