cOS Stream 4.00.02 Use Case Guide

This guide describes the cOS Stream configuration of specific use cases for deployment of the cOS Stream operating system.

Further information about cOS Stream setup can be found in the following key cOS Stream documents:

This use case details how to configure the Clavister Firewall (SGW) with a LAN-to-LAN IPsec tunnel, negotiated via IKEv2 using a pre-shared key (PSK) or certificates, as well as rules allowing traffic to pass through the tunnel in a bi-directional fashion.

Scenario

In this scenario there are two IPv4 networks at two different locations: Site A (network 192.168.1.0/24) and Site B (network 192.168.2.0/24). These are connected to each other via a LAN-to-LAN IPsec tunnel over a shared WAN network (10.0.1.0/24).

Hosts on Site A can initiate communication with hosts on Site B and vice versa. The tunnel can be negotiated by using IKEv2 with PSK for authentication or by using certificates.

In the guide, only the configuration of the SGW is described. It is assumed that the Site B tunnel endpoint is configured in a similar manner to Site A. Only IPv4 addresses are used.

Configuration Assumptions

It is assumed that the SGW has a default base configuration with default cOS Stream address book objects created for interface IP addresses and networks. The contents of the address book can be displayed with the CLI command:

System:/> show Address

This will display the address book contents. If the default address book objects do not exist for the Ethernet interfaces then they must be created before continuing.

Configure IP Addresses and Networks

In this use case, the If2 and If3 Ethernet interfaces will be used for external connections. The If2 interface is connected to the external WAN network and the If3 interface is connected to the protected Site A network.

To begin the configuration process, set the IP address and network of the If2 interface to 10.0.1.1 and 10.0.1.0/24 respectively using the CLI:

System:/> set Address IPAddress If2_ip Address=10.0.1.1

System:/> set Address IPAddress If2_net Address=10.0.1.0/24

Next, the IP address and network of the If3 interface is set to 192.168.1.1 and 192.168.1.0/24 respectively:

System:/> set Address IPAddress If3_ip Address=192.168.1.1

System:/> set Address IPAddress If3_net Address=192.168.1.0/24

Next, a network object for the Site B network 192.168.2.0/24 needs to be added:

System:/> add Address IPAddress site_b_net Address=192.168.2.0/24

The remote endpoint of Site B also needs to be added to the address book:

System:/> add Address IPAddress site_b_ip Address=10.0.1.2

Make sure that the routes for routing traffic over the interfaces are configured correctly. If they are not, first change the current context to be the routing table called main:

System:/> cc RoutingTable main

The prompt will change to indicate the new context and the following commands will set the routes:

System:/RoutingTable/main> set Route 1 Interface=If2 Network=If2_net

System:/RoutingTable/main> set Route 2 Interface=If3 Network=If3_net

Each route in the routing table has an index number and this number is specified following set route in the above commands to identify the route being changed. To find out the correct index number for a route, use the following command to list the entire table:

System:/RoutingTable/main> show

Routes can optionally be assigned a name for greater clarity.

Before continuing, change the context back to the default:

System:/RoutingTable/main> cc

All routes in the active routing table can be displayed with the CLI command:

System:/> routes

Configure the IPsec Tunnel

In this use case, the IPsec tunnel is configured to either use certificates for authentication or a shared PSK. Depending on how the tunnel endpoint at Site B is configured, either PSK or certificate authentication should be used.

A. PSK Authentication

Create the Pre-shared Key (PSK) to use for authentication:

System:/> add IPsecPSK LocalID=site_a@local.com
			RemoteIDType=E-Mail
			RemoteID=site_b@remote.com
			Type=ASCII
			PSKAscii=somesharedsecretcode

Create the IPsec tunnel interface:

System:/> add Interface IPsecTunnel my_tunnel
			LocalAuthMethod=PSK
			LocalID=site_a@local.com
			LocalNetwork=If3_net
			LocalEndpoint=If2_ip
			RemoteEndpoint=site_b_ip
			RemoteID=site_b@remote.com
			RemoteNetwork=site_b_net
			IPaddress=If3_ip
			IKEProposalList=ike_all
			IPsecProposalList=ipsec_all
			IKELifeTimeSeconds=604800
			IPsecLifeTimeSeconds=57600
			IKEReauthTimeSeconds=0

