Using Stateless Policies.

Security Gateway Articles and How to's
Post Reply
Peter
Posts: 636
Joined: 10 Apr 2008, 14:14
Location: Clavister HQ - Örnsköldsvik

Using Stateless Policies.

Post by Peter » 18 Feb 2013, 19:33

This How-to applies to:
  • Clavister Security Gateway 11.x.
Description:

Stateless Policies are a type of rule that let the packets pass through the Clavister Security Gateway without setting up a state for it in the state table. This means that the stateful inspection process is bypassed and is therefore less secure than normal policies. Packet processing time is also slower than normal policies since every packet needs to perform a new rule and route lookup.

Why use it?

Sometimes it might be necessary to use these kinds of policies as not all applications follows the exact behavior on e.g. TCP traffic as specified the in RFC's. We as a security product inspect all traffic and look for irregularities and/or deviations from normal behavior or traffic patterns. It may also be that based on how the network is setup, traffic arrives in an incorrect order 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 quite limited. Sometimes the log may give you clues as to what setting it is that triggers for the traffic that you want to allow and then you can change that option in e.g. Advanced Settings.

The problem with changing an advanced setting is that the setting changes the behavior globally on all traffic passing through the SGW, and that is rarely something that you would like to do. Especially if the problem is only between e.g. 2 specific machines, 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.

Example setup:

Code: Select all

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:
Allow lan to server.png
Allow lan to server.png (11.2 KiB) Viewed 1771 times
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 have two policies that allows traffic in both directions, like this:
Allow server to lan.png
Allow server to lan.png (16.35 KiB) Viewed 1771 times
But to make a point, we'll stick with using only one policy and not both from now on. So our ruleset looks like this:
Allow Policies.png
Allow Policies.png (19.6 KiB) Viewed 1771 times
The problem:

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

The point is that based on your troubleshooting you have concluded that:

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

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:
FWDFast SingleIP.png
FWDFast SingleIP.png (16.6 KiB) Viewed 1771 times
Stateless policies requires two polices, one in each direction, in order to function properly. The reason for this is because they are stateless, there is no connection or otherwise being created to keep track of the traffic.

Also we have disabled logging on these rules. The reason for that is due to the lack of connections we would 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.

So the ruleset then looks like this:
FWDFast Policies.png
FWDFast Policies.png (25.49 KiB) Viewed 1771 times
Using stateless policies is not recommended unless you either want to use it for testing or if you trust the machines on both sides. It is also not possible to use features such as Application Layer Gateways and such due to the lack of state tracking.

NOTE: In case the Stateless policies are not triggering:

If you change type from a state traced policy (Normal policy) to Stateless and there are active traffic being triggered on these policies, the stateless policies may not necessary trigger.

The reason for this is due to existing connections formed by the normal policy. An existing connection will ALWAYS trigger before a new ruleset lookup. In order to make the stateless policy trigger, you must close the existing connections.

You can use the CONN command in the CLI to make connection filters and then close only the connections related to the traffic you are handling.

Example:

Code: Select all

Connections -close -destport=80 -destiface=VPN_Ovik
Another alternative would simply be to restart the unit to clear out the entire connection table or use the "connections -close -all" command.

mape
Posts: 41
Joined: 24 Oct 2016, 08:23

Re: Using Stateless Policies.

Post by mape » 13 Dec 2016, 12:30

Updated 2016-12-13

Post Reply