推荐点击下面图片，通过本站淘宝优惠价购买:
https://support.huawei.com/enterprise/de/doc/EDOC1000179232/a5653c64
Case Study: Troubleshooting IPSec SA Negotiation Failure
Symptom
In Figure 16-27, after IPSec is deployed between FWs, PCs cannot communicate with each other.
Run the display ike sa command on FW1 to check the IKE SA status. The command output shows that the negotiation status in phase 1 is RD and that in phase 2 is NEG or null. After the display ipsec sa command is run, no IPSec SA status information is displayed. This indicates that the IPSec SA is not established. As a result, the IPSec tunnel fails to be established.
<FW1> display ike saIKE SA information : Conn-ID Peer VPN Flag(s) Phase ---------------------------------------------------------------------- 8388 2.1.1.1:500 RD|ST|A v2:1 Number of IKE SA : 1 ---------------------------------------------------------------------- Flag Description: RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
Relevant Alarms and Logs
None.
Cause Analysis
Procedure
Run the display ike error-info command to check the IPSec SA negotiation failure reason for fast fault location or perform the following steps to locate the fault.
Run the display ike error-info command to check the cause of the IPSec SA negotiation failure to quickly locate the fault.
If no error information is displayed, go to the next step. If the error-info field records the negotiation failure cause, analyze the cause. Common negotiation failure causes are as follows:
phase2 proposal or pfs mismatch
Generally, the IPSec proposal parameters and PFS algorithms on both ends do not match. This error may be caused by a parameter verification error on the local end or by a notification sent by the peer end to the local end after a parameter verification error occurs on the peer end. The method of identifying the error is as follows:
Run the display ike error-info verbose command. If receive is displayed in detail, the peer end fails to match parameters. Otherwise, the local end fails to verify related parameters. Check IPSec proposal parameters and PFS algorithm configurations on both ends. In addition, if this error message is displayed during the interconnection with a third-party device and the error is caused by a verification error on the peer end, the possible cause is that the peer end fails to match the ACL. Therefore, you need to check whether the ACL configurations on both ends are correct.
encapsulation mode mismatch
The encapsulation-mode parameters in IPSec proposal parameters on both ends do not match. Check IPSec proposal parameters on both ends.
flow or peer mismatch
Indicates that the security ACLs of the two ends do not match or an incorrect IKE peer is matched (that is, the addresses in the IKE peer do not match). Run the display ike error-info verbose command to check whether the configurations of interested flows on both ends are correct.
route limit
Indicates that after the dynamic route injection function is configured on the device, the tunnel fails to be established because the number of injected routes reaches the upper limit. Run the display ip routing-table protocol unr command to check the number of UNRs in the routing table, and run the display ipsec route-info command in the diagnostic view to check whether the number of UNRs reaches the upper limit. If so, replace the device with a device with higher specifications.
license or specification limited
The total number of IPSec tunnels has reached the license or device specifications, and new IPSec tunnels fail to be established. Run the display ipsec statistics tunnel-number command to check the number of established tunnels and device specifications. If so, replace the device with a device with higher specifications.
netmask mismatch
After the IPSec mask filtering function is enabled, the ACL masks do not match. As a result, the tunnel fails to be established. Check whether the ACL configurations on both ends are correct.
flow confict
Indicates that when the duplicate flow access function is not enabled on the device, the ACL negotiated for the new tunnel is the same as the ACL of the tunnel that has been established on the peer end. As a result, the ACL conflict occurs and the tunnel fails to be established. Check whether the ACL configurations of peer ends are the same. If yes, refine the ACL configurations based on the actual network plan to ensure that different peer ends use different ACLs.
proposal mismatch or use sm in ikev2
Indicates that the IPSec proposal does not match or IKEv2 uses the SM algorithm. This error is recorded when the local end receives a NO_PROPOSAL_CHOZEN message from the peer end during IKEv2 negotiation. Check configurations, such as the IPSec proposal and PFS algorithm, on both ends. If this error occurs during interconnection with a third-party device, check whether the ACL configurations on both ends are correct.
ikev2 not support sm in ipsec proposal ikev2
When IKEv2 is used for negotiation, IKEv2 does not support the SM algorithm, but the SM algorithm is configured in the IPSec proposal. Check whether the SM algorithm is configured in the IPSec proposal. If the SM algorithm is configured, change the IKE negotiation version or the IPSec proposal algorithm.
Check whether ACL configurations on both ends match.
Run the display ipsec policy command to check the ACL number referenced by IPSec and then run the display acl acl-number command to check whether ACL rules on both ends match.
<sysname> display ipsec policy =========================================== IPSec policy group: "10" Using interface: GigabitEthernet0/0/2 =========================================== Sequence number: 10 Policy Alias: map1-10 Security data flow: 3100/IPv4 //Security ACL Peer name : rut2 Perfect forward secrecy: DH group 14 Proposal name: prop1 IPSec SA local duration(time based): 3600 seconds IPSec SA local duration(traffic based): 1843200 kilobytes SA trigger mode: Traffic-based ...... <sysname> display acl 3100 Advanced ACL 3100, 1 rule ( Reference counter 1 ) Acl's step is 5 rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255 (0 times matched)
When configuring ACL rules, pay attention to the following points:
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 IPSec-protected data flows.
The ACL rule referenced by IPSec matches the post-NAT IP address.
If the firewall assigns an IP address to the connected small-cell base station, the first ACL configured on the firewall must contain an address pool. Otherwise, the negotiation fails because the assigned IP address does not match the first ACL.
For IKEv1, mirroring is not necessary. SAs can be set up successfully as long as the address range defined in the ACL rule of the initiator is included in that of the responder. Both ends use the overlapping ACL rule range as the negotiation result. In addition, the ACL cannot be configured in address-set mode, and the port range cannot be configured. If a port number range is configured, the tunnel uses the start port number for negotiation. When the start port number is 0, the port number ranges from 0 to 65535. If the ACL configurations on both ends are inconsistent, when the tunnel is interrupted, the end with a larger ACL range triggers negotiation. As a result, the negotiation fails and services cannot be restored. Therefore, you are advised to configure ACL configurations on both ends to be consistent.
For IKEv2, in the automatic triggering scenario, mirroring is not a necessary condition as long as ACL rules on both ends overlap. The two ends use overlapping address ranges as the negotiation result. In the service flow triggering scenario, if the service flow that triggers negotiation does not belong to the ACL intersection of the two ends, the negotiation fails. Therefore, you are advised to configure ACL configurations on both ends to be consistent.
The protocol type defined in the ACL rules on both ends must be consistent. For example, if one device uses the IP protocol, the other device must use the IP protocol too.
If point-to-point IPSec policies are configured on both ends of an IPSec tunnel, it is recommended that ACL configurations on both ends of the IPSec tunnel be consistent.
If the IPSec policy on one end is a P2MP IPSec policy, a large ACL can be configured for the P2MP IPSec policy. However, you are advised to configure the ACL based on the actual network plan. The permit ip all command is not recommended because it indicates that all traffic enters the IPSec tunnel, which interrupts the service traffic that does not require IPSec encryption, you do not need to configure an ACL for a point-to-multipoint IPSec policy. The effect is the same as that of the permit ip all command.
If ACL rules on both ends mirror each other, a SA can be successfully established after any party initiates negotiation. If ACL rules on both ends do not mirror each other, a SA can be successfully established only when the address range defined in the ACL rule of the initiator is included in that of the responder or there is an overlapping address range between the two ACL rules. It is recommended that ACL rules on both ends mirror each other. That is, the source and destination IP addresses in the ACL rule of one device are the destination and source IP addresses in the ACL rule of the other device, respectively. That is:
The IP address ranges in the ACL rules should not overlap each other. Otherwise, an error will occur when the devices match ACL rules for data flows.
The rules for the ACL in the same IPSec policy group must be unique.
The ACL rules referenced by all the IPSec policies in the same IPSec policy group cannot overlap. For example, the referenced ACL3001 and ACL3002 overlap:
acl number 3001 rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255 acl number 3002 rule 5 permit ip source 10.1.0.0 0.0.255.255 destination 10.1.0.0 0.0.255.255
When the responder uses IPSec policies configured using an IPSec policy template, pay attention to the following points:
Data flows to be protected can be not defined for the responder, which indicates that the responder accepts the data flow protection range defined on the initiator. If you want to define data flows to be protected for the responder, the configuration must mirror or include that of the initiator.
If NAT is configured on the interface to which an IPSec policy is applied, IPSec does not take effect because the device executes the NAT configuration first. In this case, you need to ensure:
Check whether the IPSec proposal configurations on both ends are consistent.
Run the display ipsec proposal command to check whether the security protocols, encryption algorithms, authentication algorithms, and encapsulation modes on both ends are consistent. If not, change them to be consistent.
<sysname> display ipsec proposal Number of proposals: 1 IPSec proposal name: p1 Encapsulation mode: Tunnel //Encapsulation mode Transform : ah-esp-new //Security protocol AH protocol : Authentication SHA2-HMAC-256 //AH authentication algorithm ESP protocol : Authentication SHA2-HMAC-256 //ESP authentication algorithm Encryption AES-256 //ESP encryption algorithm
It is recommended that the same algorithm be configured on both ends. If you do not know the algorithm used on the peer end (for example, you cannot log in to the peer device to view the configuration), use either of the following methods.
Method 1: Configure multiple algorithms on the firewall. The peer end selects the algorithm to be used. After the negotiation succeeds, run the display ipsec sa command on the firewall to view the finally negotiated algorithm information. Then, change the algorithm, protocol, and encapsulation mode in the IPSec proposal to the actually used algorithm, protocol, and encapsulation mode. This method takes effect in most scenarios unless the peer end does not have the multi-algorithm matching capability.
Method 2: Run the ike negotiate compatible command on the IKE peer to enable the compatibility algorithm so that the peer end can trigger negotiation. After the negotiation is successful, run the display ipsec sa command on the firewall to check the negotiated algorithm. Then change the algorithm, protocol, and encapsulation mode in the IPSec proposal to the actually used ones. This method requires the responder-only enable command in the site-to-site IPSec policy view.
For IKEv1, check whether the PFS configurations on both ends are consistent.
For a point-to-point IPSec policy, ensure that the PFS configurations on both ends are the same. For a point-to-multipoint IPSec policy, you do not need to configure the PFS in the template. If the peer carries the PFS, the PFS on the peer end is used for negotiation. If the PFS is configured in the template, ensure that the PFS configurations on both ends are the same.
Run the display ipsec policy command to check the PFS algorithm. Ensure that the PFS algorithms on both ends are consistent.
<sysname> display ipsec policy =========================================== IPSec policy group: "10" Using interface: GigabitEthernet0/0/2 =========================================== Sequence number: 10 Policy Alias: map1-10 Security data flow: 3100/IPv4 Peer name : rut2 Perfect forward secrecy: DH group 14 //PFS algorithm
If the fault persists, collect the following information and contact technical support personnel.
Run the save logfile command to save the log and trap information in the buffer to files.
<sysname> save logfile all Info: Save logfile successfully. Info: Save diagnostic logfile successfully.
After log and trap information files are generated, export the files using TFTP.
Run the display diagnostic-information file-name command to collect diagnostic information and save the information to a file.
<sysname> display diagnostic-information dia-info.txt Now saving the diagnostic information to the device 100% Info: The diagnostic information was saved to the device successfully
After a diagnostic information file is generated, export the file from the device using TFTP.
You can run the dir command in the user view to check whether the file is generated.
Collect the configurations and operation results of the preceding steps, and record the information in a file.
Run the debugging command to collect information about the IPSec tunnel establishment process.
<sysname> terminal monitor <sysname> terminal debugging <sysname> debugging ikev1 all //Debugging information collected when IKEv1 negotiation is used <sysname> debugging ikev2 all //Debugging information collected when IKEv2 negotiation is used <sysname> debugging ipsec all
After debugging is disabled, collect all diagnostic information and export the information to a file.
Collect the log and trap information on the device and export the information to files.
Collect packet information on interfaces and export the information using TFTP.
<sysname> system-view [sysname] acl 3100 [sysname-acl-adv-3100] acl 3100 //Define data flows. [sysname-acl-adv-3100] rule 5 permit ip source 10.1.1.1 0 destination 10.2.1.1 0 [sysname-acl-adv-3100] rule 5 permit ip source 10.2.1.1 0 destination 10.1.1.1 0 [sysname-acl-adv-3100] quit [sysname] packet-capture ipv4-packet 3100 interface GigabitEthernet 1/0/1 [sysname] packet-capture startup packet-num 1500 //Enable the function of obtaining packet header information. [sysname] packet-capture queue 0 to-file 1.cap //Save the obtained packet header information to the device.
After obtaining packet header information, delete the related configurations.
本文链接：https://hqyman.cn/post/5758.html 非本站原创文章欢迎转载，原创文章需保留本站地址！
休息一下，本站随机推荐观看栏目:
