No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

NE20E-S2 V800R010C10SPC500 Feature Description - NAT and IPv6 Transition 01

This is NE20E-S2 V800R010C10SPC500 Feature Description - NAT and IPv6 Transition
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
NAT ALG

NAT ALG

The application level gateway (ALG) provides transparent translation for some application layer protocols.

Packets of many application layer protocols contain user information, including IP addresses and port numbers. These protocol packets may fail to be forwarded because NAT cannot identify the IP addresses and port numbers carried in these protocol packets. To address this problem, the NAT ALG technique can be used to perform the mapping for IP addresses and port numbers of protocol packets and also translate IP addresses and port numbers carried in protocol packets.

NAT ALG supports various protocols, such as the Internet Control Message Protocol (ICMP), UDP-based Session Initiation Protocol (SIP), TCP-based Real-Time Streaming Protocol (RTSP), Point-to-Point Tunneling Protocol (PPTP), domain name service (DNS), and File Transfer Protocol (FTP).

NAT ALG does not support HA.

NAT ALG Support for FTP

FTP is working in either of proactive (also called port mode) or passive (PASV) mode. NAT ALG processes FTP packets in the following scenarios:
  • An FTP server on a public network is working in port mode.
  • An FTP server on a private network is working in passive mode.
In Figure 2-5, an FTP server on a public network is working in port mode. Without the NAT ALG function, a NAT device does not process the private IP address or port number carried in payload of FTP packets sent by a private network host. After the FTP server working in port mode receives the packets, it cannot identify the private IP address or port number carried in the FTP packets. As a result, the FTP server cannot establish an FTP connection to the private network host.
Figure 2-5 FTP ALG scenario
The process of using the ALG function to establish an FTP connection is as follows:
  1. The private network host and the public network FTP server establish a TCP control connection using three handshakes.
  2. The host sends FTP Port packets carrying a destination IP address and port number to the FTP server to request to establish a data connection to the server.
  3. Upon receipt of the FTP Port packets, the ALG-capable NAT device maps the private IP address and port number carried in payload to the public IP address and port number, respectively. In this example, the private IP address 192.168.0.10 carried in payload is translated to a public IP address 10.10.10.10, and private port 1024 to public port 5000.
  4. Upon receipt of the FTP Port packets, the public network FTP server parses the packets and sends packets with a destination public IP address of 10.10.10.10 and a port number of 5000 to initiate a data connection to the private network host.
  5. Upon receipt of the packets, the NAT device translates the destination public IP address and port number to the private IP address and port number, respectively before sending the packets to the host. Then the host can successfully establish a data connection to the FTP server.

NAT ALG Support for ICMP

In Figure 2-6, a public network host attempts to access a private network FTP server with a public IP address of 10.10.10.10. If port 21 on the FTP server is disabled, the FTP server sends an ICMP error message to the public network host.
Figure 2-6 ICMP ALG scenario

The data payload of the ICMP error message carries a private IP address. Without the NAT ALG function, the NAT device forwards the message to the public network host without processing the private IP address in the data payload. Upon receipt of the message, the public network cannot identify the application to which the message belongs. In addition, the private IP address of the private network FTP server is leaked to the public network.

With the NAT AGL function, the NAT device translates the private IP address of 192.168.0.10 of the FTP server to a public IP address of 10.10.10.10 and then forwards the ICMP message to the public network host. Upon receipt of the ICMP message, the host can properly identify the FTP application. In addition, the risk of leaking the private IP address of the FTP server to the public network is eliminated.

NAT ALG Support for RTSP

In Figure 2-7, RTSP establishes and controls one or more time-synchronous continuous media stream connections, such as audio and video connections. Although a control stream may be inserted into a continuous media stream, RTSP itself does not send a media stream. RTSP functions only as a network remote controller for a media server. RTSP control packets include SETUP, PLAY, PAUSE, and TEARDOWN packets. SETUP packets are used to instruct a server to establish an RTSP session to assign resources to a stream. Over the RTSP session, PLAY packets can be sent to play audio or video programs, and PAUSE packets can be sent to pause audio or video programs.
Figure 2-7 RTSP ALG scenario
RTSP can work in either inband or outband mode.
  • Inband mode: Also called the interleaving mode. A media stream is transmitted along a control channel and does not need to be processed by the ALG function.
  • Outband mode: A media stream is transmitted along a data channel and carries a port number that is negotiated using control packets. The ALG function must process the media stream packets.
The ALG module processes RTSP SETUP packets carrying client data port numbers and their response packets each carrying a client data port number and a server data port number in the following situations:
  1. The client is on a private network, and the server is on a public network. The client private port number in payload of each SETUP packet is replaced with a public port number. The client public port number in each SETUP response packet is replaced with the client private port number.
  2. The client is on a public network, and the server is on a private network. The client private port number in the SETUP packet payload is unchanged, and the server private port number in SETUP response packet payload is replaced with the server public port number.

The ALG module also identifies the TEARDOWN packet, changes the aging time of a stream table, and deletes the aging stream table to release resources.

NAT ALG Support for PPTP

In Figure 2-8, a PPTP client is on a private network, and a PPTP server is on a public network. Packets transmitted along the data channel between the client and server must be processed by the ALG function. Generic Routing Encapsulation (GRE) packets transmitted along the data channel carry IP addresses and call IDs, but not port numbers. If a NAT device maps IP addresses in packets of various PPTP clients to the same public IP address, the NAT device cannot forward returned public network PPTP packets to the clients.

To distinguish clients on the private network, the NAT device replaces the call IDs in packets with different call IDs and saves call ID mappings to distinguish private clients. After the server sends response packets, the NAT server can restore the call ID in each packet based on call ID mappings and properly forward the packets to the clients.

When a PPTP server is on a private network, and a PPTP client is on a public network, the NAT device only performs common NAT to translate a private IP address to a public IP address, but does not perform the ALG function.
Figure 2-8 PPTP ALG scenario
PPTP ALG processing is as follows:
  1. Set up a PPTP TCP connection.
  2. A PPTP client sends a PPTP Outgoing-Call-Request packet to a PPTP server to establish a PPTP tunnel and selects a call ID to identify the PPTP tunnel along which the client sends data to a PPTP server.
  3. Upon receipt of the Outgoing-Call-Request packet, the PPTP server sends an Outgoing-Call-Reply packet and selects a call ID to identify the tunnel along which the server sends data to the client.
  4. The PPTP client and server send GRE data packets on a GRE tunnel.
  5. The client sends a PPTP Clear-Call-Request packet to inform the PPTP server that the PPTP control connection is to be terminated.
  6. The server replies with a PPTP Call-Disconnected-Notify packet.
  7. The server replies with a PPTP Stop-Control-Connection-Reply packet.
  8. The client closes the PPTP TCP connection.

NAT ALG Support for SIP

SIP is a session control protocol running over the application layer. SIP can create, modify, or terminate multimedia sessions or invite participants to an existing session. SIP is a request/response model. Each event involves at least a specific request to execute a method or function and a response sent by a server. All devices register with a server. Then a client can negotiate with a user on a media channel and communicate with the user through the server. The IP address in the Contact field must be the same as that in the packet header. An inconsistency between the IP addresses in the Contact field and packet header is not supported. SIP NAT ALG processes protocol packets used in registration and channel negotiation in the following situations:
  • Users are connected to various NAT devices in a SIP ALG scenario.

    In Figure 2-9, user packets carrying private IP addresses, and each user is connected to a specific NAT device. UA1 sends SIP packets to NAT device 1, and NAT device 1 performs the ALG function on the SIP packets and forwards them along a media stream channel. NAT device 2 processes the ALG function on UA2 packets and forwards them along the media stream channel. UA1 and UA2 communicate through the media stream channel.
    Figure 2-9 Each user connected to a specific NAT device in a SIP ALG scenario
  • Users are connected to the same NAT device in a SIP ALG scenario.

    In Figure 2-10, user packets carrying private IP addresses, and users are connected to the same CGN device. NAT device 1 performs the AGL function on UA1 packets and forwards them along a media stream channel. The destination IP address carried in the packets is an IP address pool address. The ALG function is performed again on the packets. UA1 and UA2 communicate through the media stream channel.
    Figure 2-10 Users connected to the same NAT device in a SIP ALG scenario
  • Private and public network users coexist in a SIP ALG scenario.

    In Figure 2-11, UA1 is assigned a private IP address, and UA2 is assigned a public IP address. The NAT device processes the source information in UA1-to-UA2 packets and the destination information in UA2-to-UA1 packets.
    Figure 2-11 Private and public network users coexisting in a SIP ALG scenario

NAT ALG Support for DNS Mapping

DNS usage scenarios are as follows:
  • A DNS server is on a private network, and an ISP server is on either a public or private network. In this situation, DNS ALG is not used.
  • A DNS server and an ISP server are on a public network. This situation is supported naturally and is irrelevant to NAT devices.
  • A DNS server is deployed on a public network, and an ISP server is on a private network. The NAT Server function or DNS mapping function can be used.

The NAT Server function allows DNS to traverse through a NAT device, whereas all DNS traffic must travel through the NAT device. In this case, DNS mapping must be configured to translate a public IP address in payload of the DNS response packet into a private IP address so that users can access the private ISP server.

In Figure 2-12, a private network host attempts to access the private network WWW server, with a domain name of www.sample.com and a public IP address of 10.10.10.10. The DNS server is on a public network. The private network host needs to obtain the private IP address of the WWW server and access the server.
Figure 2-12 DNS mapping ALG scenario
The DNS mapping ALG processing is as follows:
  1. The private network host sends a DNS request packet carrying a domain name to the public network DNS server.
  2. Upon receipt of the request, the DNS server obtains the public IP address (10.10.10.10) mapped to the domain name of www.sample.com, adds the IP address to the DNS response packet, and sends the response to the private host.
  3. Upon receipt of the response, the ALG-capable NAT device replaces the public IP address of 10.10.10.10 in payload of the response packet with the private IP address of 192.168.0.10 of the private network www server. Then the NAT device forwards the DNS response packet to the private network host.
  4. Upon receipt of the DNS response packet, the host obtains the private IP address mapped to the domain name of www.sample.com and is able to communicate with the private network WWW server.
Translation
Download
Updated: 2019-01-02

Document ID: EDOC1100055472

Views: 2649

Downloads: 3

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next