Not supported by SBC SWe Lite in this release.
In this section:
This article describes the steps necessary to configure the SBC 1000/2000 for IPsec.
Internet Protocol Security (IPsec) is a protocol suite for securing Internet Protocol (IP) communications by authenticating and encrypting each IP packet of a communication session. The IPsec enabled SBC gateway secures data transmission between the subnets behind the branch remote offices and the corporate headsquarters (HQ). IPsec tunnels are established and maintained to provide for data privacy, integrity, authenticity, and anti-replay protection for network traffic over Internet-based connections.
The procedures outlined in this document are best practice recommendations and guidelines for the steps requires to set up an IKEv2 connection between SBC gateways with IPSec Tunnel Tables.
First, determine how to authenticate both SBC IPsec enabled peers to each other. Configure a preshared key as a strong pass-phrase or install a digital RSA certificate with a stronger 2048-bit key option. This is used for authentication and to ensure the IPsec gateways are authorized by proving their identities to each other. Both gateways must use the same type of credentials – either preshared keys or digital certificates. Preshared keys are shared with the gateway peer, therefore both keys must match.
The tunnel connection definition is configured and negotiated in two phases. In phase 1, set up a secure and encrypted channel (required to protect the phase 2 negotiations). In phase 2, establish the IPSec Security Association (SA) to tell the gateway what traffic is being sent over the tunnel, and how to encrypt and authenticate it.
Internet Key Exchange (IKE) is accessed via UDP port 500. IP port 50 must be used for the Encapsulating Security Payload (ESP). The NAT Traversal is assigned to UDP port 4500.
When NAT is present, UDP port 4500 is used in the tunnel path.
The establishment of a single IKE SA using the IKEv2 protocol requires an exchange of four UDP datagrams as shown in the illustration below.
The task of resending messages falls to the initiator only. The IKE_SA_INIT message carries the selection of cryptographic transforms for the IKE SA, the derivation of a common Diffie-Hellman secret and the nonces into a single exchange. The IKE_AUTH message authenticates the peers using the pre-shared keys(PSK)or the RSA signatures supported by the SBC to create the first so-called Child SA by defining the traffic selectors and cryptographic transforms for the IPsec connection.
The establishment of a single or multiple Child SA using the IKEv2 protocol requires an exchange of a CREATE_CHILD_SA request/response pair as shown in the following illustration. The message carries the cryptographic transforms, a pair of fresh nonces, an optional Diffie-Hellman exchange if PFS is desired and the additional traffic selectors.
The SBC gateway defines a hard-coded time interval of 30s with which keep-alive INFORMATIONAL exchanges are sent to the peer. These are only sent if no other traffic is received. All connections with a dead peer are stopped and unrouted. The gateway also defines a hard-coded timeout interval of 60s, after which all connections to a peer are deleted and the IKE and Child Security Associations(SA) are cleared in case of inactivity.
When upgrading to version 3.0 existing Ribbon SBC Certificates will fail authentication due to key integrity verification errors when used to bring up the IPsec tunnel in the Certificate authentication mode. Before beginning to manage an IPsec tunnel for Certificate authentication, must generate a new Certificate Signing Request (CSR), re-sign, and re-import a new RibbonSBC Certificate.
The configuration settings and examples in following sections are based on network a topology comprising a single SBC gateway at two different branch sites, behind an external NAT accessing the corporate gateway or the servers in the subnet behind the corporate gateway over public internet access.
Network Topology
The following information refers to the Create IPsec Tunnel Entry page of the SBC user interface.
For more information see: Managing IPsec Tunnels and Creating and Modifying IPsec Tunnel Entries.
Configure the local host internal subnet to allow traffic to and from the selected hosts/networks at the remote site.
When specifying the local and/or remote site peer address as an FQDN address type, the DNS Server must be configured to resolve the FQDN.
Initiator
Either an SBC 1000 or SBC 2000 IPsec enabled gateway can be deployed at branch offices sites which will negotiate the tunnel in an active mode of operation.
This setting is applicable for the IPsec enabled gateway configured in an Initiator mode of operation.
Local Address: Ethernet 2 IP(10.1.1.10)
Remote Address: 10.1.2.20
Local Subnet Addresses: 172.20.1.10/32,172.20.1.20/32
Remote Subnet Addresses: 172.20.5.0/24
Tunnel Name: Branch2_SBC 2000
Local Address: branch2sbc.uxdev.com
Remote Address: hqsbc.uxdev.com
Local Subnet Addresses: 172.20.6.0/24
Remote Subnet Addresses: 172.20.5.3/32,172.20.5.4/32,172.20.5.5/32,172.20.5.6/32
The networking configuration must be the exact opposite of those configured on each branch office sites, that is, reverse the Local Address, Remote Address, Local Subnet Addresses and Remote Subnet Addresses used on the branch office when setting up a one-to-one tunnel connection entry on the headquarters SBC 2000.
Local Address: Ethernet 2 IP(10.1.2.20)
Remote Address: 10.1.1.10
Remote Subnet Addresses: 172.20.1.0/24
Remote Address: branch2sbc.uxdev.com
Policy-based Firewall Rules
The Apply Policy Rules field is enabled by default and automatically inserts bi-directional FORWARD rules on gateways or an INPUT and OUTPUT rule on single hosts, and adds an INPUT and OUTPUT rule to reach the gateway itself when the tunnel is established. Likewise, these rules are deleted when the tunnel is disconnected.
Use of the policy module depends on how the rest of the firewall is configured and the exact requirements.
When the forwarding-firewalling feature is enabled, the iptables policy module rules-matches packets based on their relation to IPsec policies which will do everything related to only allow traffic from/to the tunneled subnet and not the whole subnet via the IPsec tunnels. The Apply Policy Rules field can be disabled if there is a business case requirement to configure custom IPsec ACCEPT/DROP rules which take precedence in relation to the automatically created IPsec rules.
Policy-based Source Routing Table
In a simple network topology with no nexthop gateway between the subnet and the local internal network interface on the SBC 2000 gateway, the policy-based source routing entries are created automatically.
To enable the policy-based source routing capabilities: the source address must be the local internal network interface. The Local Subnet Addresses list must include the local internal network address, and the Remote Subnet Addresses must contain the peer's internal network address.
For example:
1) On the Branch1_SBC 2000 gateway (Refer to Network Topology Diagram section), the Ethernet 1 IP(172.20.1.10) is the local internal network interface. This address should be added to the Local Subnet Addresses as 172.20.1.10/32 or automatically included when specifying the address range such as 172.20.1.0/24. Likewise, on the Branch1_SBC 2000 gateway, the Ethernet 1 IP(172.20.5.3) which is the remote internal network interface configured on the HQ_SBC 2000 gateway should be added to the Remote Subnet Addresses as 172.20.5.3/32 or automatically included when specifying the address range such as 172.20.5.0/24.
2) On the HQ_SBC 2000 gateway (Refer to Network Topology Diagram ), the networking configuration must be the exact opposites of the ones configured on each branch office sites. Reverse the Local Subnet Addresses and Remote Subnet Addresses used on the branch office when setting up a one-to-one tunnel connection entry on the headquarters SBC 2000.
Specify either the peer address of the remote site (outside interface IP of the peer SBC 2000 gateway) or the remote identifier when enabling the Allow Any Remote Address field in case of the remote host behind NAT. Use either an existing or new pre-shared key to be configured the same between the SBC 2000 gateway peers.
Branch1_SBC Tunnel Connection Definition
Branch2_SBC Tunnel Connection Definition
HQ_SBC Tunnel Connection Definitions
Tunnel connection definitions on headquarters SBC 2000 gateway can be configured in two possible ways as indicated by the examples below.
Single Tunnel Connection for all Branch Sites
A single tunnel ID can be configured on the headquarters SBC 2000 to negotiate the traffic selectors from any branch office by specifying any remote address as an identifier selector.
Multiple Tunnel Connections for each Branch Site
The need to create multiple tunnels on the headquarters SBC 2000 as one-to-one mapping with branch sites is highly recommended when there is a greater interest in maintaining separate tunnels and/or analyzing the IPsec Statistics data corresponding to each branch sites.
Remote Address: 10.1.1.10
Remote Address: 10.1.1.30
Branch1_SBC Tunnel Connection Definition
Branch2_SBC Tunnel Connection Definition
HQ_SBC Tunnel Connection Definitions
Remote Address: 10.1.1.10
Remote Address: 10.1.1.30
As a best practice where security is of concern for multiple branch office SBC 2000 deployments, generating a new Certificate Signing Request, acquiring and installing a digital signed certificate and Trusted Certificate Authority (CA) root chain is recommended.
The CA file(s) which signed the Ribbon SBC 2000 Certificate must be exported from each branch office SBC 2000 (if these are different CA vendors) and imported on the headquarters SBC 2000.
Likewise, the CA file(s) which signed the Ribbon SBC 2000 Certificate must be exported from the headquarters SBC 2000 and imported on each of the branch office SBC 2000 gateways.
The CA file(s) must be imported/exported under the Web UI Security navigation pane * > Certificates > Trusted CA* folder.
Specify the Certificate Identifier as Subject Alternative Name (IPsec Tunnel Table navigation pane > Remote Attributes panel) on the branch office SBC 2000. To do this, copy one of the Subject Alternative Names display text (IPsec Tunnel Table navigation pane > Local Attributes read-only panel) from the headquarters SBC 2000 gateway and paste it in the Certificate Identifier field text box under the Remote Attributes panel of the branch office SBC 2000. Likewise, copy the Subject Alternative Name text (IPsec Tunnel Table navigation pane > Local Attributes read-only panel) on the branch office SBC 2000 gateway and paste it in the Certificate Identifier field text box under the Remote Attributes section of the headquarters SBC 2000. When specifying a peer certificate's SAN identifier, enable and specify the local SAN identifier under the Local Attributes section on the branch office and headquarters SBC 2000 gateways. These additional field configurations are mandatory in order to perform a successful look-up and match of an expected SAN identifier against the configured SAN identifier.
The following sections are examples for authenticating a peer gateway using the SAN identifier:
Branch1_SBC Tunnel Connection Definition
Use SAN Identifier: Enabled
Branch2_SBC Tunnel Connection Definition
HQ_SBC Tunnel Connection Definitions
Remote Address: 10.1.1.10
Remote Address: 10.1.1.30
Specify the Certificate Identifier as Subject Distinguished Name(IPsec Tunnel Table navigation pane -> Remote Attributes panel) on the branch office SBC 2000. To do this, copy the Subject Distinguished Name display text(IPsec Tunnel Table navigation pane -> Local Attributes read-only panel) from the headquarters SBC 2000 and paste it in the Certificate Identifier field text box under the Remote Attributes panel of the branch office SBC 2000. Likewise, copy the Subject Distinguished Name display text(IPsec Tunnel Table navigation pane -> Local Attributes read-only panel) from the branch office SBC 2000 gateway and paste it in the Certificate Identifier field text box under the Remote Attributes panel on the headquarters SBC 2000 gateway.
Branch1_SBC Tunnel Connection Definition
Use SAN Identifier: Disabled
Branch2_SBC Tunnel Connection Definition
Use SAN Identifier: Disabled
HQ_SBC Tunnel Connection Definitions
Remote Address: 10.1.1.10
Remote Address: 10.1.1.30
One significance of configuring 'any' certificate identifier is to simplify the configuration steps at the headquarters SBC 2000 gateway in larger deployments.
The Trusted Certificate Authority file(s) must be exported from each branch office SBC 2000 gateway and imported to the headquarters SBC 2000 gateway. This is the only configuration step required in order to perform a successful look-up and match of an expected SAN or DN dentifier against the 'any' identifier configured on the SBC 2000 gateway peer,
The configuration examples for authenticating the peer gateway using 'any' SAN or DN identifier is provided below.
HQ_SBC Tunnel Connection Definition using Any SAN Identifier
A single tunnel ID can be configured to negotiate the traffic selectors from any branch offices by specifying a local SAN identifier, 'any' remote address and 'any' peer certificate's SAN identifier.
The branch sites SBC 2000 tunnel connection is unchanged from the example provided in 'Using SAN Identifier' section above.
HQ_SBC Tunnel Connection Definition using Any DN Identifier
A single tunnel ID can be configured to negotiate the traffic selectors from any branch offices by specifying 'any' remote address and 'any' certificate DN identifier.
The branch sites SBC 2000 tunnel connection is unchanged from the example provided in 'Using DN Identifier' section above.
Each branch office site can specify various authentication mode (Certificate or PSK) and identifier type(same secret, different secret, SAN or DN).
The headquarters SBC 2000 should create a one-to-one tunnel connection mapping to match whichever authentication mode specified on the branch office SBC 2000.
Branch1_SBC Tunnel Connection Definition
Use SAN Identifier: Disabled
Branch2_SBC Tunnel Connection Definition
HQ_SBC Tunnel Connection Definitions
It is recommended that the transform data such as selection of encryption level, authentication algorithm and diffie-hellman group (DH Group) be configured the same way on the SBC 2000 gateway deployed at each branch office sites communicating with another SBC 2000 gateway at the headquarters site.
Choose the default settings: 1) IKE: aes128-sha1-modp2048 and IPSEC: aes128-sha1 or consider selecting stronger transform algorithms 2) IKE: aes256-sha256-modp2048 and IPSEC: aes256-sha256 when considering security measures.
IPsec connection can be successfully established between the SBC 2000 peers in case of non-matching Encryption, Integrity or DH Group parameters.
In case of mismatched encryption settings, the Responder gateway's configured cipher settings will take precedence over the proposed one received from the Initiator gateway. In case of a DH Group mismatch, the initiator or responder side with stronger key takes the precedence.
Selection of 3DES is supported mainly for the purpose of compatibility with non-SBC 2000 devices that do not support AES.
It is recommended to select AES encryption level since the throughput rate with the 3DES encryption will be significantly less and slower than the AES.
By default, both the SA Expiry and Reauthentication key protection measures are disabled since achieving better throughput and low latency for high call load traffic going in and out of the tunnel may be a bigger concern. Based on the business case requirements, whether a low or high degree of security measures are to be taken to protect the keys, then the SA Expiry, Reauthentication, and/or Perfect Forward Secrecy should be enabled under the SA Expiry and Security Settings panel.
The negotiation of IKE SAs and IPsec SAs can be configured to expire after a specific amount of time. By default, the IKE Lifetime is set to 3 hours, whereas the IPsec lifetime is set to 1 hour as to avoid collisions of these SAs expiring at same time.
The Margin Time field is supported to avoid collisions when the SA Expiry and Reauthentication are enabled on the SBC 2000 gateway deployed at both branch offices and the headquarters sites.
The specified margins are increased randomly(hard-coded percentage on initiator and responder gateway by which margins are randomly increased) before subtracting them from the expiration limits.
The formula shown below is used to calculate the rekey time of IKE and IPsec SAs.
Actual IKE rekey time = *IKE Lifetime* - (*Margin Time* + random(0, *Margin Time* * 100%)) Actual IPsec rekey time = *IPsec Lifetime* - (*Margin Time* + random(0, *Margin Time* * 100%))
Actual IKE rekey time = *IKE Lifetime* - (*Margin Time* + random(0, *Margin Time* * 10%)) Actual IPsec rekey time = *IPsec Lifetime* - (*Margin Time* + random(0, *Margin Time* * 10%))
The IPsec tunnel attempts to rekey the IPsec SA at a random time between 40 and 50 minutes after establishing the SA.
In other words, between 10 and 20 minutes before the SA expires.
1. IPsec Lifetime: 1h
2. Margin Time: 600s(10m)
Actual Minimum IPsec rekey time = 1h - (10m + 10m) = 40m Actual Maximum IPsec rekey time = 1h - (10m + 0m) = 50m