Home  Prev  cOS Stream 4.00.03 Administration Guide  Next

8.2. SCTP

8.2.1. The SCTP Service

A service object of the type ServiceSCTP can be assigned to the Service property of an IPRule so the rule triggers on SCTP traffic. cOS Stream provides a predefined object of this type with the name all_sctp.

In addition to being used as a filter for SCTP traffic, the ServiceSCTP service type also performs validation of SCTP flows. Validation can be performed for both stateless or stateful SCTP flows. Note that an SCTP flow is stateless if the Stateless property on the associated IPRule is enabled.

Supported SCTP Scenarios

A typical SCTP scenario that is supported by cOS Stream is where two networks communicate via the firewall using the SCTP protocol. SCTP multi-homing is supported by cOS Stream which means that the communicating networks can connect to the firewall via multiple interfaces, therefore providing path redundancy.

Limitations with SCTP

It should be noted that although cOS Stream supports the routing of SCTP traffic, it does not support the firewall acting as a terminator for SCTP traffic. Having cOS Stream perform NAT or SAT address translation with SCTP is also not possible.

SCTP Global Settings

There is a set of global settings for SCTP available in the SCTPSettings object. These settings are fully documented in the SCTPSettings section of the separate Clavister NetShield Firewall CLI Reference Guide and apply to all SCTP processing in the firewall

The global setting SCTPEnabled in the object SCTPSettings determines if SCTP filtering can be performed using a ServiceSCTP object. This is enabled by default but, if required, can be disabled with the following command: 

System:/> set Settings SCTPSettings SCTPEnabled=No

When enabled, STCP validation will also be part of the all_services object for both stateless and stateful flows.

If SCTPEnabled is set to No, SCTP is treated as an unknown protocol.

Multi-Homing

cOS Stream supports SCTP multi-homing with either all IPv4 or all IPv6 addresses. Multi-homing means that SCTP peers can make use of multiple IP addresses for path redundancy. If a path fails, SCTP will retransmit the data over an alternate path. Flows can be between any IP address pair which is negotiated by the peers, but the port number is always the same.

Stripping of Multi-Homing Packets

The following should be noted about the stripping performed with multi-homing:

  • For SCTP stateful flows, all the IP addresses need to be routed through cOS Stream which means that the SCTP traffic must match the filter of the IPRuleobject. cOS Stream will strip IP addresses from packets that do not match the filter during the setup of SCTP associations. It will also strip host name addresses since they might get resolved by the peers to IP addresses that do not match the filter.

  • For SCTP stateless flows, stripping of IP addresses that lie outside the filter of the IP Rule object can be controlled by the SCTPMultihoming property of SCTPSettings. The default behavior is to not apply any restrictions on additional IP addresses or host name addresses for SCTP stateless flows. Handling of host name addresses is controlled by the SCTPHostNameAddressParam property of SCTPsettings.

Limiting Multi-Homing IP Addresses

The number of IP addresses allowed with multi-homing can be configured on the ServiceSCTP object by setting the properties MaxSourceAddresses and MaxDestAddresses.

Multi-Homing Interfaces Must Be Security Equivalent

The set of interfaces used for multi-homing must be set to be security equivalent. For example: 
System:/> set Interface EthernetInterface if1
			SecurityEquivalentInterfaces=if2,if3
Security equivalence is explained further in Section 3.6, Security/Transport Equivalence.

Using Interface Groups with Multi-Homing

It can be helpful to create an InterfaceGroup object which consists of the interfaces that will be involved in multi-homing. This group can then be used as the source and destination interfaces of IP rule(s) set up to handle SCTP traffic instead of specifying the interfaces individually.

A Summary of Multi-Homing Setup

The steps for setting up multi-homing with multiple source interfaces and multiple destination interfaces can be summarized as the following:

  1. Set up security equivalence between the source interfaces and again between the destination interfaces.

  2. Create an interface group for the source interfaces and another for the destination interfaces.

  3. Set up an IP rule with the appropriate SCTP service that uses these groups as the source and destination interface values. Also set the source and destination network values to the networks reachable through the interface groups. The setup and function of this rule is described in more detail next.

Setting up the IP Rule for Multi-Homing

