[Dr.WoW] [No.21] NAT ALG Highlighted

Latest reply: Sep 16, 2019 02:47:55 5388 5 0 0

In the previous sections, I have introduced Source NAT, NAT Server, and bidirectional NAT supported by firewalls. These NAT functions can be flexibly used in different scenarios. As we know, NAT translates only the addresses in headers. For some protocols, such as FTP, packet payloads also carry address information. If firewalls cannot properly process such information, FTP may not work properly. Well, how should firewalls process such protocol packets?

1 FTP Packets Traversing NAT Devices

Let's use FTP as an example to see what problems occur when FTP packets attempt to pass through NAT devices. In this example, an FTP client resides on an intranet, and an FTP server resides on the Internet. FTP works in active mode. Figure 1-1 shows the FTP interaction process on the NAT device.
Figure 1-1 FTP interaction process 1 when Source NAT is configured

[Dr.WoW] [No.21] NAT ALG-1330855-1

 

We can see that after a control connection is established between the FTP client and server, the client sends a PORT command packet to the server, and the packet contains the private address and port of the client. The firewall directly forwards the packet to the server. After receiving the packet, the FTP server initiates a data connection to 192.168.1.2 as instructed by the PORT command. The problem is incurred. 192.168.1.2 is a private address. Packets destined for this address cannot be transmitted on the Internet. As a result, the FTP service is abnormal.

What should the firewall do to resolve the problem? If the firewall translates both the source address in the header and the IP address in the application-layer information in the payload, the data connection can be established.

The NAT Application Level Gateway (ALG) function resolves the problem. As a technique to help packets traverse firewalls, NAT ALG enables a firewall to translate the IP addresses in both headers and payloads. Figure 1-2 shows the FTP interaction process after NAT ALG is enabled on the firewall.
Figure 1-2 FTP interaction process 2 when Source NAT is configured

[Dr.WoW] [No.21] NAT ALG-1330855-2

 

After NAT ALG is enabled, the firewall translates the IP address carried in the PORT command packet payload into the public address 1.1.1.1. After receiving the packet, the FTP server initiates a data connection to 1.1.1.1.

You may have another question. Can the firewall permit the connection request even if the FTP server can initiate the connection request? This question is so familiar. Right? To find the answer, let's go back to the ASPF function in chapter 2 "Security Policy". After ASPF is enabled, the firewall opens up an invisible channel for FTP data to bypass security policy checks, traversing the firewall. The FTP service requires ASPF in NAT scenarios. Actually, NAT ALG and ASPF are implemented using one command. Enabling NAT ALG also has ASPF enabled. Therefore, after NAT ALG is enabled, the following server-map entry is generated:

Type: ASPF,  3.3.3.3 -> 1.1.1.1:24576[192.168.1.2:55177],  Zone:--- 
 Protocol: tcp(Appro: ftp-data),  Left-Time:00:00:03,  Pool: ---               
 Vpn: public -> public

This server-map entry has address translation information. Before the aging time expires, this entry helps the FTP server's data connection request packet traverse the firewall and accurately arrive at the FTP client on the intranet. Figure 1-3 shows the complete FTP interaction process.
Figure 1-3 FTP interaction process 3 when Source NAT is configured

[Dr.WoW] [No.21] NAT ALG-1330855-3

 

In addition to the Source NAT scenario, the NAT Server scenario requires NAT ALG and ASPF. In this example, an FTP client resides on the Internet, and an FTP server resides on an intranet. FTP works in passive mode. Figure 1-4 shows the complete FTP interaction process.
Figure 1-4 FTP interaction process when NAT Server is configured

[Dr.WoW] [No.21] NAT ALG-1330855-4

 

The following server-map entries are generated on the firewall:

[FW] display firewall server-map

server-map item(s)

 ------------------------------------------------------------------------------

 Nat Server, any -> 1.1.1.1:21[192.168.1.2:21], Zone: ---

   Protocol: tcp(Appro: ftp), Left-Time: --:--:--, Addr-Pool: ---

   VPN: public -> public

 

 Nat Server Reverse, 192.168.1.2[1.1.1.1] -> any, Zone: ---

   Protocol: any(Appro: ---), Left-Time: --:--:--, Addr-Pool: ---

   VPN: public -> public

 

 ASPF, 3.3.3.3 -> 1.1.1.1:4097[192.168.1.2:2049], Zone: ---

   Protocol: tcp(Appro: ftp-data), Left-Time: 00:00:53, Addr-Pool: ---

   VPN: public -> public

The control connection packet initiated by the FTP client matches the forward server-map entry for NAT Server, and the address is translated. The data connection packet initiated by the FTP client matches the server-map entry for ASPF, and the address is translated.

In conclusion, if multi-channel protocols such as FTP, SIP, and H.323 are used and NAT applies on a network, enabling both NAT ALG and ASPF on the firewall is recommended, so that the protocols can work properly.

