7.3. IP Rule Actions

Home Prev	cOS Stream 4.00.03 Administration Guide	Next

A rule consists of two parts: the filtering parameters and the action to take if there is a match with those parameters. As described above, the parameters of any rule, including IP rules are:

Source Interface
Source Network
Destination Interface
Destination Network
Service

When an IP rule is triggered by a match then one of the following Actions can occur:

Allow

The packet is allowed to pass from the specified source to the specified destination interface. As the rule is applied to only the opening of a flow, an entry in the "flow table" is made to record that a flow is open. The remaining packets related to this flow will pass through the system "state engine" and will not require another rule table lookup.

The parameter SourceTranslation can optionally be set to one of the following values:
1. NAT - This enables dynamic address translation (NAT) for traffic that triggers the rule. Refer to Section 9.2, NAT in Chapter 9, Address Translation for a detailed description of this.
2. SAT - This enables static address translation (SAT) for traffic that triggers the rule. Refer to Section 9.5, SAT in Chapter 9, Address Translation for a detailed description of this.

Deny

This tells cOS Stream to immediately discard the packet and by default, no reply is sent back to the sending host.

A "polite" version of Deny can be created if the optional OnDeny parameter of a Deny rule is set to SendReject. This setting means the rule returns a TCP RST or ICMP Unreachable message for denied traffic, informing the sender that the packet was dropped. Using this option can help to speed up applications that must wait for a reply timeout period.

The "impolite" default setting for a Deny rule is OnDeny=DropSilent.

Bi-directional Connections

A common mistake when setting up IP Rules is to define two rules, one rule for traffic in one direction and another rule for traffic coming back in the other direction. In fact, an IP rule with the action defined as Allow will permit bi-directional traffic flow once the initial flow is set up.

The Source Network and Source Interface in an IP rule with action Allow refers to the source of the initial flow request. If a flow is permitted and then becomes established, traffic can pass in either direction over it.

Example 7.2. Adding an Allow IP Rule

This example shows how to create a simple Allow rule that will allow HTTP flows to be opened from the if1_net network on the if1 interface to any IP4 address (all-nets-ip4) on the wan interface.

Command-Line Interface

First, change the current context to be the main IP rule set:

System:/> cc RuleSet IPRuleSet main

Now, create the IP rule:

System:/IPRuleSet/main> add IPRule
			SourceInterface=if1
			SourceNetwork=if1_net
			DestinationInterface=wan
			DestinationNetwork=all-nets-ip4
			Service=http
			Action=Allow
			Name=lan_http

Return to the default CLI context:

System:/IPRuleSet/main> cc
System:/>

Configuration changes must be saved by then issuing an activate followed by a commit command.

The Stateless Property

With the Stateless property of an IPRule object, it is possible to turn off the stateful tracking of protocols such as TCP. However, bidirectional flow states will still be set up for the flow in the system state table.

Stateless IP rules are used in a network scenario where data traffic is not suited to the default stateful protocol validation used by cOS Stream. This is usually only an issue with the TCP or ICMP protocols.

For example, with the default TCP state tracking, new flows are only opened when a TCP SYN packet is seen. cOS Stream performs validation so that illegal TCP state transitions are not allowed. When using IP rules with the Stateless property enabled, state transitions are not validated and a TCP flow can be opened even though the first packet is not a SYN.

A typical use case for this option is where asymmetric routing is used in a network topology. This means that only one direction of the TCP flow is passing through cOS Stream. If TCP validation were enabled then the flow would be dropped by cOS Stream since only one side of the TCP exchange will be seen.

Another use case is where there are TCP data flows from a wireless device to a 3GPP network. The flow might be started over a cellular phone wireless network and then be handed over to a Wi-Fi network that comes into range. The Wi-Fi network access could be via a Clavister NetShield Firewall and the triggering IP rule in the configuration will need the Stateless property enabled since any TCP flows have already been established prior to transiting through the firewall.

The following points should also be noted when using the Stateless option:

There is no loss of firewall throughput performance when the option is used.
The disadvantage of turning off flow validation is a reduction in security.
The IPRule object property StatelessAllowNewTCP can be used to prevent new TCP flows being established using the IP rule. The default value for this is Yes which allows new TCP flows.

The StatelessAllowNewTCP property is only used if the Stateless property is enabled.
IP rules with the Stateless property enabled can still support all the address translation options.

Example 7.3. Enabling the IP Rule Stateless Property

This example assumes the existence of the IP rule that has index number 6 in the main IP rule set. The Stateless property for this rule is to be enabled.

In addition, establishing new TCP flows with this IP rule will not be allowed by disabling the property StatelessAllowNewTCP.

Command-Line Interface

First, change the current context to be the main IP rule set:

System:/> cc RuleSet IPRuleSet main

Now, create the IP rule:

System:/IPRuleSet/main> set IPRule 6 Stateless=Yes StatelessAllowNewTCP=No
Modified IPRule/6.
System:/IPRuleSet/main>

Return to the default CLI context:

System:/IPRuleSet/main> cc
System:/>

Configuration changes must be saved by issuing an activate followed by a commit command.