cOS Stream 4.00.00 Use Case Guide


Table of Contents

1. Overview
2. LAN-to-LAN IKEv2/IPsec Tunnels
3. HA and LAN-to-LAN IKEv2/IPsec
4. LTE

Chapter 1: Overview

[Note] Note: This document is also available in other formats

A PDF version of this document along with all current and older documentation in PDF format can be found at https://my.clavister.com.

It is also available in a framed HTML version.

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:

  • cOS Stream Administration Guide.
  • cOS Stream CLI Reference Guide.
  • cOS Stream Log Reference Guide.
  • cOS Stream Statistics Reference Guide.
  • The relevant Clavister Getting Started Guide for the platform running cOS Stream.

Chapter 2: LAN-to-LAN IKEv2/IPsec Tunnels

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.

The LAN-to-LAN IPsec Use Case

Figure 2.1. The LAN-to-LAN IPsec Use Case

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.

[Tip] Tip: Tab completion lists mandatory properties first

When using tab completion with the CLI to list object properties, only mandatory properties are listed first. Optional properties are only listed after all mandatory properties have been entered. For example, the Name= property for an IPRule can be entered at any time but tab completion only lists it after all mandatory properties have been entered.

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

[Note] Note

The value somesharedsecretcode in the above should be replaced with the actual shared key which is used on both sides of the tunnel.

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

  • The clock can be set manually through the CLI. For example:
    System:/> time -set 2010-06-24 14:43:00
  • NTP servers can be configured in cOS Stream so that they are queried automatically on system startup and the clock is set automatically. This method is recommended. Details on NTP configuration can be found in the separate Administration Guide.

[Note] Note: Date and time format

When setting the date and time, the date is entered in yyyy-mm-dd format and the time is stated in 24 hour hh:mm:ss format.

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:

  • The certificate used for authentication is selected by the remote peer sending a hash of its root certificate and cOS Stream using this to find a local host certificate that can be validated by the client. The LocalID property of the tunnel must match the Subject or Subject Alternative Name of the chosen host certificate.
  • All certificates required for a certificate chain between a root certificate and the host certificate must be uploaded into cOS Stream as these will also be sent to the remote peer.
  • The value of the local tunnel's LocalID property must be the same as the RemoteID property on the remote peer. Similarly, the value of the local tunnel's RemoteID property must match the LocalID property on the remote peer. For example, if one side has LocalID=my_id1 and RemoteID=my_id2 then the other side should have LocalID=my_id2 and RemoteID=my_id1.

    A wild card asterisk character "*" could alternatively be used for the RemoteID if any remote peer is allowed to connect. Using a wild card is not recommended, but some value for this property should be specified.

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

[Note] Note: The Name parameter is optional

The Name parameter is optional for an IP rule but it is recommended that it is included for clarity. Because it is optional, tab completion will not list it.

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

[Note] Note: More restrictive IP rules are better

The IP rules above define relatively unrestrictive security policies. Normally, it is preferable to restrict traffic using a service with more specific protocols and ports.

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

Chapter 3: HA and LAN-to-LAN IKEv2/IPsec

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:

  • The two individual firewalls will be configured as cluster members before they are physically connected together.
  • Once the firewalls are configured, the Ethernet interfaces pairs of each will be connected together so the cluster becomes operational.
  • Once the cluster is operational, the previous Chapter 2, LAN-to-LAN IKEv2/IPsec Tunnels can be followed using the same interface names.

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:

  • SSH management access to the firewall.
  • As the source IP for log messages.

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:

Interface Shared IP Master IP Slave IP
If2 10.0.1.1 10.0.1.10 10.0.1.11
If3 192.168.1.1 192.168.1.10 192.168.1.11

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

Private and Shared IP Addresses

Figure 3.1. Private and Shared IP Addresses

[Note] Note

As is the case here, the private IP addresses chosen are usually from the same network as the shared IP address.

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.

[Important] Important: The cluster ID must be unique

The ClusterID in the above command must be a unique value for clusters that have a network connection with each other. If setting up a second cluster that has a network connection to the cluster in this use case, another ID must be used. For example, ClusterID=2.

Within the same cluster, both the master and slave must have the same ID.

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.

[Note] Note: The private IP is used for management connection

When connecting to either cluster member using SSH, it is the private IP address of the management Ethernet interface that must be used. The shared IP of the management interface should not be used.

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.

Chapter 4: LTE

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:

  • DNS Server Access

    A DNS server must be accessible from the SEG and this must be configured in cOS Stream.

  • CA Server Access

    A private CA server will be accessible via a network connected to the SEG. This server must be configured to allow anonymous LDAP requests. Microsoft documentation might refer to these request types as Anonymous LDAP Binding.

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.

[Note] Note: IP rules are not needed for cOS Stream generated requests

When a request to a server is initiated by cOS Stream itself, no IP rules are required in the cOS Stream configuration for the flow to be allowed.