2 QQ/MSN/User-defined Protocol Packets Traversing NAT Devices

We also mentioned QQ, MSN, and user-defined protocols in  "Security Policy". Firewalls classify such protocols into one type: STUN. STUN is short for Simple Traversal of UDP Through Network Address Translators, which is a NAT traversal mode. Unlike NAT ALG, STUN does not need any processing on NAT devices. Instead, the STUN client on an intranet obtains its public address through information exchanges between the STUN client and server. Then, the client adds the public address in the payload and sends the packet. In this manner, the server on the Internet obtains the public address of the client from the payload and initiates a connection request to the client.

STUN protocols are responsible for their running during address translation. Therefore, NAT ALG is not required for these protocols. However, we still to consider how to make their service packets pass through the firewall. The solution is also ASPF. After a packet matches the ASPF server-map entry, it can traverse the firewall.

TFTP is used as an example. The following part provides a triplet ASPF server-map entry for the user-defined protocol in a NAT scenario (the server-map entries generated for QQ and MSN are similar to this server-map entry):

Type: STUN,  ANY -> 1.1.1.1:4096[192.168.1.2:63212],  Zone:---          

 Protocol: udp(Appro: stun-derived),  Left-Time:00:04:58,  Pool: 1, Section: 0 

 Vpn: public -> public

 Type: STUN Reverse,  192.168.1.2:63212[1.1.1.1:4096] -> ANY,  Zone:---  

 Protocol: udp(Appro: stun-derived),  Left-Time:00:04:58,  Pool: 1, Section: 0 

 Vpn: public -> public

Unlike the entries generated in non-NAT scenarios, these entries contain address translation information. In addition, two server-map entries are generated. The entry with the Type being STUN is the forward entry, while the entry with the Type being STUN Reverse is the reverse entry.

Before the aging time expires, the forward entry helps the connection request initiated by the TFTP server traverse the firewall and accurately arrive at the TFTP client on the intranet; the reverse entry helps the firewall translate the address and port (63212) of the packet sent from the TFTP client to the server into the public address (1.1.1.1) and port (4096). This implementation ensures that a specific application (identified by the port number) for an intranet user is presented using the fixed public address and port, ensuring the normal running of TFTP services.

3 One Command Controlling Two Functions

In early Huawei firewalls, ASPF and NAT ALG are controlled using separate commands. Currently, most firewalls use one command to control these two functions. To be specific, the detect command can be used in the intrazone or interzone view to enable ASPF. Then, NAT ALG is automatically enabled.

The firewall determines the use of NAT ALG, ASPF, or both as required. What we should do is only to run the command, reducing the configuration workload.

Specific to typical protocols, Table 1-1 lists the firewall processing modes after the detect command is used.

Table 1-1 Processing modes for typical protocols

Typical Protocol

NAT Scenario or Not

Effective Function

Effect

FTP

SIP

H323

Non-NAT scenario

ASPF

Server-map entries are generated to help the packets from other hosts to FTP, SIP, and H.323 hosts traverse the firewall.

NAT scenario

NAT ALG

The IP addresses in payloads are translated.

ASPF

Server-map entries (with address translation information) are generated to help the packets from other hosts on the Internet to FTP, SIP, and H.323 hosts on an intranet traverse the firewall.

QQ

MSN

User-defined

Non-NAT scenario

ASPF

Triplet server-map entries are generated to help the packets from other hosts to QQ, MSN, and user-defined hosts traverse the firewall.

NAT scenario

ASPF

Triplet server-map entries (with address translation information) are generated to help the packets from other hosts on the Internet to QQ, MSN, and user-defined hosts on an intranet traverse the firewall.

 

As indicated in the preceding table, ASPF generates a triplet server-map entry for a user-defined protocol in the NAT scenario. We also mentioned triplet NAT in section 4.1.6 "Triplet NAT". What is the difference between them?

4 Differences Between ASPF for User-defined Protocols and Triplet NAT

Triplet NAT allows the co-existence of P2P and NAT. When an intranet host accesses the Internet, an asymmetric network system is established after NAT is performed on a firewall. This means that the intranet host can access the Internet, but Internet users cannot initiate access to the intranet host.

After triplet NAT is deployed, the firewall generates a server-map entry to allow the packets from an Internet user to the intranet user to traverse the firewall. In this way, P2P-based applications such as file sharing, voice communications, and video transmission can properly run in NAT scenarios.

The server map for triple NAT contains the source (forward) and destination (reverse) entries.

 Type: FullCone Src,  192.168.1.2:51451[1.1.1.1:2048] -> ANY,  Zone:---  

 Protocol: tcp(Appro: ---),  Left-Time:00:00:57,  Pool: 1, Section: 0          

 Vpn: public -> public

 Type: FullCone Dst,  ANY -> 1.1.1.1:2048[192.168.1.2:51451],  Zone:---  

 Protocol: tcp(Appro: ---),  Left-Time:00:00:57,  Pool: 1, Section: 0          

 Vpn: public -> public

