Limitations and Precautions for IPSec

Hardware Requirements

The IPSec function is supported by all models.

Component Package Requirements

By default, IPSec does not support weak security algorithms such as MD5, SHA1, DES, 3DES, DH-GROUP1, DH-GROUP2, and DH-GROUP5. To use these algorithms, you need to install the weak security algorithm component package (product_version_WEAKEA.mod). For details about the component package, see Dynamic Loading.

Impact on Performance

• In scenarios where IPSec service reliability requirements is high (for example, in LTE scenarios), you are advised to enable DPD on both ends of the tunnel to ensure that the device can effectively detect and restore the peer tunnel fault. If dead peer detection (DPD) is enabled on the device and the network has many IPSec tunnels, as DPD packets are frequently sent and received, the device CPU resources are greatly consumed, deteriorating device performance. You can run the ike dpd and dpd commands to set a proper DPD idle time for IKE peers:
  • If there are less than 10,000 tunnels, you can use the default DPD idle time (30s).
  • If there are 10,000 to 20,000 tunnels, set the DPD idle time to 45s.
  • If there are more than 20,000 tunnels, setting the DPD idle time to 60s is recommended.
• The DH group value has impacts on IKE negotiation performance (such as the tunnel creation rate). A higher DH group value has greater impacts on IKE negotiation performance (for example, the tunnel creation rate greatly decreases).
• When the number of IPSec tunnels is greater than 50% of the maximum limit, high CPU usage alarms may be generated in a short period of time after the undo ipsec policy or undo ipsec profile command is run. After all the SAs are cleared, the CPU usage restores to the normal range.
• IPSec flow overlapping detection is enabled only during network upgrades or capacity expansion. As this function greatly consumes CPU resources and affects device performance, you are advised to run the undo ipsec flow-overlap check enable command to disable it when the network runs steadily (no upgrade or capacity expansion is performed).
• IPSec flow self-healing affects tunnel performance and throughput. To disable this function, run the undo ipsec share-flow recover enable command.
• When the SHA2-384 and SHA2-512 algorithms are used, the IPSec performance deteriorates to a certain extent.

Restrictions on the Use of IPSec

• The USG6635E/6655E, USG6680E and USG6712E/6716E do not apply to the scenario where the encryption tunnel of forward packets and the decryption tunnel of reverse packets are inconsistent.
• SM3 and SM4 apply only to IKEv1 negotiation.
• The RSA digital envelope authentication and SM2 digital envelope authentication method is defined by the State Cryptography Administration of China. It applies only to the IKEv1 main mode negotiation.
• In IPSec negotiation using the SM algorithm, IKEv1 phase 1 is implemented based on the SM standard, and phase 2 is implemented based on RFC 2409. During negotiation using the SM algorithm, negotiation can be successful and the tunnel can be established only when both ends of the tunnel use the same negotiation standard.
• The security protocol, authentication algorithm, encryption algorithm, and packet encapsulation mode on both tunnel endpoints must be the same when you configure a security proposal. Otherwise, tunnel negotiation will fail. If the PFS algorithm is configured, ensure that the two ends use the same PFS algorithm. Otherwise, tunnel negotiation will fail.
• In L2TP over IPSec scenarios, the function that the responder accepts the security proposal of the initiator is usually used together with L2TP. Separate use of this function will reduce network security, and is therefore not preferred.
• Setting the same 5-tuple information for branches and distinguishing the branches based only on their DSCP values are not recommended. The configurations will cause the traffic from the HQ fail to be sent to branches.
• When an IPSec policy references ACL rules, ACL rules must be configured in the ACL view. Otherwise, the IPSec policy fails to reference the ACL rules. In addition, if a large number of ACL rules are configured and service traffic exists on the tunnel, modifying the last several ACL rules will cause a temporary increase in the CPU usage. Therefore, you are advised to modify ACL configurations during off-peak hours.
• When configuring data flows to be encrypted by IPSec, configure refined ACL rules based on services to prevent unnecessary data flows from entering the encryption tunnel due to loose ACL rules, causing service interruption.
• Setting the MTU to a value less than 256 bytes is not recommended for the interface to which an IPSec policy group applies. As IP packets become longer after IPSec processing, a small MTU makes the interface divide a large IP packet into multiple fragments. The peer device may not properly receive or process such fragmented packets.

• When a NAT device is deployed between IPSec peers, NAT traversal must be enabled and the security protocol must be ESP.

• During IPSec tunnel migration, if the number of IPSec tunnels exceeds the maximum value or the license-controlled number, excess IPSec tunnels fail to migrate.