The following points should be noted about the IPRule object that is created for SCTP multi-homing:

  • The rule should allow the initiator (the SCTP client) to make connections to the responder (the SCTP server).

  • The source IP address group of the rule should, at a minimum, contain all the IP aliases of the SCTP initiator that will be visible to the SCTP responder.

  • The source interface group should include all the interfaces through which the SCTP initiator can reach the SCTP responder.

  • The destination IP address group should include all the IP aliases of the SCTP responder that will be visible to the SCTP initiator.

  • The destination interface group should include all the interfaces through which the SCTP responder can reach the SCTP initiator.

  • Even though the rule does not explicitly allow the SCTP responder to contact the initiator, the return path is implicitly defined once the initiator has contacted the responder.

  • The source and destination interface filter specified for the rule can include interfaces which are not security equivalent. However, once the SCTP initiator has made initial contact with the responder, communication can only continue over security equivalent interfaces. Specifically, the initiator will only be allowed to send via source interfaces that are security equivalent to the source interface used for initial contact. Similarly, the responder will only be allowed to send via destination interfaces that are security equivalent to the destination interface used for initial contact.

  • Similarly, the rule's source and destination IP address filter can include IP addresses that are not part of IP aliases used by the SCTP endpoints. This means that the filters can be configured with entire network ranges, provided that this does not compromise security. However, once the SCTP initiator and responder have made contact, they will only be allowed to use their respective IP aliases for further communication.

Setting Up Stateless SCTP

Stateless SCTP is set up by setting the Stateless property of the IPRule object to a value of Yes. What this means is that SCTP will function as before and multi-homing will work, but cOS Stream will not be able to apply its full range of SCTP integrity checks. For example, the initial SCTP endpoint negotiation might flow through another route outside the firewall before subsequent SCTP traffic flows through the firewall. Note that if part of the SCTP session were to occur outside of the firewall then a second IP rule would be needed for SCTP traffic returning from the responder.

Also note that the SCTP multi-homing redundancy feature, described later in this section, will not function with stateless SCTP.

Example 8.3. Setting Up Stateful SCTP Multi-Homing

This example sets up stateful SCTP multi-homing. There are two IPv4 source networks that will initiate SCTP flows, if1_net on the if1 interface and if2_net on the if2 interface.

There are two destination remote SCTP peers which have IPv4 addresses 198.168.3.1 and 192.168.4.1. These addresses have associated interfaces if3 and if4.

Note that this example is valid if there are two independent remote peers using SCTP or there is a just a single remote peer implementing multi-homing using two IP addresses.

Command-Line Interface

First, create address book objects for the remote peers that will be the destination addresses: 

System:/> add Address IPAddress peer_ip1 Address=192.168.3.1

System:/> add Address IPAddress peer_ip2 Address=192.168.4.1

Next, set up security equivalence for the source and destination interfaces: 

System:/> set Interface EthernetInterface if1
			SecurityEquivalentInterfaces=if2

System:/> set Interface EthernetInterface if3
			SecurityEquivalentInterfaces=if4

Create interface groups for the source and destination interfaces: 

System:/> add Interface InterfaceGroup ifgp1 Members=if1,if2

System:/> add Interface InterfaceGroup ifgp2 Members=if3,if4

Create an IP rule for traffic coming from the networks that initiate SCTP flows towards the remote peers: 

System:/> cc RuleSet IPRuleSet main
System:/IPRuleSet/main> add IPRule Action=Allow
			SourceInterface=ifgp1
			SourceNetwork=if_net,if2_net
			DestinationInterface=ifgp2
			DestinationNetwork=peer_ip1,peer_ip2
			Service=all_sctp
			Stateless=No

8.2.2. Multi-Homing Redundancy

Both SCTP stateless and stateful flows are fully supported by a high availability cluster. SCTP flows do not need to be reestablished after an HA failover.

In addition, SCTP stateful flows can make use of an HA cluster feature called Multi-Homing Redundancy in conjunction with SCTP multi-homing This feature means that stateful SCTP flows are able to use a route through either HA cluster node. If one cluster node fails then, using multi-homing, the SCTP endpoints will reroute traffic through the other node with no requirement for flow reestablishment.

