Table of Contents
|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:
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.
ScenarioIn 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 AssumptionsIt 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:
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 NetworksIn 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:
Routes can optionally be assigned a name for greater clarity.
Before continuing, change the context back to the default:
All routes in the active routing table can be displayed with the CLI command:
Configure the IPsec TunnelIn 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: 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 LocalIDemail@example.com RemoteIDType=E-Mail RemoteIDfirstname.lastname@example.org Type=ASCII PSKAscii=somesharedsecretcode
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 LocalIDemail@example.com LocalNetwork=If3_net LocalEndpoint=If2_ip RemoteEndpoint=site_b_ip RemoteIDfirstname.lastname@example.org 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
System:/>time -set 2010-06-24 14:43:00
|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 LocalIDemail@example.com LocalNetwork=If3_net LocalEndpoint=If2_ip RemoteEndpoint=site_b_ip RemoteIDfirstname.lastname@example.org 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 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 LookupCertificate 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 InterfaceThe 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:
Configure IP RulesThe 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.
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:/>cc RuleSet IPRuleSet main
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: 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:
|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 LoggingIn 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 ChangesConfiguration changes do not become permanent until the CLI commands activate followed by commit are issued:
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 AddressesIn 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:
|Interface||Shared IP||Master IP||Slave IP|
Usage of these IP addresses with the cluster master and slave is illustrated below.
As is the case here, the private IP addresses chosen are usually from the same network as the shared IP address.
HA Setup StepsHaving 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 SlaveBoth 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 ConnectionUsing SSH, open a management CLI connection to the master's management interface.
3. Check the EthernetDevice SettingsOn 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:
In the above example output, the property EthernetAddress:1 is incorrectly set to <empty> and this should be corrected with 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 this example, the device name is the same as the interface name but this is not always true.
System:/>set Interface EthernetInterface If2 EthernetDevice:1=If2
4. Set the Shared IP AddressesThe 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 AddressesThe 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 InterfaceA 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:
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.
System:/>Set Interface EthernetInterface If1 HAType=Sync
This command is repeated for both units in the cluster.
7. Set as the HA MasterTo set this unit as the HA Master, the following command is entered:
The new master configuration should finally be activated and committed.
System:/>set HighAvailability Role=Master ClusterID=1 AutoSyncCfg=No Enabled=Yes
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: 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 SlaveUsing 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 MembersThe 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 ManuallyThe master's configuration can now overwrite the slave's configuration by entering the following command on the slave:
This pulls the configuration over from the master. The corresponding command on the master to push the configuration to the slave would be:
Both commands have the same effect of overwriting the slave configuration.
11. Enable Automatic SynchronizationNow the configurations have been synchronized manually, automatic synchronization can be enabled on both units. First on the slave:
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:/>set HighAvailability AutoSyncCfg=Yes
12. Verify the Cluster StatusAfter 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 ChangesOnce 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: 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 TunnelsNow 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:
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: 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.
Configuration AssumptionsThe following assumptions are made for the use case:
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: 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 StepsThe steps for LTE IPsec tunnel setup are as follows:
1. Configure IP Addresses and NetworksTo 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 CorrectMake sure that the routes for routing traffic over the interfaces are configured correctly.
3. Configure CertificatesThe 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: 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 TunnelAn 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 LocalIDemail@example.com 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:
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 InterfaceThe 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:
6. Configure IP RulesThe 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:
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:
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 eNBEach 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 LoggingIn 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 ServerIn 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 ChangesOnce the configuration changes have be made permanent, the IPsec tunnels between the networks eNB_net and S1-U_net can be established.