IKEv2 is the tunnel default and does not need to be specified. The RemoteAuthMethod= option also does not need to be specified since it defaults to the same value as LocalAuthMethod.

The association between the previously defined PSK and this tunnel is through the unique combination of the LocalID and RemoteID parameters in each definition.

The three parameters IKELifeTimeSeconds and IPsecLifeTimeSeconds are set according to how much traffic is expected through the tunnel. High throughput means that these values should be set lower to re-key more often in order to preserve security. These settings do not affect the re-keying performed by the peer at the other end of the tunnel so that peer should be similarly configured to prevent re-keying.

In this case, the time values 604800 seconds (7 days) and 57600 seconds (8 hours) are used. The value of IKEReauthTimeSeconds is set to zero in order to disable it.

B. Certificate Authentication

For certificate authentication, the certificates first need to be uploaded to the SGW using Secure Copy (SCP). For a description of how to do this, consult your SCP client documentation.

Once uploaded, cOS Stream stores the certificate files until they are referenced by name to create Certificate objects. It is assumed here that the CA signed certificate file has the filename myfile.cer and the host certificate files have the filenames anotherfile.cer and anotherfile.key.

First, the CA signed certificate is added to the cOS Stream configuration:

System:/> add Certificate ca_signed_cert
			CertificateData=file://myfile.cer
			Type=Remote

Next, the host certificate is added:

System:/> add Certificate host_cert
			CertificateData=file://anotherfile.cer
			Type=Local
			PrivateKey=file://anotherfile.key

Now, the tunnel is created and this is done in a similar way to the tunnel definition with the PSK but this time the authentication method becomes Certificate and the certificate names are specified:

System:/> add Interface IPsecTunnel my_tunnel
			LocalAuthMethod=Certificate
			LocalID=site_a@local.net
			LocalNetwork=If3_net
			LocalEndpoint=If2_ip
			RemoteEndpoint=site_b_ip
			RemoteID=site_b@remote.net
			RemoteNetwork=site_b_net
			IPaddress=If3_ip
			IKEProposalList=ike_all
			IPsecProposalList=ipsec_all
			IKELifeTimeSeconds=604800
			IPsecLifeTimeSeconds=57600
			IKEReauthTimeSeconds=604800

The following should be noted about tunnel setup:

As explained above for the PSK tunnel, re-keying by either tunnel peer should be prevented.

CA Lookup

Certificate usage may require that certificates are validated against a Certificate Authority Server (CA server). This is possible with cOS Stream and the setup for this is described in Chapter 4, LTE.

Configure a Route Over the IPsec Interface

The routing table needs to be updated with a route over the IPsec interface in order to route the traffic to the 192.168.2.0/24 network of Site B through the tunnel.

First, the current context must be changed to the routing table called main:

System:/> cc RoutingTable main

The prompt will change to indicate the context and the route can be added:

System:/RoutingTable/main> add Route Interface=my_tunnel Network=site_b_net

This route will be appended after the last entry in the main routing table.

To change back to the default context, use the command:

System:/RoutingTable/main> cc

Configure IP Rules

The IP rule set needs to be updated with IP rules allowing TCP and UDP traffic connections to be initiated to/from the Site B network. First, the context must be changed to the be the IP rule set called main.

System:/> cc RuleSet IPRuleSet main

The prompt will change to indicate the new context and an IP rules can be added which allows connections originating from Site A going to Site B:

System:/IPRuleSet/main> add IPRule Action=Allow
			SourceInterface=If3
			SourceNetwork=If3_net
			DestinationInterface=my_tunnel
			DestinationNetwork=site_b_net
			Service=all_tcpudp
			Name=siteA_to_siteB

Now add a rule that allows connections originating from Site B to go to Site A:

System:/IPRuleSet/main> add IPRule Action=Allow
			SourceInterface=my_tunnel
			SourceNetwork=site_b_net
			DestinationInterface=If3
			DestinationNetwork=If3_net
			Service=all_tcpudp
			Name=siteB_to_siteA

Finally, return to the original context:

System:/IPRuleSet/main> cc

Configure Logging

