There are two different alternative variants for Phase 1: Aggressive Mode and Main Mode. Aggressive Mode does without a Diffie-Hellman key agreement, which significantly reduces security. Therefore, Aggressive Mode is not implemented in the Intra2net system. Use only Main Mode.

Phase 1 begins with the negotiation of the encryption algorithms to be used, the so-called proposals. The party that initiates the connection establishment (initiator) sends a list of combinations of encryption algorithms it desires, sorted in descending order of preference. The peer (responder) picks the first combination from this list that it also accepts. This combination is then used.

The party responding to the request (responder) only sees the list of desired encryption algorithm combinations. It does not know which connection is to be established at this moment. The required IKE IDs are transmitted later. If a static IP is configured for the peer, this can be used to select the configured encryption algorithms. For all connections with unknown or dynamic IPs, the only option is to define a common set of encryption algorithm combinations.

At the same time, the respective supported extensions of IKEv1 are negotiated. Extensions are things such as NAT traversal. For this purpose, so-called vendor payloads are sent along with the list of proposals. The peer responds to the vendor payloads it knows and ignores all unknown ones.

After agreeing on a set of encryption algorithms, a set of session keys is next negotiated using the Diffie-Hellman method. These session keys protect the rest of the IKE protocol, but not the actual user data.

This is followed by the exchange of IKE IDs and authentication. Each of the two parties must mandatory authenticate itself to its peer.

If authentication by certificate is configured, the appropriate certificates are selected and transmitted to the peer. For the actual authentication, a random number is taken, encrypted with the public key of the peer and sent. Only the holder of the private key can decrypt this and thus correctly answer the authentication request.

In contrast, with authentication by pre-shared key, the entire packet is encrypted with the pre-shared key. The packet also contains the IKE IDs. The peer therefore needs another mechanism to decide which pre-shared key should be used. If the IP addresses of both sides are static, these can be used for this purpose. All connections with dynamic IP addresses, on the other hand, must use the same pre-shared key.

	Caution
	Using the same pre-shared key for multiple connections represents a security risk. This configuration is therefore explicitly discouraged. Instead, use IKEv2 or, for IKEv1, authentication by certificate.

A successful authentication is logged as "IKE SA" or "ISAKMP SA". SA stands for Security Association. This completes Phase 1. Phase 1 requires 6 consecutive messages.

Mode Config is an optional extension of IKEv1. It is used to specify connection parameters for a VPN client. Common parameters include the IP address to be used by the client for the VPN, the IP networks in the VPN tunnel, and a DNS server in the VPN tunnel. The transmission of Mode Config takes place between Phase 1 and 2.

Mode Config is available in two variants: Push and Pull.

With Mode Config Push, the VPN server sends the connection parameters to the client without request. If a transmission error occurs at this moment or the maximum packet size is exceeded, there is no way to repeat the transmission and the connection establishment fails. Therefore, the Push variant is less robust.

With Mode Config Pull, the VPN client requests the connection parameters on its own. In case of an error, it repeats the request. Mode Config Pull is therefore more robust and clearly the preferred mode.

For Phase 2, on the other hand, there is only one variant, the Quick Mode.

A list of desired tunnels is sent together with a combination of desired encryption algorithms (proposals). A tunnel always consists of the combination of source and destination network, each including the network mask. The peer compares these tunnels with its own existing configuration. The configuration of a tunnel must be identical on both sides.

The peer then picks the first combination of the sent encryption algorithms that it accepts. It then either derives session keys for the user data from the session key of Phase 1 or negotiates new ones using the Diffie-Hellman method. The peer's tunnel is then confirmed with this data. This is then usually logged as a successful "IPSec SA".

If the tunnel data does not match, the error identifier INVALID-ID-INFORMATION is sent. If no matching set of encryption algorithms could be found, NO-PROPOSAL-CHOSEN is sent.

The previously negotiated session keys are used to encrypt the actual user data. This data is transmitted via the ESP protocol (Encapsulating Security Payload, IP protocol no. 50). If NAT traversal was activated to bridge a NAT router, the user data is packed into UDP packets on port 4500. This results in a larger protocol overhead than with ESP.

Phase 2 requires 3 consecutive messages. Phase 1 and 2 together therefore require at least 9 consecutive messages.

Both Phase 1 and Phase 2 are renewed regularly. In Phase 1, this is done to renew the session keys and to ensure that both peers are still authorized to establish the connection. In Phase 2, this is done to regularly negotiate new session keys. If the same session keys were used for too long, attacks on the encryption using statistical patterns might otherwise be possible.

The lifetime for Phase 1 is usually significantly longer than that of Phase 2. Typical lifetimes for Phase 1 range from several hours to one day. Usual lifetimes for Phase 2, on the other hand, range from 30 minutes to 3 hours.

Phase 1 and Phase 2 can be renewed independently of each other.

If offline detection, also called Dead-Peer-Detection (DPD), is activated, the connection negotiated in Phase 1 is used to regularly check whether the peer still responds. DPD requests are then sent regularly. If there is no longer any response to these, the connection is recognized as interrupted after some time. Depending on the configuration, an attempt is then made to re-establish it.