• In AH encapsulation mode, the DF flag bit of the inner packet is inherited to the outer packet, and the FW combines it with the DF flag bit of the outer layer to calculate the checksum of the packet. If the peer end of the tunnel removes the DF flag bit from the outer packet and then calculates the checksum, the checksums on both ends of the tunnel are inconsistent. As a result, the interconnection fails. To prevent this, run the ipsec df-bit clear command to ensure that the checksums on both ends of the tunnel are consistent.

• When configuring IPSec intelligent uplink selection, ensure that the number of rules in the ACL referenced by the IPSec policy does not reach the upper limit. Otherwise, negotiation in IPSec intelligent uplink selection fails. In addition, the number of rules in the referenced ACL cannot exceed 50% of the total number of rules. Otherwise, the link in IPSec intelligent uplink selection may be switched frequently because of a long tunnel negotiation period for link detection.
• IPSec intelligent link selection does not support VPN multi-instance.
• When mobile users remotely access the network using L2TP over IPSec, the IPSec in transport mode instead of tunnel mode can be configured.
• During IPSec tunnel migration, if the number of IPSec tunnels exceeds the maximum value, excess IPSec tunnels fail to migrate.
• It is not recommended that IPSec be deployed on both tunnel interfaces and other interfaces. If IPSec is deployed on both tunnel interfaces and other interfaces, the device functioning as the negotiation responder first attempts to perform tunnel negotiation through IPSec of a tunnel interface. If the device does not match IPSec access requirements of the tunnel interface, the device attempts to perform tunnel negotiation through IPSec of another interface.
• In transport mode, the flow information after IPSec negotiation must be consistent with the IPSec tunnel address, which is a 32-bit host address.
• In an IPSec tunnel scenario, remote-address and acl rule destination cannot be the same. Otherwise, tunnel negotiation or service traffic encryption and decryption may be abnormal due to incorrect route selection.
• On an IPv6 network, when packets such as detection and monitoring packets of an IPSec tunnel are transmitted over the tunnel, the corresponding ACL needs to be configured for these packets. Otherwise, these packets are discarded because they cannot enter the IPSec tunnel. For example, after a service packet comes out of the IPSec tunnel, the local firewall needs to send a "too big" packet to the peer end because the packet is too long. In this case, you need to configure an ACL for the "too big" packet. If no ACL is configured, the "too big" packet cannot be transmitted to the peer end through the tunnel, causing services to be abnormal.
• The maximum length of an IPSec encrypted packet sent from the peer device to the local device cannot exceed 1500 bytes after fragmentation and reassembly. Otherwise, the encrypted packet will be discarded.
• The original packets before entering the IPSec tunnel are recommended to have a proper length (for example, not exceeding 1500 bytes). Jumbo packets may fail to be transmitted in encrypted mode when entering the IPSec tunnel.
• In an IPSec scenario, if the firewall needs to return an ICMP error packet in response to a packet from the initiator, the source IP address of the ICMP error packet is not the destination IP address of the initiator's packet but the interface IP address of the firewall. Therefore, an ACL needs to be configured, so that the ICMP error packet can enter the IPSec tunnel. For example, in a scenario where the base station is interconnected with the firewall, if the length of an IPv6 service packet after IPSec tunnel decryption is greater than the IPv6 MTU value of the outbound interface, the local firewall needs to send an ICMP error packet to the base station. In this case, you need to configure an ACL (with the source address being the IP address of the outbound interface) for the ICMP error packet, so that the packet can enter the IPSec tunnel. If no ACL is configured, the packet cannot be transmitted to the base station through the tunnel, causing services to be abnormal.
• Only the SA that is dynamically negotiated by the IKE supports the anti-replay function. The SA that is manually generated does not support the anti-replay function. The SA that is manually generated is not affected by the anti-replay function.
• In an IPSec intelligent link selection scenario where link switchover is performed based on the link quality probe result, if the automatic switchback function is enabled for links with high priorities, a branch FW continuously sends ICMP packets to the HQ FW through idle links to detect the link quality. By default, a branch FW sends one ICMP packet per second, and a maximum of ten ICMP packets within a probe period. If there are too many links between the branch FW and the HQ FW, the HQ FW receives too many ICMP packets simultaneously. In this case, the HQ FW discards the received ICMP packets due to rate limit. As a result, the probe result is inaccurate. Therefore, the total number of links on the branch FW must be limited to ensure that the rate at which all branch FWs send ICMP packets to the HQ FW is lower than the rate limited for ICMP packets configured on the HQ FW. You can run the display firewall dataplane to manageplane car type icmp command to check the rate limited for ICMP packets on the HQ FW
• For the USG6610E/6620E, USG6630E/6650E, USG6680E and USG6712E/6716E, in certificate authentication scenarios, the RSA key length of the certificate must be set to 2048, 3072, or 4096. Otherwise, IKE negotiation using this certificate will be affected.
• For a multi-CPU device (USG6635E/6655E, USG6680E and USG6712E/6716E), , if a backup private line exists between a virtual system of the device and a peer device, the virtual system cannot establish an IPSec tunnel with the peer device across the public system or another virtual system. In this scenario, if the reset ike sa command is run to clear the SA established through IKE negotiation, service packets from the peer device are sent to the local virtual system through the backup private line. As a result, two identical reverse sessions exist on different CPUs of the local device. After the IPSec tunnel is re-established, service packets from the local virtual system to the peer device match the reverse session of the backup private line. As a result, the service packets cannot enter the IPSec tunnel for encrypted transmission, causing IPSec service faults.
• In transport mode, fragmentation before encryption is not supported.
• When configuring an ACL referenced by an IPSec policy, ensure that the ACL rule does not reference address groups that contain other address group members.When configuring an ACL referenced by an IPSec policy, an ACL rule can reference only address groups with members in mask format. An address group with members in other address groups or members in address range type cannot be referenced.
• The device does not support the scenario where SLB and IPSec services are used together.
• For a multi-CPU device, only one remote-address can be configured for an IKE peer.