Such requests are always considered to be trusted and therefore DNS lookups and CA server requests generated by cOS Stream do not require IP rules to be defined.

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

The LTE Use Case

Figure 4.1. The LTE Use Case

Configuration Assumptions

The following assumptions are made for the use case:

  • The Clavister Firewall has a base cOS Stream configuration with default cOS Stream address book objects created for interface IP addresses and networks.
  • The If2 Ethernet interface will be used for connection to the base station (eNB) network 10.0.1.0/24 (eNB_net) and all base stations are assumed to be members of this network.

    In this use case, individual base stations will be given the designation eNB1, eNB2 and so on.

  • Behind each base station is another network with which the S-GW will communicate through a LAN-to-LAN IPsec tunnel.

    Behind eNB1 is the network 10.1.1.0/24 (eNB1_net). Behind eNB2 is the network 10.2.1.0/24 (eNB2_net) and so on.

  • The If3 Ethernet interface will be used for the connection to the protected network 192.168.1.0/24 (S1-U_net) which has the S-GW as a member.

[Note] Note: Arbitrary private IP addresses are used in this description

Arbitrary private IP addresses are used throughout this use case description. Public IPs could be used instead for communication that takes place over the public Internet.

  • The If1 interface is connected to the protected management network 192.168.2.0/24 on which an internal DNS server, Syslog server and SNMP monitor are located.

    The location of the CA server is on some network which is accessible from the SEG. In the diagram above, it is shown connected to the eNB network. The server's actual IP address will be discovered through certificate FQDN resolution using the DNS server.

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.

Address Book Name IPv4 Address Description
eNB1_net 10.1.1.0/24 Network behind the base station eNB1.
eNB2_net 10.2.1.0/24 Network behind the base station eNB2.
S1-U_net 192.168.1.0/24 The network linking the SEG and the S-GW.
eNB_net 10.0.1.0/24 The network connecting the base stations.
mgmt_net 192.168.2.0/24 Management network containing Syslog and DNS servers.
If2_ip 10.0.1.1 Part of the network eNB network.
If2_net eNB_net The eNB network.
If3_ip 192.168.1.1 Part of the network S1-U_net.
If3_net S1-U_net The S1-U network.
eNB1_ip 10.0.1.2 eNB1 base station's IP and the Remote Endpoint for its IPsec tunnel.
eNB2_ip 10.0.1.3 eNB2 base station's IP and the Remote Endpoint for its IPsec tunnel.
If1_ip 192.168.2.1 Management network interface IP.
If1_net mgmt_net The management network
syslog1_ip 192.168.2.5 Address of the syslog server on mgmt_net.
dns1_ip 192.168.2.6 Address of the DNS server on mgmt_net

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

[Important] Important: Certificates need the system clock to be correct

It is essential that the system clock is set correctly so that the validity dates inside certificates are interpreted correctly. Configuring an NTS time server is recommended.

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:

  • The host certificate sent by the SEG (cOS Stream) to the eNB for authentication is selected by the eNB sending a hash of its root certificate and then cOS Stream uses this to find a host certificate that can be validated by the eNB.
  • The SEG's LocalID property for the tunnel must also be the same as the Subject or Subject Alternative Name of the certificate chosen.
  • If there is a certificate chain between a root certificate and the host certificate chosen then all certificates in the chain must be uploaded into cOS Stream as these will also be sent to the eNB for the validation process.
  • The value of the tunnel's LocalID property on the SEG must be the same as the RemoteID property defined on the remote eNB.
  • Similarly, there must also be a match between the tunnel's RemoteID property on the SEG and the LocalID property defined on the remote eNB. Since this value is usually unique for each eNB, the wildcard asterisk "*" character should be used when specifying the RemoteID property on the SEG.

    For example, specifying the SEG's RemoteID property as "*" means that all LocalID values on eNBs are acceptable. Alternatively, it might be the case that the SEG's RemoteID property is given the value "*@sim*". This means that only eNBs with their LocalID containing the string @sim will be able to connect.

    If examining the IKE negotiation with the cOS Stream ikesnoop command, the IDi value is sent by the eNB (the initiator) to the SEG and the IDr value is sent by the SEG (the receiver) to the eNB. The IDi value must match the SEG's RemoteID property and the IDr value will be the SEG's LocalID value.

  • The tunnel properties 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 rekey 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.

    The recommended numerical time values used in this use case are 12 hours (43200 seconds) and 8 hours (28800 seconds). The value of IKEReauthTimeSeconds should be set to zero in order to disable it.

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:

  1. For the IPsec tunnel object, the RemoteEndpoint becomes eNB2_ip and the RemoteNetwork becomes eNB2_net.
  2. For the route, the Network is changed to eNB2_net and the Interface becomes eNB2_tunnel.
  3. For the IP rules, the network eNB1_net becomes eNB2_net and the interface changes from eNB1_tunnel to eNB2_tunnel.

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.