Limitations and Precautions for ASPF/ALG

Hardware Requirements

The ASPF/ALG is supported by all models.

License Requirements

The ASPF/ALG is not license-controlled.

Limitations on the Interworking with NAT

• For the DNS protocol, the NAT ALG function takes effect only in scenarios where server mapping is configured. In addition, when the server resides on the intranet and the client resides on the extranet, you must select Allow the Server to Use the Public IP Address for Internet Access (the no-reverse parameter is not involved in NAT Server configuration through the CLI) for the configured server mapping. Otherwise, the NAT ALG function does not take effect.
• When NAT ALG is used together with the source NAT policy and the NAT ALG function is configured for multi-channel protocols, such as FTP, you are not advised to specify the corresponding service matching conditions in the source NAT policy. Otherwise, communication may fail.

  The port information of the data channel is dynamically negotiated. If a service is specified in the source NAT policy, data packets cannot match the source NAT policy. As a result, the communication fails.

• As for destination NAT, the NAT ALG function supports only static destination NAT. In addition, if the NAT ALG function is configured for the H323, FTP, and SQLNET protocols that have the redirection function, the FW has server map entries generated, with the source being any, the destination being itself, and the destination port ranging from 10000 to 65535. This may affect the destination NAT function for other protocols. Therefore, you need to set the destination NAT port of other protocols to a value smaller than 10000.

  For example, the private address of server1 is 192.168.1.1, the private address of server2 (which is an H323 server) is 192.168.1.2, and both servers use public address 1.1.1.1 to provide services. To ensure that the servers can properly provide services, destination NAT1 is configured on the FW to map 1.1.1.1:10000 to 192.168.1.1:10000, and destination NAT2 is configured to map 1.1.1.1:1719 to 192.168.1.2:1719.

  After the NAT ALG function for H323 is enabled, a server map entry is generated on the FW during the service process. If the allocated port is 10000, server map entry any—>1.1.1.1:10000[192.168.1.2:10000] is generated. The server map entry has a higher priority than destination NAT, invalidating destination NAT1.

• If the network has VoIP services, NAT ALG is required. The FW supports only the following scenarios:
  • The server is on the Internet, while the client is on a private network. The client accesses the server through Source NAT. In this scenario, Source NAT in No-PAT mode is not supported.
  • The server is on a private network, while the client is on the Internet. The client accesses the server through NAT Server.
• The ALG function for a user-defined protocol does not support NAT64, NAT66 and DS-Lite scenarios.
• The H.323 client does not support the following scenarios in a point-to-point call:
  • The H.323 server is on an IPv6 network, and client 1 and client 2 are on an IPv4 network and an IPv6 network, respectively. Traffic between two clients needs to be translated using NAT64. The FW connects to client 1, H.323 server, and NAT64 device. After the ALG function of the H.323 protocol is enabled on the FW, when client 1 calls client 2, the FW generates a destination server map entry. The traffic matches the server map entry, and the destination address is translated into an IPv6 address but the FW connects to the NAT64 device using an IPv4 address. Due to different address types, the FW discards packets.
  • The H.323 server is on an IPv4 network, and client 1 and client 2 are on an IPv6 network and an IPv4 network, respectively. Traffic between two clients needs to be translated using NAT64. The FW connects to client 1, H.323 server, and NAT64 device. After the ALG function of the H.323 protocol is enabled on the FW, when client 1 calls client 2, the FW generates a destination server map entry. The traffic matches the server map entry, and the destination address is translated into an IPv4 address but the FW connects to the NAT64 device using an IPv6 address. Due to different address types, the FW discards packets.
• When DNS ALG and NAT Server are used together, you are advised not to specify both the port and protocol in the NAT Server configuration simultaneously. Otherwise, DNS ALG address translation fails.
• When both NAT64 and NAT44 are used, the FW does not support ASPF and ALG.

Other Limitations

• In versions earlier than V600R007C20SPC603, the FW supports ASPF/NAT ALG for the standard SIP protocol, not for extended SIP protocols (SIP-I and SIP-T).
• In V600R007C20SPC603 and later versions, the FW supports only the ASPF/ALG of the RFC and GB28181 SIP protocols. However, ASPF/ALG of other SIP protocols such as extended SIP protocols (SIP-I and SIP-T) and GB standards (except GB28181) are not supported.
• The ASPF/NAT ALG does not apply to TCP segment.
• The ASPF/NAT ALG can process only fragmented SIP packets. Before being processed by the ASPF/NAT ALG, fragmented SIP packets must be reassembled first. If the size of reassembled SIP packets exceeds 2048 bytes (USG6510E/6510E-POE/6530E) or 9500 bytes (USG6515E/6550E/6560E/6580E, USG6525E/6555E/6565E/6575E-B/6585E/6605E-B, USG6610E/6620E, USG6615E/6625E, USG6630E/6650E, USG6635E/6655E, USG6680E, and USG6712E/6716E), the packets are directly forwarded, without being processed by the ASPF/NAT ALG.
• For SIP, H323, and MGCP, if the communication parties reside on no smaller than three security zones, the ASPF/NAT ALG function does not take effect.
• The ASPF/NAT ALG function for SIP configured through the web UI takes effect only for UDP-based and TLS-encrypted SIP traffic. The ASPF/NAT ALG function for TCP-based SIP traffic can be configured only through the detect [ ipv6 ] sip tcp command.
• For some protocols, ASPF/NAT ALG needs to be configured only in specific scenarios. Therefore, you are not advised to configure ASPF/NAT ALG in other scenarios to avoid unnecessary performance consumption.
  • For DNS, NAT ALG takes effect only when NAT Server is configured.
  • For PPTP, NAT ALG takes effect only in NAT scenarios where port mapping is configured.

Precautions

• The ASPF and NAT ALG functions share configurations. Enabling one function makes another take effect.
• If you do not need to use the ASPF/NAT ALG function for a specific protocol, disable it. For example, service traffic corresponding to H.323, SIP, and MGCP is usually of a large volume. Enabling the ASPF/NAT ALG function may compromise the performance. The compromised performance is subject to the service volume. As for the QQ protocol that uses the common port 8000, if the ASPF/NAT ALG function is enabled, it is possible that a large number of non-QQ packets may enter the ASPF/NAT ALG process, causing unnecessary performance occupation.
• For SIP, if there are other NAT traversal devices, SIP NAT ALG cannot be enabled on the FW. Otherwise, services are interrupted.
• In NAT64 scenarios, the FW performs NAT ALG for FTP, RTSP, SIP, H.323 traffic by default. The FW performs NAT ALG for H.323 traffic by default. For SIP, only the SIP traffic based on TCP and UDP can be processed.
• After the ASPF/NAT ALG configuration is modified (for example, the ASPF/NAT ALG function is disabled), to ensure that the configuration modification immediately takes effect, run the reset firewall server-map or reset firewall ipv6 server-map command in the diagnose view to delete the corresponding server map entry. Before deleting the server map entry, delete the corresponding session. Otherwise, the server map entry cannot be completely deleted.