Cloud Connect (IPSec and Transit Gateway) FAQ and Guides

1. Integration guides
2. Technical documentation

3. Why are my IPSec tunnels down though the configuration was correct and was not changed?

4. The traffic sent from my Connected Devices does not arrive to my server

5. I am getting an error message: "CIDR not valid. X.X.X.X is not available"

6. I want to update my CloudConnect. How should I proceed?

7. Can I setup a Transit Gateway / IPSec for a specific subset of IP?

8. What are the differences between OpenVPN and IPSec

9. How IPSec works
10. Supported algorithms
11. Requirements: Internet Key Exchange (IKE)

 

Integration Guides

Please check our Developer Hub for the following integration guides:

• CloudConnect integration into AWS using Transit Gateway
• Setup an IPSec using CloudConnect
• Integration into Azure Virtual Network Gateway

 

Technical documentation

Please visit the following AWS articles (Article 1, Article 2) for additional information and technical documentation regarding Virtual Private Networks

 

 

Why are my IPSec tunnels down though the configuration was correct and was not changed?

No traffic

If no traffic is sent through the IPSec , the tunnels may go down. They will go up as soon as traffic coming from the customer's application server comes through. AWS documentation states: "The VPN tunnel comes up when traffic is generated from your side of the VPN connection. The AWS endpoint is not the initiator; your customer gateway device must initiate the tunnels. "

