SA information cannot be checked after IPSec is configured on the AR

21

After IPSec is configured and the display ipsec sa command is used, SA information cannot be checked. To rectify the fault, perform the following operations:
1. Perform the ping operation to check connectivity of the public network.
2. If the IPSec tunnel is established through IKE negotiation, run the display ike sa command to check whether the IKE SA is established successfully.
3. Wait for about 10s and then check the SA.
4. Run the display interface brief command to check whether the interface bound to the IPSec policy is in Up state.
5. Check whether IPSec is configured correctly.

Other related questions:
How do I rectify the failure to view SA information by running the display ipsec sa command after IPSec is configured
To rectify the failure, perform the following operations: 1. Perform the ping operation to check the public network connectivity. 2. If the IPSec tunnel is established through IKE negotiation, run the display ike sa command to check whether the IKE SA is successfully established. 3. Wait about 10 seconds and run the display ipsec sa command again. 4. Run the display interface brief command to verify that the interface bound to the IPSec policy is in the Up state. 5. Verify that IPSec is configured correctly.

Configuring the IPSec SA lifetime on the firewall
Configure the IPSec SA lifetime on the USG. Configure the IPSec VPN SA lifetime. 1. Configure IKE SA hard lifetime. You can configure per-SA IKE lifetime, but cannot configure a global IKE lifetime. system-view //Access the system view. ike proposal proposal-number //Access the IKE proposal view. sa duration seconds //Configure the IKE SA hard lifetime. Notes for configuring IKE SA lifetime: a) If the hard lifetime expires, the IKE SA will be deleted and re-negotiated. The IKE negotiation involves DH calculation and may take a long time. To ensure the secure communications, you are advised to set the lifetime to a value larger than 600 seconds. b) When the soft lifetime expires, a new SA is negotiated to replace the original SA. Before the new SA is negotiated, the original SA is still in use. After the new SA is established, the new SA is used, and the original SA will be automatically deleted when the hard lifetime expires. The default IKE SA hard lifetime is 86,400 seconds (a day). 2. Configure IKE SA soft lifetime. system-view //Access the system view. ike peer peer-name //Access the IKE peer view. sa soft-duration time-based buffer seconds //Configure the IKE SA soft lifetime. The configuration applies only to IKEv1. a) By default, the soft lifetime is 9/10 of the hard lifetime. When the soft lifetime expires, a new SA is negotiated to replace the original SA. b) If the soft lifetime is specified and the hard lifetime is greater than the soft lifetime by more than 10s, the specified soft lifetime applies; otherwise, the default soft lifetime applies. display ike proposal //Display the configured IKE SA hard lifetime. [USG] display ike proposal priority authentication authentication encryption Diffie-Hellman duration method algorithm algorithm group (seconds) --- 10 PRE_SHARED MD5 DES_CBC MODP_768 5000 default PRE_SHARED SHA1 AES_CBC MODP_1024 86400 display ike peer [ brief | name peer-name ] //Display the configured IKE SA soft lifetime. [USG] display ike peer name b -- IKE peer: b Exchange mode: main on phase 1 Pre-shared key: %$%$biLQ*117FHI`Qe&-VY`>l%yp%$%$ Local certificate file name: Proposal: 10 Local ID type: IP Peer IP address: 202.38.169.1 VPN instance: Authentic IP address: IP address pool: Peer name: Peer domain name: VPN instance bound to the SA: NAT traversal: enable SA soft timeout buffer time: 22 seconds OCSP check: disable OCSP server URL: Applied to 1 policy: ppp1-1-isakmp

