Description

A Stateless Policy is a type of IP rule set entry in cOS Core that lets packets pass through a NetWall firewall without setting up a state for the connection in the state table. This means that the stateful inspection process is bypassed and is therefore less secure than normal stateful policy. Packet processing time is also slower than stateful policies since every packet needs to perform an IP rule set and routing table lookup. This means that using these types of IP rule set entries could potentially cause an increase in system resource usage.

Why use it?

Sometimes it might be necessary to use these kinds of policies as not all applications follows the correct behavior, e.g. TCP traffic, as specified in the relevant RFC. cOS Core, as a security product, inspects all traffic and looks for irregularities and/or deviations from normal behavior or traffic patterns. The need for stateless policies may also be that based on how the network is setup, with the possibility of traffic arriving out of sequence, such as a SYN+ACK before the SYN packet. Whatever the case may be, in order to allow such unusual traffic patterns, the options may be limited. Sometimes the event log may provide as to what setting it is that triggers for the traffic that you want to allow and then you can change the appropriate option in, for example, cOS Core’s advanced settings.

The problem with changing an advanced setting is that the setting often changes the behavior globally for all traffic and that is rarely something that we would like to do. Especially if the problem is only between specific network hosts, for example, one locally and the other beyond an IPsec tunnel. The best solution then is to use stateless policies to allow the communication between these two hosts as a specific exception.

Example setup

PC(192.168.1.10) <—-> (Lan)SGW(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 beyond the IPsec tunnel. The policy that allows this traffic looks like this:

Which means that only the Lan side of the setup will be able to create connections towards the 192.168.10.0/24 network.
This is not that usual, usually you would have two policies that allows traffic in both directions, like this:

But to make a point, we’ll stick with using only one policy and not both from now on. So our IP rule set would contain:

An example problem

Communication between the PC and the Server is problematic for one reason or another. We will not go into details as to the reasons as they can be numerous. This is not an exact science, as in most cases, it depends on the application, the operating system or both.

The key point is that based on troubleshooting we have concluded that:

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

The solution

Unless the application or server can be modified or changed to behave differently, an easy solution would be to use stateless policies just between the problematic hosts, thus leaving the rest of the network unaffected by this change.

The stateless policy would then look like this:

The need for two stateless policies

Note that stateless policy usage requires two polices, one for each traffic direction, in order to function properly. The reason for this is because they are stateless, there is no connection otherwise created in the state table to keep track of the traffic (especially the return/reply traffic).

Logging should be avoided (if possible)

In the above example, we have disabled logging on these rules. The reason for that is due to the lack of connections created by Stateless rules in the state table the firewall would need to generate a log message for every single packet being sent in each direction.
For one server and client it would not be a big problem, but if this were to be a /24 or /16 network, that would pretty much flood any configured log receiver and potentially cause a much higher CPU load on the firewall as it needs to spend resources on generating these logs.

Continuing with the example, the finished rule set entries would look something like this:

Generic notes

Recommendation

Using stateless policies is not recommended unless you either want to use it for testing or if you trust the network hosts on both sides. It can be useful in solving minor communication issues between specific hosts but for larger networks it should be avoided as much as possible.

It is also not possible to use features such as Application Layer Gateways, Anti-Virus, Web Content Filtering, Application Control and more due to the lack of state tracking.

In case the Stateless policies are not triggering

If we change the type from a state traced policy (normal IP policy) to Stateless and there are still active traffic being triggered on these policies, the stateless policies may not necessary trigger when activating the new configuration changes.

The reason for this is due to existing connections formed by the normal policy that still may exist in the connection table. An existing connection will always trigger before a new rule set lookup. In order to make the stateless policy trigger, we must first close the existing connections (or wait for their timeout assuming that the client is no longer actively using the connection).

We can use the “connections” CLI command with connection filters to close only the connections related to the traffic we are interested in.

Example:

First make a query to see if there are any lingering connections:

connections -show -destport=80 -destiface=VPN_Ovik

And if there are any hits, close them:

connections -close -destport=80 -destiface=VPN_Ovik

Another alternative would simply be to restart the firewall in order to clear out the entire connection table or use the “connections -close -all” command to wipe the ** entire connection table.

Related articles