4. IPSec NAT traversal

IPSec NAT traversal

  • 1. IPSec NAT traversal
  • 2. Processing of IPSec traversal through NAT
  • 3. IKEv2 and NAT traversal
    • 3.1. NAT-T capability detection
    • 3.2. NAT gateway discovery
    • 3.3. Enabling NAT traversal
    • 3.4. NAT-keepalive
  • 4. IPSec NAT traversal example (NAT devices exist between gateways)
  • 5. IPSec NAT traversal example (the egress gateway is a NAT device, and the tunnel is deployed between the two gateways)

———————————————-

1. IPSec NAT traversal

NAT technology is mainly used to solve the problem of shortage of IPv4 addresses. NAT is widely used in current networks. Especially in enterprise network exit gateways, NAT technology is mostly used to solve the problem of insufficient public network addresses. IPSec provides end-to-end IP communication security and can realize low-cost secure interconnection between different geographical branches of the same enterprise group. However, there are incompatibility issues between IPSec and NAT technologies themselves.

1. In order to complete the address translation, NAT will modify the IP address in the IP packet header.

2. IPsec must ensure data security because it will encrypt and verify data. The AH verification scope includes the IP header, and NAT’s modification of the IP header will cause the AH check to fail. Therefore, the IPSec tunnel protected by cannot pass through the NAT gateway.

3. The part protected by the ESP protocol does not include the IP header (external to the tunnel method). Layer IP header)

There is also an incompatibility problem. When NAT changes the IP address and port of a certain packet, TCP and UDP checksums are usually updated. When TCP or UDP checksums are encrypted using ESP, the checksum cannot be updated. . result in failure.

1. ESP encapsulation transmission mode: TCP and UDP message headers are encrypted using ESP, so the calibration cannot be changed. Checksum, because the IP address or port number has been changed by NAT, the checksum verification of the destination will fail, resulting in the ESP encapsulated transmission mode being unable to coexist with NAT.

2. ESP encapsulation tunnel mode: Encrypt the entire original IP packet and add new ones outside the ESP header. A layer of IP header is added, so if NAT only changes the front IP address, the later protected parts will not be affected. Therefore, IPSec uses ESP tunnel mode to encapsulate data and can coexist with NAT.

———————————————-

2. IPSec traversal of NAT processing

IPSec NAT traversal process:

NAT traversal (NAT-T for short): Both ends of establishing an IPSec tunnel need to negotiate NAT traversal capabilities. This is done in the first two messages of IKE negotiation and is identified by a set of data specified by the Vendor ID payload.

NAT gateway discovery: realized through NAT-D payload, discovering the existence of NAT gateway between IKE peers and determining which side of the peer the NAT device is on. The peer on the NAT side acts as the initiator and regularly sends NAT-Keepalive messages. Enable the NAT gateway to ensure that the secure tunnel is active.

ESP packets normally traverse the NAT gateway: IPSec traverses the NAT. Simply put, it is to A UDP header is added between the header and the ESP header, so that when the ESP packet passes through the NAT gateway, NAT performs address and port translation on the outer IP of the packet and the added UDP header.

After conversion, it reaches the opposite end in the same way as ordinary IPsec, but when sending a response message, a UPD header is also added between the IP header and the ESP header.

———————————————-

3. IKEv2 and NAT traversal

———————————————-

3.1, NAT-T capability detection

NAT-T capability detection is completed in the first two messages of IKE negotiation. A Vendor ID payload identifying the NAT-T capability is inserted into the message to inform the other party of its support for this capability. Ifboth parties include the payload in their respective messages, it means that both parties are interested in NAT-T. Supported. Only when both parties support the NAT-T capability can other negotiations continue.

———————————————-

3.2, NAT gateway discovery

UDP transmission must be used when a NAT device exists, so in the first phase of negotiation in IKEv2, it must first detect whether there is a NAT device, that is, NAT detection. Implementing NAT detection by sending NAT-D payloads is currently a popular method.