Configuring SA on the firewall
Configuring an SA on the USG Creating a dynamic IPSec SA 1. The data between network A and network B is encrypted and securely transmitted through the IPSec tunnel between USG_A and USG_B. USG_A protects network 10.1.1.0/24, and its public address is 202.38.163.1/24. USG_B protects network 10.1.2.0/24, and its public address is 202.38.169.1/24. Network A---USG_A----INTERNET----USG_B---Network B 2. The configuration steps are as follows: [USG_A] acl 3000 //Configure an ACL to match sensitive traffic packets. [USG_A-acl-adv-3000] rule permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255 [USG_A-acl-adv-3000] quit [USG_A] ip route-static 10.1.2.0 255.255.255.0 202.38.163.2 //Configure a route. [USG_A] ipsec proposal tran1 //Configure an IPSec proposal. [USG_A-ipsec-proposal-tran1] encapsulation-mode tunnel [USG_A-ipsec-proposal-tran1] transform esp [USG_A-ipsec-proposal-tran1] esp authentication-algorithm sha1 [USG_A-ipsec-proposal-tran1] esp encryption-algorithm aes [USG_A-ipsec-proposal-tran1] quit [USG_A] ike proposal 10 //Configure an IKE proposal. [USG_A-ike-proposal-10] authentication-method pre-share [USG_A-ike-proposal-10] authentication-algorithm sha1 [USG_A-ike-proposal-10] integrity-algorithm hmac-sha1-96 [USG_A-ike-proposal-10] quit [USG_A] ike peer b //Configure an IKE peer. [USG_A-ike-peer-b] ike-proposal 10 [USG_A-ike-peer-b] remote-address 202.38.169.1 [USG_A-ike-peer-b] pre-shared-key abcde [USG_A-ike-peer-b] quit [USG_A] ipsec policy map1 10 isakmp //Configure an IPSec policy. [USG_A-ipsec-policy-isakmp-map1-10] security acl 3000 [USG_A-ipsec-policy-isakmp-map1-10] proposal tran1 [USG_A-ipsec-policy-isakmp-map1-10] ike-peer b [USG_A-ipsec-policy-manual-map1-10] quit [USG_A] interface GigabitEthernet 0/0/2 [USG_A-GigabitEthernet0/0/2] ipsec policy map1 //Apply the IPSec policy to the interface. [USG_B] acl 3000 //Configure an ACL to match sensitive traffic packets. [USG_B-acl-adv-3000] rule permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255 [USG_B-acl-adv-3000] quit [USG_B] ip route-static 10.1.1.0 255.255.255.0 202.38.169.2 //Configure a route. [USG_B] ipsec proposal tran1 //Configure an IPSec proposal. [USG_B-ipsec-proposal-tran1] encapsulation-mode tunnel [USG_B-ipsec-proposal-tran1] transform esp [USG_B-ipsec-proposal-tran1] esp authentication-algorithm sha1 [USG_B-ipsec-proposal-tran1] esp encryption-algorithm aes [USG_B-ipsec-proposal-tran1] quit [USG_B] ike proposal 10 //Configure an IKE proposal. [USG_B-ike-proposal-10] authentication-method pre-share [USG_B-ike-proposal-10] authentication-algorithm sha1 [USG_B-ike-proposal-10] integrity-algorithm hmac-sha1-96 [USG_B-ike-proposal-10] quit [USG_B] ike peer a //Configure an IKE peer. [USG_B-ike-peer-a] ike-proposal 10 [USG_B-ike-peer-a] remote-address 202.38.163.1 [USG_B-ike-peer-a] pre-shared-key abcde [USG_B-ike-peer-a] quit [USG_B] ipsec policy map1 10 isakmp //Configure an IPSec policy. [USG_B-ipsec-policy-isakmp-map1-10] security acl 3000 [USG_B-ipsec-policy-isakmp-map1-10] proposal tran1 [USG_B-ipsec-policy-isakmp-map1-10] ike-peer a [USG_B-ipsec-policy-isakmp-map1-10] quit [USG_B] interface GigabitEthernet 0/0/2 [USG_B-GigabitEthernet0/0/2] ipsec policy map1 //Apply the IPSec policy to the interface.

Reason why devices on two private networks cannot communicate after IPSec is configured on the AR
Devices on two private networks fail to communicate with each other after IPSec is configured. The possible causes are as follows: -The public addresses of two IPSec-enabled devices cannot be pinged. -There is an error in the data flow to be encapsulated with the IPSec header or both IPSec and NAT are performed for the same data flow. You can run the display acl all command to check ACL matching. If both IPSec and NAT are performed for the same data flow, use either of the following method to prevent data flow overlapping: -Ensure that the destination IP address denied in the ACL rule referenced by NAT is the destination IP address in the ACL rule referenced by IPSec. By doing so, the device does not perform NAT on the data flow protected by IPSec. -The ACL rule referenced by IPSec matches the NAT-translated IP address. -The AR incorrectly learns private routes. The outbound interface of the route to the destination private network is not the public network interface with enabled IPSec.

USG firewall security association
USG firewall security association What is security association (SA)? The IPSec SA is a unidirectional logical connection created for security purposes. The SA is bidirectional and requires an IPSec SA in each direction. The number of SAs depends on the security protocol. If either the AH or ESP is used to protect traffic between peers, two SAs, one in each direction, exist between the peers. If both the AH and the ESP are used, four SAs, two in each direction corresponding to the AH and the ESP, exist between the peers. Therefore, an IPSec SA is not equivalent to a connection. The IPSec SA is uniquely identified by a triplet. The triplet includes the following elements: Security Parameter Index (SPI) The SPI is a 32-bit value that is generated to uniquely identify an SA. The SPI is carried in the AH and ESP headers. The SPI, destination IP address, and security protocol number uniquely identify an IPSec SA. Destination IP address Security protocol number (AH or ESP) Creation mode The IPSec SA is classified into two types: SA that is manually created and SA that is created by means of IKE automatic negotiation (isakmp). Major differences between two types of SAs are as follows: Different key generation modes In manual mode, all parameters required by the IPSec SA, including encryption and verification keys, are manually configured or manually updated. In IKE mode, encryption and verification keys required by the IPSec SA are generated by the DH algorithm and can be dynamically updated. The key management cost is low and the security is high. Different IPSec SA lifetime In manual mode, once an IPSec SA is created, it permanently exists. In IKE mode, the IPSec SA establishment is triggered by the data flow, and the SA lifetime is controlled by lifetime parameters configured on both ends.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top