In the Site A network, a syslog server is available that the SGW will use to send logs to. To configure the SGW to send log messages to the syslog server, use the following CLI command:

System:/> add LogReceiver LogReceiverSyslog syslog IPAddress=192.168.1.2

Activate and Commit Configuration Changes

Configuration changes do not become permanent until the CLI commands activate followed by commit are issued:

System:/> activate
		
System:/> commit

This chapter will detail the setup of LAN-to-LAN IPsec tunnel described in the previous chapter, but using a High Availability (HA) hardware cluster.

An HA cluster consists of two Clavister Firewalls running on identical hardware platforms with identical sets of Ethernet interfaces. One unit is designated the Master and the other is the Slave. Either the master or slave can be the active unit while the other is the passive. If the active unit should malfunction, a failover occurs and the passive unit becomes active and takes over all processing with almost no interruption.

This chapter will approach the setup description as follows:

Private and Shared IP Addresses

In a cluster, the matching Ethernet interfaces from each firewall form pairs, both of which have the same shared IP. It is this shared IP that is used in the cOS Stream configuration's policies and rules. However, an individual Ethernet interface can also have a unique private IP address which is used for:

In the previous chapter's LAN-to-LAN use case with a standalone firewall, the two physical Ethernet interfaces If2 and If3 are used. For a cluster, the shared IP addresses will remain the same for these interfaces but the private IP address of each interface must be reset to a unique value.

In summary, the following IPv4 addresses will be used for setting up HA LAN-to-LAN:

Usage of these IP addresses with the cluster master and slave is illustrated below.

HA Setup Steps

Having made the initial decisions about the IP addresses to use, the individual steps for setting up the HA cluster are as follows:

1. Select the Master and Slave

Both firewalls are at this point still standalone and identical but not physically connected to each other. It must be first decided which unit will be the Master and which will be the Slave. The choice is arbitrary but the master will be configured first.

The master's configuration will also overwrite the slave's configuration and becomes the initial configuration of the cluster. This is important to understand in case the slave configuration is important.

2. Open a Management CLI Connection

Using SSH, open a management CLI connection to the master's management interface.

3. Check the EthernetDevice Settings

On each Ethernet interface, the EthernetDevice:0 and EthernetDevice:1 properties should be the same and set to the device name of that interface. For example, check the If2 properties using the command:

System:/> show Interface EthernetInterface If2
		
        Property  Value
 ----------------  --------------------
            Name:  If2
 EthernetAddress:  <empty>
       PrivateIP:  0:<empty>  1:<empty>
          HAType:  Critical
  EthernetDevice:  0:If2  1:<empty>
             MTU:  1500
       IPAddress:  If2_ip
    IP4Broadcast:  <empty>
   RTBMembership:  main
        Comments:  <empty>

In the above example output, the property EthernetAddress:1 is incorrectly set to <empty> and this should be corrected with the command:

System:/> set Interface EthernetInterface If2 EthernetDevice:1=If2

In this example, the device name is the same as the interface name but this is not always true.

4. Set the Shared IP Addresses

The shared IPs for the LAN-to-LAN use case are set with the following commands:

System:/> set Interface EthernetInterface If2 Address=10.0.1.1

System:/> set Interface EthernetInterface If3 Address=192.168.1.1

5. Set the Private IP Addresses

The private IP addresses for these interfaces are now defined:

System:/> set Interface EthernetInterface If2
			PrivateIP:0=10.0.1.10 PrivateIP:1=10.0.1.11

System:/> set Interface EthernetInterface If3
			PrivateIP:0=192.168.1.10 PrivateIP:1=192.168.1.11

6. Set the Sync Interface

A pair of matching interfaces from each firewall will be connected together to form the Sync interface connection. This is the primary connection used for monitoring peer health in the cluster. In this use case, the interface If1 of is assumed to be used for this purpose so the following command should be issued:

System:/> Set Interface EthernetInterface If1 HAType=Sync

If If1 is used for system management, any other available interface should be used as the Sync interface instead. For the sake of illustration, If1 will be used here.

This command is repeated for both units in the cluster.

7. Set as the HA Master

To set this unit as the HA Master, the following command is entered:

System:/> set HighAvailability
			Role=Master
			ClusterID=1
			AutoSyncCfg=No
			Enabled=Yes

The new master configuration should finally be activated and committed.

The option AutoSyncCfg is disabled at this time so that manual control of the synchronization process can be retained. Overwriting of the slave's configuration with the master's will be initiated later.

8. Repeat Configuration for the Slave

Using SSH, open a management CLI connection to the management interface of the other unit and repeat steps 2 to 5.

Step 6 is also applied but must be changed to designate this unit as the HA slave. The following command is used to do this:

System:/> set HighAvailability
			Role=Slave
			ClusterID=1
			AutoSyncCfg=No
			Enabled=Yes

The modified slave configuration should then be activated and committed before continuing.

9. Physically Connect Together the Cluster Members

The separate firewalls can now be physically connected together. This is discussed further in the HA chapter of the separate cOS Stream Administration Guide

10. Synchronize Manually

The master's configuration can now overwrite the slave's configuration by entering the following command on the slave:

System:/> ha -recvconf

This pulls the configuration over from the master. The corresponding command on the master to push the configuration to the slave would be:

System:/> ha -sendconf

Both commands have the same effect of overwriting the slave configuration.

11. Enable Automatic Synchronization

Now the configurations have been synchronized manually, automatic synchronization can be enabled on both units. First on the slave:

System:/> set HighAvailability AutoSyncCfg=Yes

A connection to the CLI of the master should then be made and the same command issued on that unit. In both cases, the change should be activated and committed.

System:/> activate
		
System:/> commit

12. Verify the Cluster Status

After the two firewalls are connected together, synchronization between the cluster nodes will take place automatically. The CLI command ha will indicate that both systems are running in HA mode and that the nodes are alive.

If a firewall is not part of a HA cluster, the output when CLI command ha is applied to it will be:

System:/> ha
This device is a standalone system (HA not configured)

If it is the master node in an HA cluster, the output will be similar to the following:

System:/> ha
This device is a HA MASTER
This device is currently Active (for 48s)
HA cluster peer is ALIVE

The time shown in parentheses is the length of time that the cluster node has been in its current active or inactive state.

When the same CLI command is applied to the slave, the output will be similar to:

System:/> ha
This device is a HA SLAVE
This device is currently Active (for 47s)
HA cluster peer is ALIVE

The cluster will now be confirmed as being operational.

Making Further Cluster Configuration Changes

Once the cluster is operational, changing the configuration of both cluster firewalls is done by connecting to either with the CLI, making the configuration changes and then activating and committing the new configuration. When a new configuration is deployed on either peer, it is automatically copied to the other. In this way, the two cluster peers always maintain the same configuration.

Configuring LAN-to-LAN Tunnels

Now that the HA cluster is running, it is possible to continue by following the steps described in Chapter 2, LAN-to-LAN IKEv2/IPsec Tunnels. The cluster members act as a single unit and the interface names If2 and If3 used in the configuration, with IP addresses that are now shared, are the same.

This chapter examines the usage of cOS Stream in an example of a Long Term Evolution (LTE) use case in a telecoms environment.

The principle aim of the setup for the LTE use case is to create a LAN-to-LAN IPsec tunnel between a base station (the eNB) and a Clavister Firewall (the SEG) so that traffic can flow securely between the network behind the eNB and the S-GW. In addition to the standard LAN-to-LAN elements, the use case requires the following additional considerations:

With CA server validation of certificates, cOS Stream must resolve the Fully Qualified Domain Name (FQDN) of the CA server found in the certificate to an IP address. A validation request is then sent to the CA server using the protocol specified in the certificate. In the LTE case, the protocol will usually be Lightweight Directory Access Protocol (LDAP) and cOS Stream always sends LDAP server queries as anonymous requests.

The diagram below illustrates the role of the SEG in an LTE scenario. Only IPv4 addresses are used.

Configuration Assumptions

The following assumptions are made for the use case:

LTE Use Case Setup Steps

The steps for LTE IPsec tunnel setup are as follows:

1. Configure IP Addresses and Networks

To begin the configuration process, various IPv4 address objects should be created or set in the cOS Stream Address Book as summarized in the following table.

2. Check that Routing is Correct

Make sure that the routes for routing traffic over the interfaces are configured correctly.

3. Configure Certificates

The certificates to use for the IPsec tunnels must be uploaded to cOS Stream via the management interface using Secure Copy (SCP). For instructions on how to do this with a particular SCP client, consult the client's documentation.

Once uploaded, cOS Stream stores the certificate files until they are referenced by name to create Certificate objects. It is assumed here that the CA signed certificate file has the filename my_ca_signed.cer and the host certificate files have the filenames my_host.cer and my_host.key.

First, the CA signed certificate object is added to the cOS Stream configuration:

System:/> add Certificate ca_signed_cert
			CertificateData=file://my_ca_signed.cer
			Type=Remote

Next, the host certificate object is added:

System:/> add Certificate host_cert
			CertificateData=file://my_host.cer
			Type=Local
			PrivateKey=file://my_host.key

4. Configure the IPsec Tunnel

An IPsec tunnel object is created for eNB1 with the authentication method specified as Certificate along with the certificate names:

System:/> add Interface IPsecTunnel eNB1_tunnel
			LocalAuthMethod=Certificate
			LocalID=site_a@local.net
			LocalNetwork=S1-U_net
			LocalEndpoint=If2_ip
			RemoteEndpoint=eNB1_ip
			RemoteID=eNB@remote.net
			RemoteNetwork=eNB1_net
			IPaddress=If3_ip
			IKEProposalList=ike_all
			IPsecProposalList=ipsec_all
			IKELifeTimeSeconds=43200
			IPsecLifeTimeSeconds=28800
			IKEReauthTimeSeconds=0

The following should be noted about tunnel setup:

5. Configure a Route over the IPsec Interface

The routing table main needs to be updated with a route for the IPsec interface in order to route traffic to eNB1_net through the tunnel.

First, change the current CLI context to be the routing table called main:

System:/> cc RoutingTable main

The prompt will change to indicate the new context. The route can now be added:

System:/RoutingTable/main> add Route Interface=eNB1_tunnel Network=eNB1_net

This route will be appended after the last entry in the main routing table.

To change back to the default CLI context, use the command:

System:/RoutingTable/main> cc

6. Configure IP Rules

The cOS Stream IP rules need to be updated to allow traffic flow between the networks eNB1_net and S1-U_net.

Add an IP rule which allows flows originating from eNB1_net network and going to the S1-U_net network:

System:/> add IPRule Action=Allow
			SourceInterface=eNB1_tunnel
			SourceNetwork=eNB1_net
			DestinationInterface=If3
			DestinationNetwork=S1-U_net
			Service=all_tcpudp
			Name=eNB1_to_S1-U

Now, add an IP rule that allows traffic flows originating from network S1-U_net and going to eNB1_net:

System:/> add IPRule Action=Allow
			SourceInterface=If3
			SourceNetwork=S1-U_net
			DestinationInterface=eNB1_tunnel
			DestinationNetwork=eNB1_net
			Service=all_tcpudp
			Name=S1-U_to_eNB1

7. Repeat Tunnel/Route/IP Rules Setup for each eNB

Each base station requires the steps (4) to 6 above to be repeated.

With the assumptions made in this use case, the following properties need to be changed for eNB2:

8. Configure Syslog Logging

In the mgmt_net network, a syslog server is located that the SEG will send log event messages to. Assume that the server's IP address is the already defined in the address book object as syslog1_ip. Configure the server:

System:/> add LogReceiver LogReceiverSyslog syslog IPAddress=syslog1_ip

No IP rules are required to allow log message flows to the syslog server because cOS Stream itself is the source. This is also true for a DNS server which is set up next.

9. Configure a DNS Server

In cOS Stream up to 8 DNS servers can be configured. For this use case, only one will be configured and the IP address of the server is assumed to be the address book object dns1_ip.

Define the DNS server using this IP address object:

System:/> set DNS DNSServers=dns1_ip

This DNS server can now be used by cOS Stream to send validation requests to the relevant CA server for a certificate by resolving certificate FQDNs.

10. Activate and Commit Configuration Changes

Once the configuration changes have be made permanent, the IPsec tunnels between the networks eNB_net and S1-U_net can be established.