To detect whether there is a NAT device in the communication link, add two Notify payloads to both negotiation parties. One includes NAT_DETECTION_SOURCE_IP, which identifies the initiator’s IP address; the other includes NAT_DETECTION_DESTINATION_IP, which identifies the destination’s IP address. These two payloads are mainly used to detect whether there is a NAT device on both communicating parties and determine which party is behind the NAT device.

In IKEv2, the numbers of NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP in the Notify message type are: 16388 and 16389 respectively. The payload uses the common ISAKMP payload header, and the value of the payload is the hash value of SPIs, IP address, and port number for sending the data packet.

SPIs are security index parameters in the HDR payload.
IP is the IP address of the sender or receiver of the data packet.
Port is the port number of the sender or receiver of the data packet.

When the recipient receives the data packet, it will check the SPIs, IP address, and port number in the data packet. Perform a hash operation and compare it with the Notify payload. If it does not match, it means that there is a NAT device in the communication link: if it does not match NAT_DETECTION_SOURCE_IP, it means that the initiator is behind the NAT device; if it does not match NAT_DETECTION_DESTINATION_IP, it means that the receiving end after the NAT device.

———————————————-

3.3, Enabling NAT traversal

After the first phase of negotiation is completed, both parties have determined whether NAT exists and the location of NAT. As for whether to enable NAT traversal, it is determined by fast mode negotiation.

Negotiation of enabling NAT traversal is performed in the SA payload in quick mode. In transport mode, both negotiating parties can send the original address of the IPSec message to the other end, making it possible for the other end to verify and correct TCP/IP after NAT conversion.

———————————————-

3.4, NAT-keepalive

The NAT session on the NAT gateway has a certain survival time. Therefore, if no packets pass through for a long time after the tunnel is established, the NAT session will be deleted, which will make it impossible to transmit data through the tunnel. The solution is to send a NAT-keepalive to the peer before the NAT session times out to keep the NAT session alive.

———————————————-

4. IPSec NAT traversal example (NAT devices exist between gateways)

The headquarters belongs to the 192.168.100.0/24 subnet and is connected to FW2 through interface G1/0/1.
The branch belongs to the 192.168.1.0/24 subnet and is connected to FW1 through interface G1/0/1.
Routes to FW1 and FW2 are reachable.
AR2 is a NAT gateway. Branch users must go through the NAT gateway to access the headquarters.

This is easy to understand. The two organizations are connected through the Internet and apply for fixed IPs. The operator has performed NAT conversion internally, or the two organizations have applied for fixed IPs. The headquarters does not have NAT conversion equipment, but the branches have NAT equipment, and the firewall is behind the NAT equipment.

———————————————-

Configuring interfaces and network interoperability

FW1:

firewall zone trust
add int g1/0/1
firewall zone untrust
add int g1/0/0

security-policy
default action permit

int g1/0/0
ip add 1.1.1.1 30
int g1/0/1
ip add 192.168.1.254 24

ip route-static 0.0.0.0 0.0.0.0 1.1.1.2

FW2:

firewall zone trust
add int g1/0/1
service-manage ping permit
firewall zone untrust
add int g1/0/0
service-manage ping permit

security-policy
default action permit

int g1/0/0
ip add 2.1.1.2 30
service-manage ping permit
int g1/0/1
ip add 192.168.100.254 24
service-manage ping permit

ip route-static 0.0.0.0 0.0.0.0 2.1.1.2

AR2:

int g0/0/0
ip add 1.1.1.2 30
int g0/0/1
ip add 3.1.1.1 30

ip route-static 0.0.0.0 0.0.0.0 3.1.1.2
ip route-static 192.168.1.0 255.255.255.0 1.1.1.1

acl number 3000
 rule 5 permit ip source 192.168.1.0 0.0.0.255
 rule 10 permit ip source 1.1.1.0 0.0.0.3
