- Clavister Security Gateway 11.x.
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.
Code: Select all
PC(192.168.1.10) <----> (Lan)SGW(Wan) <--- IPsec Tunnel(VPN_Ovik) ---> Server(192.168.10.50)
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.
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: 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: 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.
Code: Select all
Connections -close -destport=80 -destiface=VPN_Ovik