Not applicable to SBC SWe Edge.
In this section:
Site to Site IPsec Settings in a Nutshell
This article describes the steps necessary to configure the
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
The procedures outlined in this document are best practice recommendations and guidelines for the steps requires to set up an IKEv2 connection between
First, determine how to authenticate both
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.
Phase 1 Settings
- Specify both Unable to show "metadata-from": No such page "_space_variables"gateway addresses. Specify the address of the localUnable to show "metadata-from": No such page "_space_variables"gateway and the address of the remoteUnable to show "metadata-from": No such page "_space_variables"gateway as an IP address or a Fully Qualified Domain Name(FQDN).
- Specify the authentication mode as preshared key or certificate. When using the digital certificate, specify the subject Distinguished Name (DN) field or the Subject Alternative Name (x509v3 Extension SAN field) of the peer's certificate. If certificates is not used, as recommended for larger deployments where security measures are of concern, then specify a long and complex preshared key. The preshared key must be a strong password or a pass-phrase represented as hexadecimal or Base64 encoded binary values.
- Choose a transform set, which includes the type of encryption, authentication and how long the security association will last. Select Sha256 if required to use a stronger authentication algorithm. Select either 3DES or AES 128, 256 bit key strength for encryption. Select AES 256 as this is the strongest encryption protocol. Specify a Diffie-Hellman key group, usually 1, 2, 5 or 14 (14 is the most secure group).
- Specify an IKE lifetime for the IKE SA, which adds more security to Unable to show "metadata-from": No such page "_space_variables"gateway if the keys have been hacked. Although this will also have a slight affect on performance as well.
Phase 2 Settings
- Specify what traffic will go across the tunnel using the IP address, Network address, or IP address range. This is access to the Unable to show "metadata-from": No such page "_space_variables"gateway's internal network, so either remote users from home, or the peer office can have access to resources behind theUnable to show "metadata-from": No such page "_space_variables"IPsec enabled gateway.
- Choose whether to use Perfect Forward Secrecy (PFS), for optional and an extra layer of security. When enabling PFS, both Unable to show "metadata-from": No such page "_space_variables"gateway peers must support and use PFS. Select which Diffie-Hellman group to use for new keying material. The higher the group selected such as DH Group 14, the stronger the key.
- Specify the encryption and authentication algorithms, securing the data in the IPsec SA (Phase 2 Proposal). The only type of proposal supported on the Unable to show "metadata-from": No such page "_space_variables"gateway is ESP to provide authentication and encryption. Specify the authentication and encryption algorithm and protocol which will be the same as ones chosen for Phase 1 settings as to simplify the configuration steps when establishing the tunnel with anotherUnable to show "metadata-from": No such page "_space_variables"gateway peer.
- Specify the IPsec lifetime for the IPsec SA. This ensures that the encryption keys change over a period of time and have them recreated, adding more security, as well as having a slight affect on performance.
Final steps
- Create policies or rules that allow the tunneled traffic in and out of the firewall based on the topology firewalling requirements. The option to either enable or disable the firewall policy rules on Unable to show "metadata-from": No such page "_space_variables"IPsec enabled gateway will automatically insert the policy based match traffic rules.
- Configure the Unable to show "metadata-from": No such page "_space_variables"gateway peer with the exactly the same settings and/or the reverse of its peer's settings as configured on the local gateway for some of the fields. If the peer settings are not reversed, this will result in a failure to establish a tunnel and it's service status will appear as Down.
IKEv2 SA Message Exchange Flow
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.
IKE SA
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
IPsec SA
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.
Dead Peer Detection Keep-Alive
The
Prerequisites
- An IPsec license is required to manage IPsec tunnels.
- A Unable to show "metadata-from": No such page "_space_variables"Unable to show "metadata-from": No such page "_space_variables"Certificate and Trusted CA Certificate must be obtained and imported to theUnable to show "metadata-from": No such page "_space_variables"when Certificate is selected from the Authentication Mode list box in the Authentication Parameters panel. Refer to Working with Certificates for information about configuring certificates on theUnable to show "metadata-from": No such page "_space_variables".
When upgrading to version 3.0 existing
Unable to show "metadata-from": No such page "_space_variables"Unable to show "metadata-from": No such page "_space_variables"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 newUnable to show "metadata-from": No such page "_space_variables"Unable to show "metadata-from": No such page "_space_variables"Certificate.
Network Topology Diagram
The configuration settings and examples in following sections are based on network a topology comprising a single
Network Topology
General Configuration Notes
The following information refers to the Create IPsec Tunnel Entry page of the
For more information see: Managing IPsec Tunnels and Creating and Modifying IPsec Tunnel Entries.
Networking Properties
- Specify the local and remote site peer address (outside interface IP of the Unable to show "metadata-from": No such page "_space_variables"gateway).
Configure the local host internal subnet to allow traffic to and from the selected hosts/networks at the remote site.
- A maximum of 10 subnet addresses can be configured per tunnel connection entry.
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.
Operating Mode
Initiator
Either an
Unable to show "metadata-from": No such page "_space_variables"orUnable to show "metadata-from": No such page "_space_variables"IPsec enabled gateway can be deployed at branch offices sites which will negotiate the tunnel in an active mode of operation.
- Responder
AnUnable to show "metadata-from": No such page "_space_variables"IPsec enabled gateway must be deployed at the corporate site premises and waits, in a passive mode, for tunnels to be initiated by the branch office IPsec enabled gateway peer(s).
Tunnel Activation
This setting is applicable for the IPsec enabled gateway configured in an Initiator mode of operation.
- Always
It is used to activate a permanent and/or stand-alone tunnel establishment. This setting should be used mainly for the purposes of confirming that the tunnel is being established with the proper configurations and/or troubleshooting the connection failures in the field. - Link Monitor Action
This is the default recommended setting for the tunnel to be activated and negotiated with the peer in an on-demand mode. The on-demand tunnel activation is performed by the branch survivability 3G4G fail-over feature. Refer to Configuring 3G4G Failover guidelines which covers configuration of the 3G4G fail-over feature on theUnable to show "metadata-from": No such page "_space_variables"under the Working with Branch Survivability section.
Branch1_SBC Tunnel Connection Definition
- Tunnel Name: Branch1_Unable to show "metadata-from": No such page "_space_variables"
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
Branch2_SBC Tunnel Connection Definition
Tunnel Name: Branch2_
Unable to show "metadata-from": No such page "_space_variables"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
HQ_SBC Tunnel Connection Definitions
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
- Tunnel ID 1
- Tunnel Name: HQ_to_Branch1_Unable to show "metadata-from": No such page "_space_variables"
Local Address: Ethernet 2 IP(10.1.2.20)
Remote Address: 10.1.1.10
- Local Subnet Addresses: 172.20.5.3/32,172.20.5.4/32,172.20.5.5/32,172.20.5.6/32
Remote Subnet Addresses: 172.20.1.0/24
- Tunnel ID 2
- Tunnel Name: HQ_to_Branch2_Unable to show "metadata-from": No such page "_space_variables"
- Local Address: hqsbc.uxdev.com
Remote Address: branch2sbc.uxdev.com
- Local Subnet Addresses: 172.20.5.0/24
- Remote Subnet Addresses: 172.20.6.0/24
Firewall and Policy Based Routing
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
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_
2) On the HQ_
Tunnel Setup using Preshared Key Authentication
Specify either the peer address of the remote site (outside interface IP of the peer
Using the Same Secret Key Between All Sites
Branch1_SBC Tunnel Connection Definition
- Authentication Mode: Preshared Key
- New Preshared Secret: Testing123@#
Branch2_SBC Tunnel Connection Definition
- Authentication Mode: Preshared Key
- New Preshared Secret: Testing123@#
HQ_SBC Tunnel Connection Definitions
Tunnel connection definitions on headquarters
Single Tunnel Connection for all Branch Sites
A single tunnel ID can be configured on the headquarters
- Allow Any Remote Address: Enabled
- Remote Subnet Addresses: 172.20.1.0/24,172.20.6.0/24
- Authentication Mode: Preshared Key
- Remote Identifier: 0.0.0.0
- New Preshared Secret: Testing123@#
Multiple Tunnel Connections for each Branch Site
The need to create multiple tunnels on the headquarters
- Tunnel ID 1
Remote Address: 10.1.1.10
- Remote Subnet Addresses: 172.20.1.10/32,172,20.1.20/32
- Authentication Mode: Preshared Key
- New Preshared Secret: Testing123@#
- Tunnel ID 2
Remote Address: 10.1.1.30
- Remote Subnet Addresses: 172.20.6.0/24
- Authentication Mode: Preshared Key
- New Preshared Secret: Testing123@#
Using Different Secret Keys at Each Branch Site
Branch1_SBC Tunnel Connection Definition
- Authentication Mode: Preshared Key
- New Preshared Secret: ABC123
Branch2_SBC Tunnel Connection Definition
- Authentication Mode: Preshared Key
- New Preshared Secret: XYZ456
HQ_SBC Tunnel Connection Definitions
- Tunnel ID 1
Remote Address: 10.1.1.10
- Remote Subnet Addresses: 172.20.1.10/32,172,20.1.20/32
- Authentication Mode: Preshared Key
- New Preshared Secret: ABC123
- Tunnel ID 2
Remote Address: 10.1.1.30
- Remote Subnet Addresses: 172.20.6.0/24
- Authentication Mode: Preshared Key
- New Preshared Secret: XYZ456
Tunnel Setup Using Certificate Key Authentication
As a best practice where security is of concern for multiple branch office
The CA file(s) which signed the
Likewise, the CA file(s) which signed the
The CA file(s) must be imported/exported under the Web UI Security navigation pane * > Certificates > Trusted CA* folder.
Using the Subject Alternative Names (SAN) Identifier
Specify the Certificate Identifier as Subject Alternative Name (IPsec Tunnel Table navigation pane > Remote Attributes panel) on the branch office
The following sections are examples for authenticating a peer gateway using the SAN identifier:
Branch1_SBC Tunnel Connection Definition
Use SAN Identifier: Enabled
- SAN Identifier: branchgw1.uxdev.com
- Authentication Mode: Certificate
- Certificate Identifier: hqgw.uxdev.com
Branch2_SBC Tunnel Connection Definition
- Use SAN Identifier: Enabled
- SAN Identifier: branchgw2.uxdev.com
- Authentication Mode: Certificate
- Certificate Identifier: hqgw.uxdev.com
HQ_SBC Tunnel Connection Definitions
- Tunnel ID 1
Remote Address: 10.1.1.10
- Remote Subnet Addresses: 172.20.1.10/32,172,20.1.20/32
- Use SAN Identifier: Enabled
- SAN Identifier: hqgw.uxdev.com
- Authentication Mode: Certificate
- Certificate Identifier: branchgw1.uxdev.com
- Tunnel ID 2
Remote Address: 10.1.1.30
- Remote Subnet Addresses: 172.20.6.0/24
- Use SAN Identifier: Enabled
- SAN Identifier: hqgw.uxdev.com
- Authentication Mode: Certificate
- Certificate Identifier: branchgw2.uxdev.com
Using the Distinguished Name(DN) Identifier
Specify the Certificate Identifier as Subject Distinguished Name(IPsec Tunnel Table navigation pane -> Remote Attributes panel) on the branch office
Branch1_SBC Tunnel Connection Definition
Use SAN Identifier: Disabled
- Authentication Mode: Certificate
- Certificate Identifier: /C=US/L=IL/OU=Research and Development/CN=testhq.uxdev.com
Branch2_SBC Tunnel Connection Definition
Use SAN Identifier: Disabled
- Authentication Mode: Certificate
- Certificate Identifier: /C=US/L=IL/OU=Research and Development/CN=testhq.uxdev.com
HQ_SBC Tunnel Connection Definitions
- Tunnel ID 1
Remote Address: 10.1.1.10
- Remote Subnet Addresses: 172.20.1.10/32,172,20.1.20/32
- Use SAN Identifier: Disabled
- Authentication Mode: Certificate
- Certificate Identifier: /C=US/L=IL/OU=Research and Development/CN=testbranch1.uxdev.com
- Tunnel ID 2
Remote Address: 10.1.1.30
- Remote Subnet Addresses: 172.20.6.0/24
- Use SAN Identifier: Disabled
- Authentication Mode: Certificate
- Certificate Identifier: /C=US/L=IL/OU=Research and Development/CN=testbranch2.uxdev.com
Using Any Identifier
One significance of configuring 'any' certificate identifier is to simplify the configuration steps at the headquarters
The Trusted Certificate Authority file(s) must be exported from each branch office
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
- Allow Any Remote Address: Enabled
- Remote Subnet Addresses: 172.20.1.0/24,172.20.6.0/24
- Use SAN Identifier: Enabled
- SAN Identifier: hqgw.uxdev.com
- Authentication Mode: Certificate
- Certificate Identifier: any
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
- Allow Any Remote Address: Enabled
- Remote Subnet Addresses: 172.20.1.0/24,172.20.6.0/24
- Use SAN Identifier: Disabled
- Authentication Mode: Certificate
- Certificate Identifier: any
Certificate and Preshared Key Using Any Identifier
Each branch office site can specify various authentication mode (Certificate or PSK) and identifier type(same secret, different secret, SAN or DN).
The headquarters
Branch1_SBC Tunnel Connection Definition
Use SAN Identifier: Disabled
- Authentication Mode: Certificate
- Certificate Identifier: /C=US/L=IL/OU=Research and Development/CN=testhq.uxdev.com
Branch2_SBC Tunnel Connection Definition
- Authentication Mode: Preshared Key
- New Preshared Secret: Testing123@#
HQ_SBC Tunnel Connection Definitions
- Tunnel ID 1
- Allow Any Remote Address: Enabled
- Remote Subnet Addresses: 172.20.1.0/24
- Use SAN Identifier: Disabled
- Authentication Mode: Certificate
- Certificate Identifier: any
- Tunnel ID 2
- Allow Any Remote Address: Enabled
- Remote Subnet Addresses: 172.20.6.0/24
- Authentication Mode: Preshared Key
- Remote Identifier: 0.0.0.0
- New Preshared Secret: Testing123@#
IKE/IPsec SA Cipher Suites
Proposal selection process
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
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
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.
Performance Considerations
Selection of 3DES is supported mainly for the purpose of compatibility with non-
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.
SA Expiry and Security Settings
IKE/IPsec SA Expiry and Protections
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.
Refactoring Significance Using Margin Time
The Margin Time field is supported to avoid collisions when the SA Expiry and Reauthentication are enabled on the
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.
Initiator Mode
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%))
Responder Mode
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%))
Example
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
Other Performance Considerations
- For a business case where some level of security measures and performance are both of concerns, it is recommended to enable the SA Expiry and Security Setting fields on the Unable to show "metadata-from": No such page "_space_variables"gateways are deployed at each of the branch office sites or at the headquarters but not required at both tunnel endpoints.
- It is recommended that the IKE Lifetime and IPsec Lifetime fields be configured with different timeout value to avoid the possibility of collisions although the refactoring using Margin Time should prevent that.
- The rekeying of an SA needs some time, the margin values must not be too low.
- Depending on the level of security that would be required for a business case, both reauthentication and rekeying can be enabled for providing maximum security level. If Reauthentication is enabled, it is recommended to set the IKE Lifetime to a high timeout value when re-authenticating the peer where key hacking is not likely on every hour. The reauthentication unlike the rekeying protection measure not only creates the IKE_SA from scratch but also the IPsec_SAs. During the reauthentication expiry process, performance may be impacted with some packet drops as it is computationally expensive to perform the Diffie-Hellman exchange and signature verifications for reauthentication purposes.