To keep the tunnel up we advise the customer side to actively try to re-establish the IPsec tunnel (e.g. by means of cron job or by setting up a ping from the application server to an EMnify endpoint). This is because the IPsec SA is eventually removed completely if it fails all the attempts to be re-established (e.g. as result to AWS network outage.

Idle timeouts

If you're experiencing idle timeouts due to low traffic on a VPN tunnel:

• Be sure that there's constant bidirectional traffic between your application server and our CloudConnect. If necessary, create a host that sends ICMP requests to an instance in your VPC every 5 seconds.
• Review your VPN device's idle timeout settings using information from your device's vendor. When there's no traffic through a VPN tunnel for the duration of your vendor-specific VPN idle time, the IPsec session terminates. Be sure to follow vendor-specific configuration guidelines.

Network failure

To re-establish a VPN tunnel in case of a network outage (that would typically exceed the DPD timeout interval) we recommend customers to provide an additional mechanism, based on a cron job or by setting up a ping from the application server to an EMnify endpoint. This is because the IPsec SA is eventually removed completely if all the attempts to be re-established fail.e. AWS does not initiate IPsec connections. It only operates in passive mode.

 

 

The traffic sent from my Connected Devices does not arrive to my server

• Check where your endpoints are sending the traffic to. If you are using a hostname to address your application servers make sure it resolves to a private IP reachable through CloudConnect.
• Make sure you are allow traffic coming from your endpoint IP addresses:
  • If you can, allow traffic from the following ranges
    • 10.192.0.0/12
    • 100.64.0.0/10
    • 10.112.0.0/12
    • 10.176.0.0/12
      You will then be sure that traffic from your endpoints will be allowed
      
  • If you have overlapping rules, you can allow only the IP ranges assigned to your account. In this case, you need to update your configuration each time a new IP range is assigned to your account.

 

 

I am getting an error message: "CIDR not valid. X.X.X.X is not available"

You can add up to 3 CIDR in your VPC. If the CIDR is already taken on our side, a warning will be displayed when you try to validate the TGW because AWS TGW does not support overlapping IP addresses. Please use a different CIDR.

 

 

I want to update my CloudConnect. How should I proceed?

There is no way to update the configuration of your CloudConnect yet. To do so, delete the attachment and create it again from scratch.

For Transit Gateways, make sure you delete it from the EMnify User Interface. If the attachment is deleted from AWS first, we won't be notified and the configured CIDR will not be available again automatically.

Note: when the old breakout is deleted and then the new is created, no additional fee will be charged. When you delete the attachment from AWS side only, it will still be charged on the EMnify side.

 

Can I setup a Transit Gateway / IPSec for a specific subset of IPs?

EMnify's Cloud Connect will enable you to access all your devices. However, you can create rules on your side to enable the access to specific IP addresses only.

 

What are the differences between OpenVPN and IPSec

EMnify offers different types of VPN:

- The OpenVPN should be used to remotely access devices using EMnify SIM cards from any computer. Please check our OpenVPN FAQ

- IPSec can be used to create a direct connection between an application server and devices connected to the Internet using EMnify SIM cards. With an IPSec, all traffic to and from the devices to and from the application server will go through the tunnel, be encrypted and secured without using the public Internet. It enables the devices to directly access the application within the same network. With the Cloud-Connect feature, EMnify offers quick IPSec configuration. For AWS users, they can use the Transit Gateway feature and keep all traffic within AWS:

 

How IPSec works

IPSec involves many component technologies and encryption methods. Yet IPSec's operation can be broken down into five main steps:

1. "Interesting traffic" initiates the IPSec process. Traffic is deemed interesting when the IPSec security policy configured in the IPSec peers starts the IKE process.

2. IKE phase 1. IKE authenticates IPSec peers and negotiates IKE SAs during this phase, setting up a secure channel for negotiating IPSec SAs in phase 2.

3. IKE phase 2. IKE negotiates IPSec SA parameters and sets up matching IPSec SAs in the peers.

4. Data transfer. Data is transferred between IPSec peers based on the IPSec parameters and keys stored in the SA database.

5. IPSec tunnel termination. IPSec SAs terminate through deletion or by timing out.

    

   1. Defining Interesting Traffic

   What type of traffic is deemed interesting is determined as part of formulating a security policy for use of a VPN. The policy is then implemented in the configuration interface for each particular IPSec peer. When interesting traffic is generated or transits the IPSec client, the client initiates the next step in the process, negotiating an IKE phase 1 exchange.

   2. IKE Phase 1

   The basic purpose of IKE phase 1 is to authenticate the IPSec peers and to set up a secure channel between the peers to enable IKE exchanges. IKE phase 1 performs the following functions:

   • Authenticates and protects the identities of the IPSec peers

   • Negotiates a matching IKE SA policy between peers to protect the IKE exchange

   • Performs an authenticated Diffie-Hellman exchange with the end result of having matching shared secret keys

   • Sets up a secure tunnel to negotiate IKE phase 2 parameters

   IKE phase 1 occurs in two modes: main mode and aggressive mode. 

   Main Mode

   Main mode has three two-way exchanges between the initiator and the receiver.

   • First exchange: The algorithms and hashes used to secure the IKE communications are agreed upon in matching IKE SAs in each peer.

   • Second exchange: Uses a Diffie-Hellman exchange to generate shared secret keying material used to generate shared secret keys and to pass nonces—random numbers sent to the other party and then signed and returned to prove their identity.

   • Third exchange: Verifies the other side's identity. The identity value is the IPSec peer's IP address in encrypted form. The main outcome of main mode is matching IKE SAs between peers to provide a protected pipe for subsequent protected ISAKMP exchanges between the IKE peers. The IKE SA specifies values for the IKE exchange: the authentication method used, the encryption and hash algorithms, the Diffie-Hellman group used, the lifetime of the IKE SA in seconds or kilobytes, and the shared secret key values for the encryption algorithms. The IKE SA in each peer is bi-directional.

   Aggressive Mode

   In aggressive mode, fewer exchanges are made, and with fewer packets. On the first exchange, almost everything is squeezed into the proposed IKE SA values: the Diffie-Hellman public key; a nonce that the other party signs; and an identity packet, which can be used to verify identity via a third party. The receiver sends everything back that is needed to complete the exchange. The only thing left is for the initiator to confirm the exchange. The weakness of using the aggressive mode is that both sides have exchanged information before there's a secure channel. Therefore, it's possible to "sniff" the wire and discover who formed the new SA. However, it is faster than main mode.

   3. IKE Phase 2

   The purpose of IKE phase 2 is to negotiate IPSec SAs to set up the IPSec tunnel. IKE phase 2 performs the following functions:

   • Negotiates IPSec SA parameters protected by an existing IKE SA

   • Establishes IPSec security associations

   • Periodically renegotiates IPSec SAs to ensure security

   • Optionally performs an additional Diffie-Hellman exchange

   IKE phase 2 has one mode, called quick mode. Quick mode occurs after IKE has established the secure tunnel in phase 1. It negotiates a shared IPSec policy, derives shared secret keying material used for the IPSec security algorithms, and establishes IPSec SAs. Quick mode exchanges nonces that provide replay protection. The nonces are used to generate new shared secret key material and prevent replay attacks from generating bogus SAs.

   Quick mode is also used to renegotiate a new IPSec SA when the IPSec SA lifetime expires. Base quick mode is used to refresh the keying material used to create the shared secret key based on the keying material derived from the Diffie-Hellman exchange in phase 1.

   Perfect Forward Secrecy

   If perfect forward secrecy (PFS) is specified in the IPSec policy, a new Diffie-Hellman exchange is performed with each quick mode, providing keying material that has greater entropy (key material life) and thereby greater resistance to cryptographic attacks. Each Diffie-Hellman exchange requires large exponentiations, thereby increasing CPU use and exacting a performance cost.

   4. IPSec Encrypted Tunnel

   After IKE phase 2 is complete and quick mode has established IPSec SAs, information is exchanged via an IPSec tunnel. Packets are encrypted and decrypted using the encryption specified in the IPSec SA.

   5. Tunnel Termination

   IPSec SAs terminate through deletion or by timing out. An SA can time out when a specified number of seconds have elapsed or when a specified number of bytes have passed through the tunnel. When the SAs terminate, the keys are also discarded. When subsequent IPSec SAs are needed for a flow, IKE performs a new phase 2 and, if necessary, a new phase 1 negotiation. A successful negotiation results in new SAs and new keys. New SAs can be established before the existing SAs expire, so that a given flow can continue uninterrupted.

 

 

Supported algorithms

Here is the list of AWS supported algorithms which are available:

 

 

 

Requirements: Internet Key Exchange (IKE)

EMnify's Cloud Connect feature is based on AWS technology. There are specific requirements for customer gateway devices. One of them is IKE.

Internet Key Exchange (IKE):

IKE is a key management protocol standard used in conjunction with the Internet Protocol Security (IPSec) standard protocol. It provides security for virtual private networks' (VPNs) negotiations and network access to random hosts. It can also be described as a method for exchanging keys for encryption and authentication over an unsecured medium, such as the Internet.

IKE is a hybrid protocol based on: 

• ISAKMP (RFC2408): Internet Security Association and Key Management Protocols are used for negotiation and establishment of security associations. This protocol establishes a secure connection between two IPSec peers.
• Oakley (RFC2412): This protocol is used for key agreement or key exchange. Oakley defines the mechanism that is used for key exchange over an IKE session. The default algorithm for key exchange used by this protocol is the Diffie-Hellman algorithm.
• SKEME: This protocol is another version for key exchange.

IKE enhances IPsec by providing additional features along with flexibility. IPsec, however, can be configured without IKE.

IKE has many benefits:

• It eliminates the need to manually specify all the IPSec security parameters at both peers.
• It allows the user to specify a particular lifetime for the IPsec security association.
• It permits certification authority.
• It allows dynamic authentication of peers.
• Encryption can be changed during IPsec sessions.

The IKE works in two steps:

1. Establishes an authenticated communication channel between the peers, by using algorithms like the Diffie-Hellman key exchange, which generates a shared key to further encrypt IKE communications. The communication channel formed as a result of the algorithm is a bi-directional channel. The authentication of the channel is achieved by using a shared key, signatures, or public key encryption. 

There are two modes of operation for the first step:

• Main mode: which is utilized to protect the identity of the peers
• Aggressive mode: which is used when the security of the identity of the peers is not an important issue.

2. The peers use the secure communication channel to set up security negotiations on behalf of other services like IPSec. These negotiation procedures give rise to two unidirectional channels of which one is inbound and the other outbound. The mode of operation for the second step is the Quick mode.

IKE provides three different methods for peer authentication:

• Authentication using a pre-shared secret
• Authentication using RSA encrypted nonces
• Authentication using RSA signatures.

IKE uses the HMAC functions to guarantee the integrity of an IKE session. When an IKE session lifetime expires, a new Diffie-Hellman exchange is performed and the IKE SA is re-established.