Traffic rerouting using the multi-homing redundancy feature is illustrated in the diagram below where two SCTP endpoints have a choice of traversing an HA cluster using either route 1 or route 2. If one route becomes unavailable because of a firewall failure in the cluster, SCTP multi-homing allows the endpoints to immediately switch to the alternate route through the other firewall, without traffic interruption.

SCTP Multi-Homing Redundancy

Figure 8.1. SCTP Multi-Homing Redundancy

8.2.3. Node Only Routes with Multi-Homing Redundancy

The routing of SCTP traffic through an HA cluster with multi-homing redundancy can sometimes require either or both of the following routing requirements:

  • SCTP traffic to a specific network may need to be routed through a specific interface on one node in the HA cluster, and dropped entirely on the other node.

  • SCTP traffic to a specific network may need to be routed through one interface on one node in the HA cluster and through a different interface on the other node.

To address the above requirements, cOS Stream provides a special HARoute object which can be added to a user-defined routing table. These special routes are also referred to as HA node only routes.

Setup Steps for Node Only Routes

The following steps are needed to set up the node only routing feature:

  1. Define a new RoutingTable object and set its property AllowHARoutes to the value Yes. This property allows both normal routes and node only routes to be added to the table. However, the property cannot be enabled for the predefined main routing table.

    Note also that with the AllowHARoutes property enabled, a table cannot be assigned to the RoutingTableMembership property of an interface.

  2. Add one or more HARoute objects to the new routing table. These define the required node only routing behavior for a specific destination network.

    The MasterInterface property of an HARoute specifies a single interface for routing on the master node and the SlaveInterface property does the same for the slave node. The interface specified could be Ethernet, VLAN or another type. Either of these properties (but not both) can be set to the special interface value of <drop> if traffic to the matching destination network is to be dropped on one of the nodes.

  3. Define a policy based routing rule which triggers on the relevant SCTP traffic and selects the routing table defined in the first step for both forward and return traffic. This is done by adding a child RoutingRule object to the predefined PBRRules parent object.

    Note that the Service property of the RoutingRule must be set to a value of SCTP. Otherwise, it will not be possible to use the rule with a RoutingTable that has its AllowHARoutes property enabled.

  4. Make sure there is an IPRule object that allows the traffic for each HARoute object created. Where a single HARoute object routes traffic through different interfaces depending on the node, a single IPRule must allow this traffic on both interfaces.

  5. On the external network equipment connected to the HA cluster interfaces, static ARP table entries may need to be created so that the equipment knows which cluster interface to send traffic to for a given IP address. The reason for this is that the HA cluster only sends out gratuitous ARPs for the shared IP addresses of interfaces and not the unique IP addresses of each HA node.

Example 8.4. HA Node Only Routes with Multi-Homing Redundancy

This example will assume that there is a requirement in an HA cluster with multi-homing redundancy to route the destination network if1_net on the master HA node through the if1 interface and to drop this same traffic on the slave node.

An additional requirement is to route the destination network ext_net on the master HA node through the if2 interface but to route this same network on the slave node through the if3 interface.

Note that creating an appropriate IPrule is not shown in this example but one has to exist that allows the traffic flow for each HARoute. Each IPRule must specify all the destination interfaces specified in its corresponding HARoute.

A. Create a routing table for the node only routes:

System:/> add RoutingTable sctp_rt AllowHARoutes=Yes

B. Add the HA routes to the new routing table:

System:/> cc RoutingTable sctp_rt
System:/RoutingTable/sctp_rt> add HARoute
			Network=if1_net
			MasterInterface=if1
			SlaveInterface=<drop>
System:/RoutingTable/sctp_rt> add HARoute
			Network=ext_net
			MasterInterface=if2
			SlaveInterface=if3
System:/RoutingTable/main> cc
System:/>

C. Add a policy based routing rule:

System:/> cc PBRRules
System:/PBRRules> add RoutingRule
			Service=all_sctp
			SourceInterface=any
			SourceNetwork=all-nets-ip4
			DestinationNetwork=if1_net,ext_net
			ForwardRoutingTable=sctp_rt
			ReturnRoutingTable=sctp_rt
			Name=sctp_rr
System:/PBRRules> cc
System:/>
Home  Prev   Next