interface GigabitEthernet0/0/1
 nat outbound 3000

AR1:

interface GigabitEthernet0/0/0
 IP address 3.1.1.2 255.255.255.252
interface GigabitEthernet0/0/1
 IP address 2.1.1.2 255.255.255.252

ip route-static 1.1.1.0 255.255.255.252 3.1.1.1
ip route-static 192.168.100.0 255.255.255.0 2.1.1.1

PC1-PC2 have been converted.


There is also communication between FW1-FW2.

———————————————-

Create an ACL to define the data flow from subnet 192.168.1.0/24 to subnet 192.168.100.0/24

FW1:
acl number 3100
rule permit ip source 192.168.1.0 0.0.0.255 destination 192.168.100.0 0.0.0.255

———————————————-

Create IPSec Security Proposal

FW1:
ipsec proposal Sec
esp au sha2-256
esp en aes-128

FW2:
ipsec proposal Sec
esp au sha2-256
esp en aes-128

———————————————-

Create IKE security proposals and IKE peers

FW1:
ike local-name fw1 **Configure the name type ID during IKE negotiation**

ike proposal 5 **Configure IKE security proposal**
en aes-128
au sha2-256
dh group14

ike peer fw1 **Configure IKE peer**
undo version 2
exchange-mode aggressive
ike-proposal 5
pre-shared-key huawei@123
local-id-type fqdn
remote-address 2.1.1.1
nat traversal

FW2:
ike local-name fw2 **Configure the name type ID during IKE negotiation**

ike proposal 5 **Configure IKE security proposal**
en aes-128
au sha2-256
dh group14

ike peer fw2 **Configure IKE peer**
undo version 2
exchange-mode aggressive
ike-proposal 5
pre-shared-key huawei@123
local-id-type fqdn
nat traversal

———————————————-

Create a security policy

FW1: **IKE dynamic negotiation security policy**
ipsec policy ipvpn 10 isakmp
security acl 3100
ike-peer fw1
proposalSec.

FW2: **Configure IKE dynamic negotiation security policy in policy template mode**
ipsec policy-template temp1 10
ike-peer fw2
proposalSec.

ipsec policy ipvpn 10 isakmp template temp1

———————————————-

Application Interface

FW1:
int g1/0/0
ipsec policy ipvpn

FW2:
int g1/0/0
ipsec policy ipvpn

———————————————-

Check results

PC1 can still ping PC2 and run dis ipsec stat to view packet statistics.


Other users will not be affected by NAT. After the IPSec tunnel is successfully established, PC1 can directly penetrate NAT when accessing PC2.

———————————————-

In aggressive mode in IKEv1, there are only 3 packets.

Negotiating in IKEv1:
Compared with the main mode, the number of exchanged information is reduced and the efficiency is high. However, the biggest problem is that the identity information is not encrypted and protected, which is unsafe. Huawei does not recommend using aggressive mode.

Aggressive mode can meet the needs of specific network environments:
1. When there is a NAT device in the ipsec tunnel, the NAT traversal function needs to be enabled, and NAT conversion will change the IP address of the peer. Since the aggressive mode does not rely on the IP address to identify the identity, when the pre-shared key verification method is used, NAT Travel can only be achieved in brutal mode. The main mode needs to enable the nat-t function to adapt to this environment.
2. If the initiator’s IP address is not fixed or cannot be known in advance, such as pppoe. If both parties want to use the pre-shared key verification method to create ike sa, they can only use aggressive mode. In addition to the brutal mode, for this scenario, you can also use the template method.
3. If the initiator knows the responder’s strategy, or has a comprehensive understanding of the responder’s strategy, aggressive mode can be used to create IKE SA faster.

After changing to main mode, ISAKMP negotiation exchanged 6 packets.

———————————————-