Restrictions on the Use of the Web UI

• For versions earlier than V600R007C20SPC500, in IPSec Policy List of Network > IPSec > IPSec, you cannot view information about IPSec SAs of IPSec tunnels established using virtual tunnel interfaces. Instead, you can view information about IPSec SAs of IPSec tunnels established in ACL mode. For V600R007C20SPC500 and later versions, in IPSec Policy List of Network > IPSec > IPSec, you can view information about IPSec SAs of IPSec tunnels established using virtual tunnel interfaces. However, you cannot create or edit the IPSec SAs of IPSec tunnel established using the virtual tunnel interface.
• If multiple virtual systems share one public IP address to establish IPSec tunnels with the peer device, you must configure an IPSec policy in the root system and bind the policy to the virtual systems. You cannot modify IPSec negotiation parameter values on the virtual system web page.
• Configuring IPSec multi-instance on the web UI is not supported. In addition, IPSec policies configured with IPSec multi-instance cannot be modified on the web UI.
• IPSec VPN instances cannot be configured or modified on the web UI. If you configure an IPSec VPN instance through the CLI but view the configuration result on the web UI, the following two situations may occur based on your configuration:
  • If you bind a VPN instance to an IPSec tunnel interface, you can view the IPSec policy on the web UI.
  • If you bind a VPN instance to an IPSec tunnel, that is, running the sa binding vpn-instance command on the IKE peer, you can view the IPSec policy on the web UI, but you cannot modify the IPSec policy on the web UI.
• If you configure the IPSec intelligent uplink selection function using the CLI, you cannot modify the corresponding configuration through the web UI. Instead, you can only modify the configuration through the CLI. Because you cannot configure the next-hop information of IPSec intelligent uplink selection on the web UI, when you modify the command configuration on the web UI, the next-hop or link information configured using the original command may be deleted. As a result, services become abnormal.

Restrictions on the Use of IPSec Virtualization

• After an interface is allocated to a virtual system or the allocation is canceled, the interface configuration (such as IP address or IPSec policy) is deleted. Before allocating an interface to a virtual system, check whether the interface has related configurations to prevent misoperations from interrupting IPSec services.
• If multiple virtual systems share one public IP address to establish IPSec tunnels with the peer device, you must configure an IPSec policy in the root system and bind the policy to the virtual systems. Note the following points during the configuration:
  • The IPSec policy configured in the root system must be in the policy template mode.
  • Virtual systems cannot reference the ACLs configured in the root system. As the peer determines the encrypted data flows that enter IPSec tunnels through negotiation, there is no need to configure or reference ACLs in the root system.
• Virtual systems do not support IPSec intelligent uplink selection, IPSec load balancing, or IPSec VPN in Layer-2 transparent mode.

Restrictions on the Use of IPSec on IPv6 Networks

• IPSec6 does not support the following functions:
  • Transparent mode
  • Intelligent uplink selection
  • VPN multi-instance
  • IPSec fragmentation before encryption
  • IKEv1 + XAUTH authentication
  • IKEv2 + EAP authentication
  • IKEv2 redirection
  • Manual IPSec policy
  • IPSec policy based on virtual tunnel interfaces (IPv6 profile)
  • Invalid SPI recovery
  • Network resource delivery
  • Detection of Overlapping IPSec Flows