In the preceding example, the entry marked FullCone Src is the source server-map entry. Before the aging time expires, the addresses of the packets that the intranet host initiates using the specific port (51451) to the Internet are translated into the public address (1.1.1.1) and port (2048). This implementation ensures that a specific application (identified by the port number) for the intranet user is presented using the fixed public address and port, ensuring the normal running of P2P services. The entry marked FullCone Dst is the destination server-map entry. Before the aging time expires, Internet users can initiate access to the specified intranet user.

If we compare these server-map entries with the triplet server-map entries that ASPF generates for user-defined protocols in NAT scenarios, we can find that two server-map entries are generated in both conditions, including the address, port, and protocol information. The ASPF processing for user-defined protocols in NAT scenarios can be considered as a special triplet NAT implementation. Both techniques allow P2P packets to traverse firewalls.

Let's look at their difference. ASPF applies to both NAT and non-NAT scenarios. In non-NAT scenarios, triplet server-map entries do not carry address translation information. In NAT scenarios, triplet server-map entries carry address translation information. As a NAT mode, triplet NAT works only in NAT scenarios, and its server-map entries carry address translation information.

Another important difference is that after a packet matches an ASPF triplet server-map entry, the firewall allows the packet to pass without checking it based on security policies (the aspf packet-filter acl-number { inbound | outbound } command in the interzone view or the aspf packet-filter acl-number command in the intrazone view can also be configured to filter packets); after a packet matches a triplet NAT server-map entry, the firewall determines whether to check the packet based on security policies according to the firewall endpoint-independent filter enable command setting. If this function is enabled, the firewall does not check the packet. If this function is disabled, the firewall checks the packet.

From the configuration perspective, the ASPF configuration for a user-defined protocol requires the familiarity of the protocol features for the accurate ACL definition. An incorrect configuration may cause the protocol unable to work or affect the normal running of other services. Compared with the ASPF configuration, the triplet NAT configuration is simpler. What we should do is to configure a NAT policy and specify the address pool mode to triplet NAT (full-cone).

Their support conditions on Huawei firewalls also differ. The USG9500 series supports both ASPF for user-defined protocols and triplet NAT; the USG2000/5000/6000 series supports only ASPF for user-defined protocols. When both NAT and P2P applications exist on a network, you are advised to configure triplet NAT on the USG9500 series or ASPF for user-defined protocols on the USG2000/5000/6000 series for the normal running of P2P services.

Table 1-2 lists the comparison between ASPF for user-defined protocols and triplet NAT.

Table 1-2 Differences between ASPF for user-defined protocols and triplet NAT

Item

ASPF for User-defined Protocols

Triplet NAT

Server-map entry elements

Triplet

Including the address, port, and protocol type

Triplet

Including the address, port, and protocol type

Number of server-map entries

Two

Including the forward and reverse entries

Two

Including the source and destination entries

Operating environment

NAT and non-NAT scenarios

NAT scenario

Impact on security policies

The packets matching ASPF server-map entries are not controlled by security policies.

A specific command setting determines whether the packets matching triplet NAT server-map entries are controlled by security policies.

Configuration requirement

ACL rules must be accurately defined.

The NAT address pool must be set to the full-cone mode.

Support condition

Supported by the USG2000/5000/6000/9500 series

Supported only by the USG9500

 

 

 

To view the list of all Dr. WoW technical posts, click here.

  • x
  • convention:

user_2790689
Created Jun 12, 2015 08:06:04 Helpful(0) Helpful(0)

Thank you.
  • x
  • convention:

CippaLippa
Created Jan 18, 2017 12:07:15 Helpful(0) Helpful(0)

Hi

regarding ASPF for ftp, sip and h323 , are the packets matching ASPF server-map entries controlled by security policies or not?

Paolo
  • x
  • convention:

MPLSTE
Created Jan 21, 2017 09:13:49 Helpful(0) Helpful(0)

good
  • x
  • convention:

HCNA R&S
JorgeMX
Created 6 days ago Helpful(0) Helpful(0)

@dr.wow Good day.

Could you help me with the next question I have

Which configuration is correct to implement NAT ALG function?

a) NAT ALG Protocol
b) ALG protocol
c) NAT protocol
d) detect protocol

Regards from Mexcio!
  • x
  • convention:

Senior Cybersecurity Engineer
chenhui
Admin Created 3 days ago Helpful(0) Helpful(0)

Posted by JorgeMX at 2019-09-13 17:37 @dr.wow Good day.Could you help me with the next question I haveWhich configuration is correct to im ...
D
  • x
  • convention:

Reply

Reply
You need to log in to reply to the post Login | Register

Notice Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " Privacy."
If the attachment button is not available, update the Adobe Flash Player to the latest version!
Login and enjoy all the member benefits

Login and enjoy all the member benefits

Login