1. When V1 NAT traversal is enabled, the first two messages in the first phase of negotiation will send the Vendor ID payload identifying the NAT Traversal (NAT-T) capability (both in main mode and aggressive mode). Used to check whether the communicating parties support NAT-T. Relevant NAT-T negotiation occurs when both parties include the payload in their messages.

2. In messages 3 and 4 in main mode and messages 2 and 3 in aggressive mode, NAT-D (NAT Discovery) payload is sent to detect whether there is a NAT gateway between two gateways to establish an IPSec tunnel and the location of the NAT gateway. . Perform HASH calculation to see if they are consistent. If consistent, there is no NAT device. If inconsistent, there is a NAT device.

FW1 sender: HASH value

The first NAT-D payload contains the hash value of the IKE peer’s IP address and port. The second NAT-D payload contains the hash value of the local IP address and port. The receiver also calculates these two hash values. Which hash value calculated by the two parties is not equal indicates which device is behind the NAT gateway.

FW2 receiver: HASH value (this screenshot is the return packet viewed on FW1, so the result in the picture below is actually reversed)

So the HASH value of this section of FW1 has changed. So FW1 is behind the NAT gateway.

3. After the NAT gateway is discovered, the port number of subsequent ISAKMP messages (main mode starts from message 5, aggressive mode starts from message 3) is converted to 4500. The ISAKMP message identifies “Non-ESP Marker”.

Currently, UDP encapsulates ISAKMP messages. A non-ESP marker (four bytes with a value of 0) is added here to show the difference from encapsulating ESP messages.

4. During SA negotiation in IKEv1 phase 2, you need to confirm whether to use NAT traversal and the encapsulation mode of NAT traversal: UDP-Encapsulated-tunnel and UDP-Encapsulated-transport. After confirmation, all subsequent transmitted ESP messages will be encapsulated by UDP. When UDP encapsulates ESP messages, there is no non-ESP marker field.

———————————————-

Use IKEv2 negotiation


In the NAT traversal scenario of KEv2, the initiator and responder of IKE negotiation add two N payloads in the IKE_SA_INIT exchange. One message type is NAT_DETECTION_SOURCE_IP, which identifies the initiator’s IP address; the other message type is NAT_DETECTION_DESTINATION_IP, which identifies the responder’s IP address. address.

1. Messages 1 and 2: Insert two N payloads into the IKE message. The first N payload contains the hash value of the local IP address and port, and the second N payload contains the IP address of the IKE peer and the hash value of the port. value, the responder also calculates these two hash values, and which hash value calculated by the two parties is not equal indicates which device is behind the NAT gateway.

2. Messages 3 and 4: After completing IKE_SA_INIT, if a NAT device is discovered, the port number of subsequent UDP messages will be modified to 4500.

Huawei firewall NAT-T is enabled by default in both IKE1 and IKE2.

When viewing the ipsec sa security association on FW2, the template method is used. Because the address of FW1 is not known, the connection cannot be actively initiated. NAT staversal in in and out directions: Y, enable NAT traversal.

Check FW1, ISAKMP mode, as the initiator of IPSEC.

———————————————-

5. IPSec NAT traversal example (the egress gateway is a NAT device, and the tunnel is deployed between the two gateways)

How to establish an IPSec tunnel when the egress gateways of organization A and organization B are both NAT devices.

The two organizations are connected to the Internet through FW1 and FW2 respectively. FW1 and FW2 are fixed public network addresses, and FW1 and FW2 are both NAT devices.

Both PC1 and PC2 can access the internet, and PC1 and PC2 can access securely.


——————————

Complete basic configurations such as interfaces, security policies, and routing.

**FW1:**
firewall zone trust
 add int g1/0/1
firewall zone untrust
 add int g1/0/0

int g1/0/0
 ip add 1.1.1.1 30
 service-manage all permit
int g1/0/1
 ip add 192.168.1.254 24
 service-manage all permit

security-policy
 default action permit

ip route-static 0.0.0.0 0.0.0.0 1.1.1.2