• IPSec 6over6 is supported in both the tunnel and transport modes, and IPSec 4over6 and IPSec 6over4 are supported only in the tunnel mode.
• IPSec 6over6 and IPSec 4over6 do not support NAT traversal. Encrypted data flows cannot be forwarded across virtual systems.
• ACL and ACL6 cannot be referenced simultaneously in the same IPSec policy group.
• Only one IPv6 address can be configured on the tunnel interface where an IPSec6 policy applies.
• IPSec policies cannot be used on the tunnel interface that has both an IPv4 address and an IPv6 address. Otherwise, an IPSec tunnel cannot be established. Therefore, before applying an IPSec6 policy on a tunnel interface, ensure that only an IPv6 address is configured on the tunnel interface. If an incorrect configuration is delivered and causes both IPv4 and IPv6 addresses to be configured on the tunnel interface where the IPSec6 policy is applied, you need to delete the IPv4 address and IPSec6 policy from the tunnel interface and then re-apply the IPSec6 policy to the tunnel interface. Note that the interval between deleting the IPSec6 policy and re-applying the IPSec6 policy must be longer than 5 seconds. Otherwise, the IPSec6 policy cannot take effect.
• When an IPv6 ACL is used to define IPSec-protected data flows and IPSec encryption needs to be performed on packets initiated by the local device, you need to run the route inject nexthop command to specify the IPv6 address of the next hop directly connected to the outbound interface.

Restrictions in Layer-2 Transparent Mode

• IPSec multi-instance is not supported.
• IPSec intelligent uplink selection is not supported.
• IPSec route injection is not supported.
• IPSec policy groups cannot be applied to VLAN interfaces or Layer-2 interfaces bound to VLANs.
• The request and response packets received by the device belong to different VLANs. You must run the vlan obscure enable command to enable the function of obscure VLAN. Otherwise, traffic detection is inaccurate and services are interrupted.
• To apply IPSec policy groups on a Layer-2 interface, you must run the tunnel local ip-address command to specify the local IP address of the IPSec tunnel. Otherwise, the IPSec policy group cannot be delivered successfully.

Restrictions on the Use with L2TP

• IPSec over L2TP is not supported.
• In L2TP over IPSec scenarios, if mobile users use devices with the Android 6.0 OS to establish IPSec tunnels with the firewall, only the SHA-1 authentication algorithm can be used. This is because the SHA2-256 algorithm of the Android 6.0 OS is implemented based on the draft, inconsistent with the RFC standard. If a mobile device uses SHA2-256 to establish an IPSec tunnel with the firewall, the two ends of the tunnel cannot properly communicate with each other.

Restrictions on the Use with NAT

Restrictions on the Use with Hot Standby

• In IPSec hot standby scenarios in active/standby mode, you must run the ipsec policy policy-name command to apply an IPSec policy group to a specified interface. This command will be backed up to the standby device during command backup. In IPSec hot standby scenarios in load sharing mode, you must run the ipsec policy policy-name { alone | master | slave } command to apply a security policy group to a specified interface. This command will not be backed up to the standby device during command backup.
• In IPSec hot standby scenarios with VRRP running and switches connected in the upstream and downstream directions, if the device serves as the initiator of the IPSec tunnel, you must run the tunnel local ip-address command to specify the virtual VRRP IP address as the IP address for initiating IPSec negotiation. If this command is not used, the interface IP address is used by default for negotiation. Once an active/standby switchover is performed, IPSec services will be interrupted.
• In IPSec hot standby scenarios, if the active device fails, an active/standby switchover is triggered. IPSec services are switched to the standby device. After the active device restarts, IPSec SAs on the standby device are backed up to the active device in batches. However, the IPSec SA batch backup takes some time. If the VRRP Group Management Protocol (VGMP) group preemption function is enabled and there are more than 10,000 IPSec SAs, the active device completes preemption before IPSec SA backup finishes, causing IPSec service anomalies. Therefore, if there are more than 10,000 IPSec SAs, you are advised to run the hrp preempt delay interval command to set a large preemption delay (300s recommended) or run the undo hrp preempt command to disable the preemption function.
• In IPSec hot standby scenarios, you should not run the hrp switch command to manually switch the active/standby status. If you do so, the standby device directly becomes active without backing up IPSec tunnel information from the active device, causing IPSec service interruption.
• If the device uses a template to establish an IPSec tunnel with the peer gateway, you are advised to set the IPSec SA aging time in the template to be 15% longer than that on the peer end. If the aging time in the template is shorter than that on the peer end, the IPSec SAs on the template side ages first, triggering the template side to renegotiate for a new IPSec SA. If new IPSec SAs fail to be negotiated within a given time range, the template has the old IPSec SAs deleted, disconnecting the IPSec tunnel and causing service forwarding failures.

• In dual-system hot backup scenarios, the local IP address of an IPSec tunnel cannot be configured as the peer IP address by using the remote-address command in the IKE peer view. Otherwise, the standby device cannot back up the IPSec tunnel information generated by hosts based on the IKE peer.

• When the undo hrp enable command is run to disable hot standby, created IPsec tunnels are automatically deleted, which affects IPsec services. Exercise caution when you run this command.