Using Stateless Policies in cOS Core

Last modified on 16 Jun, 2021. Revision 21
When and how to use a Stateless Policy in a cOS Core IP rule set instead of the more usual stateful IP Policy.
Up to date for
13.00.10
Supported since
11.x
Status OK
Author
Peter Nilsson

Stateless Policy Description

A Stateless Policy is a type of IP rule set entry can let packets pass through a NetWall firewall without setting up a state for the connection in the cOS Core state table. This means that the stateful packet inspection process is bypassed and is therefore less secure than a stateful IP Policy. Packet processing times are also slower than stateful IP rule set entries since every packet is treated as a new connection that needs to have rule and route lookup performed on it. It will also generate a log message for each packet unless logging is disabled for the policy.

Why use a Stateless Policy?

Sometimes it might be necessary to use these kinds of policies since not all applications follows the exact behavior specified the in RFCs (for example, in TCP).  It might also be that based on how a network is setup, packets could arrive in an incorrect packet order, such as with a SYN+ACK before the SYN packet. With its default settings, cOS Core inspects traffic, looking for such irregularities and/or deviations from normal behavior.

Whatever the case, in order to allow such unusual traffic patterns the options may be limited. Sometimes the system log may give clues as to what the trigger should be for the traffic that you want to allow and then changing an option in the firewall’s advanced settings might resolve the issue.

The problem with changing an advanced setting is that the behavior may change globally on all traffic and that is usually not desirable. Especially if the problem is only between, for example, two specific hosts, one local and the other beyond an IPsec tunnel.

A better, more targeted solution might be to use Stateless Policy entries in the IP rule set that allows communication between the hosts.


An Example Setup Using Stateful Policies

PC(192.168.1.10) <----> (Lan)Firewall(Wan) <--- IPsec Tunnel(VPN_Ovik) ---> Server(192.168.10.50)

In the above scenario, the PC with IP 192.168.1.10 wants to talk to the Server (with IP 192.168.10.50) which is routed through the IPsec tunnel. The stateful IP policy that allows this might look like the following:

This means that only the Lan side of the setup will be able to create connections towards the 192.168.10.0/24 network. More common is having two policies that allow connections to be initiated by either side using two stateful IP policies:

However, for this example, we’ll assume only one stateful IP policy is used so connections can only be initiated by clients on the internal network. The complete stateful IP rule set entries might now be the following:

The Problem

The system administrator may now see that the communication between the PC and the server has problems, perhaps because of the way host operating systems or applications behave. Further investigation then indicates that

1. The firewall drops the traffic we are interesting in allowing.
2. The required cOS Core setting change is a global change that would lead to a security compromise in the overall network environment.

The Solution Using Stateless Policies

The most straightforward solution may be to use stateless policies between the problematic hosts, thus leaving the rest of the network unaffected by this change. The stateless policy entries in the IP rule set for this example scenario might then look like this:

Using stateless policies with bidirectional traffic requires two polices, one for each direction. The reason for this is because they are stateless, meaning there is no bidirectional connection being tracked in the Firewall’s state table.

Note that logging has been disabled on these policies. The reason for this is because cOS Core would otherwise generate a log message for every single packet being sent in each direction. For one server and client it might not be a big problem, but if this were to be a /24 or /16 network, logs could flood any configured log receiver.

So the rule set entries now look like this:

Use Stateless Policies Only When Required

Using stateless policies is not recommended unless you either want to use it for testing or if you trust the hosts on both sides. Some of a NetWall firewall’s security features cannot be used with Stateless Policies. For example, it is also not possible to use features such as Application Layer Gateways (ALGs) because the connection state is not being tracked.

Note: If Stateless Policies are not Triggering

If you change the IP rule set entry from stateful to stateless and there is active traffic affected by the entry, the stateless entry may not necessarily trigger.

The reason for this is that existing connections may have triggered the original stateful entry. An existing connection will ALWAYS trigger before a new rule set lookup. In order to make a stateless policy trigger, existing connections must be closed.

You can use the “conn” command in the cOS Core CLI to see existing connections and then close only the connections related to the traffic of interest.

A conn Command Example:

conn -close -destport=80 -destiface=VPN_Ovik

Another alternative would simply be to restart the firewall to clear out the entire connection table or use the “conn -close -all” command.



Related articles

Does IPsecBeforeRules trigger before Access rules?
8 Sep, 2020 core ipsec rules access
Is Statless (FwdFast) faster than a normal IP policy?
27 Jan, 2021 core stateless routing brokenlink