Juniper SRX IPsec VPN is a security framework used to secure remote connections.
It uses cryptography algorithms to secure traffic to ensure it cannot be eavesdropped or manipulated with by unauthorized users.
In this section we discuss the theoretical concept of IPsec VPN. We will see the configuration examples in the next sections.
Juniper SRX IPsec VPN Fundamentals
When two or multiple parties decide to secure their remote connection, parties must first negotiate about the security algorithms and keys that they will use to secure the communication.
This is the first step of secure communication and it is done through a dynamic protocol name IKE or internet key exchange.
Then they can use the agreed algorithms and keys to secure their connection.
This is the second step of secure communication and this is done through IPsec protocols.
IPsec itself is just a framework and there are two protocols that belong to the IPsec framework. AH and ESP.
With AH, the confidentiality of data is not important to you and only the integrity of data is important. In other words, you just want to make sure the receiver is receiving exactly what the sender has sent and nothing has been changed on the path.
You choose ESP when both confidentiality and integrity, are important to you. In addition to integrity it is important to you that data is not readable by unauthorized users. If it is then we choose ESP to secure the connection.
Understanding IKE Fundamentals
As I have explained, IKE is the first step of IPsec secure communication.
The goal is to negotiate security algorithms and key used to secure data itself.
IKE protocol runs over UDP port 500.
IKE protocol has two phases. In the first phase, IKE negotiates security algorithms and key to secure IKE of second phase. This phase is called IKE SA (IKE Security Association).
In the second phase of IKE, which is secured by algorithms and key negotiated in the first phase, IPsec protocol, AH or ESP, cryptography algorithms used in IPsec and also the key to encrypt data itself is negotiated. This phase is called IPsec SA (IPsec Security Association).
Security Association or SA is an important word in IPsec protocol. And it means that two ends of the connection agree on the algorithms and key to secure the communication.
Understanding IKE Phase 1 Main Mode
IKE first phase has two different modes.
IKE Main mode is used mostly in site to site VPN communication, in which both sites have static IP address.
IKE Aggressive mode is used mostly in remote access VPN communication, in which the remote users have dynamic IP addresses.
In IKE Main mode, 6 packets are negotiated between two ends of the connection.
The first two packets are intended to negotiate cryptography algorithms used to secure the second phase of IKE.
The next two packets are designed to negotiate the key that is used to encrypt communication in the second IKE phase.
The key is negotiated using the asymmetric Diffie-Hellman algorithm. The key is then used to encrypt the second phase using symmetric encryption algorithms.
IPsec endpoints use the last two packets to authenticate each other. Authentication is done based on “authentication key” which is manually configured in both sides. It is also called PSK or pre shared key.
Although the first 4 packets are negotiated in the clear text, but the Diffie-Hellman algorithm itself is safe and nothing to worry about.
The last two packets are authenticated and encrypted.
Understanding IKE Phase 1 Aggressive Mode
In IKE Aggressive mode, only 3 packets instead of 6 packets are negotiated.
Aggressive mode is faster but less secure because it reveals the unencrypted authentication hash of PSK (pre shared authentication key).
Understanding IKE Phase 2
When Phase 1 negotiation is completed, we now have a secure channel in which all traffic are secured based on algorithms and key negotiated in phase 1.
In the second phase of IKE negotiation, IPsec protocol, AH or ESP, cryptography algorithms used in AH or ESP and also the key to encrypt data is negotiated. This phase is called IPsec SA (IPsec Security Association).
The second phase of IKE is also called IKE quick mode.
The second phase includes only 3 packets.
In the first two packets, the following information are negotiated.
- Which IPsec protocol to use? AH or ESP? And with which parameters?
- Tunnel Mode or Transport mode. In this course, we will use always tunnel mode. we will not talk about transport mode.
- Which traffic must be secured? In other words, Proxy ID.
- SPI or security Parameter Index. I will talk more about it in a few minutes.
- Negotiate a new optional key through DH for data encryption. It is optional and the same key negotiated in IKE phase 1 can be used for data encryption.
The third packet is only to acknowledge the second packet.
what is SPI in IKE Phase 2?
SPI (Security Parameter Index) is one of the parameters that are negotiated in IKE phase 2. The question is, for what do we use SPI parameter in IPsec communication?
To answer that question, I’ll ask another question.
If we receive a secure and encrypted IPsec packet, how can we understand which cryptographic algorithm and key must be used to decrypt and authenticate the packet?
For each IKE Phase 2 negotiation, a record is created in a table with SPI as the index, which is a random number. And all negotiated protocols, algorithms and key are added to the record.
When an encrypted packet is received, in addition to the packet’s source IP address, there is SPI parameter in IPsec encapsulated packet in the plaintext.
According to the SPI, we find the entry in the table in which the IPsec protocol, cryptographic algorithms and key are stored. Then we will decrypt and authenticate the packet based on these information.
Understanding IPsec Encapsulation
To secure IP packets, we have to deliver IP packet to IPsec protocol stack to re-encapsulate them for security purposes.
Depending on the configured IPsec protocol, one of two protocols, AH or ESP will be used.
With AH, only authentication information, HMAC or digital signature, will be added to the header of the packet. So receiver with inspection authentication header can make sure of the integrity and also sender of the packet. With AH, payload is not encrypted.
In the previous section, we learned how authentication information is added to the packet and how it is processed and verified on the receiver side.
With ESP, authentication information, HMAC or digital signature, will be added to the ESP trailer and not header. With ESP the content of the packet will also be encrypted.
SPI in both AH and ESP are inserted in the header of AH/ESP. we have already discussed about the importance of SPI parameter.
You can also see that there two IP headers in IPsec encapsulation.
Inner IP header is the IP address of real source and destination IP address. As an example, servers inside the main office and branch office are the real source and destination IP address.
Outer IP header is the IP address of IPsec tunnel endpoints. In our example, Juniper SRX in main office and branch office with IPsec tunnel implementation are the source and destination IP address of outer IP header.
The other point in this figure is that with AH, the entire packet except the Layer 2 header, which is not displayed in the figure, is inside the authentication/hashing process.
But with ESP, the outer IP header is not completely inside the process of authentication/hashing process. With ESP, it also shows that all payload information including ESP trailer and inner IP header are encrypted.
The last point in ESP is that in the source, the packet is first encrypted and then authentication information is added. How did I understand it? Because authentication information is not encrypted.
The reason is that when the packet is received, authentication information is processed first, if the authentication is verified, then the packet is decrypted, which requires high process and memory utilization.
Of course, if authentication is not confirmed, the packet will not be decrypted and it will be discarded.