ip address-set to_internet type object **Create address object**
 address 0 192.168.1.0 mask 24
ip address-set to_ipvpn type object
 address 0 192.168.100.0 mask 24


nat-policy **Create Easy nat**
 rule name to_internet
 source-zone trust
 destination-zone untrust
 source-address address-set to_internet
 action source-nat easy-ip
nat-policy
 rule name to_ipvpn
 source-zone trust
 destination-zone untrust
 source-address address-set to_internet
 destination-address address-set to_ipvpn

FW2:
firewall zone trust
add int g1/0/1
firewall zone untrust
add int g1/0/0

int g1/0/0
ip add 2.1.1.1 30
service-manage all permit
int g1/0/1
ip add 192.168.100.254 24
service-manage all permit

security-policy
default action permit

ip route-static 0.0.0.0 0.0.0.0 2.1.1.2

ip address-set to_internet type object **Create address object**
 address 0 192.168.100.0 mask 24
 ip address-set to_ipvpn type object
 address 0 192.168.1.0 mask 24

nat-policy **Create Easy nat**
 rule name to_internet
 source-zone trust
 destination-zone untrust
 source-address address-set to_internet
 action source-nat easy-ip **source address conversion**
 
nat-policy
 rule name to_ipvpn
 source-zone trust
 destination-zone untrust
 source-address address-set to_internet
 destination-address address-set to_ipvpn **For segments going to 192.168.100.0, no conversion**

AR2:
int g0/0/0
ip add 1.1.1.2 30
int g0/0/1
ip add 2.1.1.2 30
ip route-static 192.168.1.0 24 1.1.1.1
ip route-static 192.168.100.0 24 2.1.1.1


—————————-

Configuring IPSec security proposals

FW1:
ipsec proposal Sec
esp au sha2-256
esp en aes-128

FW2:
ipsec proposal Sec
esp au sha2-256
esp en aes-128

—————————-
Configuring IKE peers

FW1:
ike proposal 5
aut pre-share
en aes-128
au sha2-256
dh group14

ike peer fw2
ike-proposal 5
pre-shared-key huawei@123
remote-address 2.1.1.1

FW2:
ike proposal 5
aut pre-share
en aes-128
au sha2-256
dh group14

ike peer fw1
ike-proposal 5
pre-shared-key huawei@123
remote-address 1.1.1.1

—————————-
Define ACL

FW2:
acl number 3000
rule permit ip source 192.168.1.0 0.0.0.255 destination 192.168.100.0 0.0.0.255
FW1:
acl number 3000
rule permit ip source 192.168.100.0 0.0.0.255 destination 192.168.1.0 0.0.0.255

—————————-
Configure security policy

FW1:
ipsec policy ipvpn 10 isakmp
security acl 3000
ike-peer fw2
proposalSec.

FW2:
ipsec policy ipvpn 10 isakmp
security acl 3000
ike-peer fw1
proposalSec.

—————————-
Application Interface

FW1:
int g1/0/0
ipsec po ipvpn

FW2:
int g1/0/0
ipsec po ipvpn

—————————-

Verification

Added a PC at 61.134.1.100.


Go to the Internet and go through NAT conversion.

To go to section 192.168.100.0, take the tunnel.

Huawei official information:

If the interface to which the security policy is applied is also configured with NAT, since the device performs NAT first, IPSec will not work. Effective, there are the following two solutions.

1. The deny destination IP address in the ACL rule referenced by NAT is the destination IP address in the ACL rule referenced by IPSec to avoid NAT conversion of IPSec-protected data flows.
2. The ACL rules referenced by IPSec need to match the IP address after NAT translation.

This experiment is that the priority of NAT rules is higher than the priority of IPSec rules. During NAT conversion, for the destination segment 192.168.100.0, no conversion is performed, and the policy is placed first in the sorting. After entering the nat-policy, configure the non-conversion first, and then configure the conversion.