2个命令起到的作用是一样的,简而言之就是某些第应用层协议如FTP
会在应用层封包中包括第三层的地址信息如端口号IP地址，而当IP包经过NAT/PAT时，这些第三层地址信息会被translated.而
第四层-应用层中的信息没有做相应改变，这样会导致协议失败。另一个情况就是，可以监控并允许类似FTP等需要动态打开第二通道的协议包通过。
juniper中称为ALG (Application Layer Gateway)。cisco称为fix up
| Knowledge Base ID: | KB13530 |
| Version: | 1.0 |
| Published: | 06 Mar 2009 |
| Categories: |  Firewall/IPSec_VPN ScreenOS |
An ALG implementation requires a ScreenOS gateway to inspect the application layer payload of a packet and understand the application control messages. An enabled ALG automatically kicks in and performs application layer inspection and the dynamic opening/closing of TCP/UDP ports as well as the associated network/port address translation when a ScreenOS security policy that uses its associated service is referenced with matching traffic. For instance, a policy that references the FTP service on its default TCP port will automatically use the FTP ALG as long as the FTP ALG is enabled globally or for that particular policy on the ScreenOS gateway.
You also can configure ALGs to be triggered when an ALG-supported application is running on a non default, custom port. ScreenOS gateways ship with a wide range of available ALGs. Support for new ALGs is frequently added with new releases of ScreenOS. Additionally, ScreenOS offers a rich suite of ALG debugging capabilities that show ALG hits and dynamic pinholes being opened on the gateway.
摘录自：http://my.safaribooksonline.com/9781597491181/ch10lev1sec7
Understanding Application Layer Gateways
Application Layer Gateways are algorithms within ScreenOS that handle dynamic firewall policies that certain protocols require, such as FTP. Many such protocols were designed without security or other access controls in mind, which can cause problems when firewalls are introduced.
For example, FTP uses multiple sessions to facilitate file transfers—a primary command channel, and secondary data channels for directory listings and file transfers. Often, these data channels will flow in a direction opposite that of the original command channel. Since these data channels could connect on any port, it's almost impossible to create a static firewall policy that would permit these data channels and yet still provide adequate protection.
The FTP ALG automatically solves this problem by monitoring the FTP command channel, looking for FTP port commands that specify which source and destination ports are being requested, and dynamically opening up that specific combination of source IP/port and destination IP/port firewall policy (called a gate) that permits the session to flow. Once the session is complete, the gate is immediately closed.
The FTP ALG also handles the special case where the FTP session flows through a NAT interface. In this circumstance, the endpoints don't always realize their addresses are being translated midstream. The FTP port commands use whatever IP the endpoint hosts' interfaces are configured for, which, in the case of a host behind a NAT firewall, will typically be unreachable from the Internet.
The ALG handles this at the application layer by modifying the ASCII port command in-situ, replacing the inside IP with the IP of the NAT interface. Since port commands are passed as ASCII text, including the IP address, the chances are high that the number of characters that represent the inside IP and the external IP won't exactly match (for example, an inside address of 192.168.1.5 contains 11 characters, which may be translated to something like 123.123.123.123 at 15 characters, or something like 1.2.3.4, which contains only 7). The firewall cannot inject these extra bytes of data without modifying the TCP checksum as well as the TCP sequence numbers. It achieves this by essentially proxying the connection at the TCP layer. This is similar to the SYN proxy feature used by the TCP flood SCREEN setting.
Deep Inspection Firewalls and Passive FTP (also known as Stateful Inspection Firewalls)
This blog post describes the situation that exists when an FTP server is located behind a Deep Inspection Firewall. (My FTP server, for example, is on a server located behind a Juniper Networks Netscreen Firewall.)
The Deep Inspection Firewall plays an important role in Passive FTP data connections. When a file is to be transferred (uploaded or downloaded) in passive mode, a PASV command is first sent to the FTP server. The FTP server sends a response providing the IP address and port number where the client should initiate a TCP/IP socket connection to establish the data channel. The firewall inspects the FTP traffic and notices the PASV reply. It knows that an inbound connection will be arriving momentarily from the FTP client for the given port. Normally the firewall would block this inbound connection, but because it knows that it is a "valid" part of an established FTP session, the traffic is allowed to pass through the firewall.
Here’s the big problem: Let’s say you’re trying to do passive FTP over SSL. Because the traffic on the FTP control channel (port 21) is encrypted, the firewall is unable to inspect it. It no longer knows to allow the data connection. It won’t be possible to upload or download files, or get directory listings.
There are two solutions:
1) Send a CCC command to the FTP server. CCC is the "Clear Control Channel" command. Some FTP servers support it, whereas others don’t. After sending CCC, the transmissions over the control channel are unencrypted, but data transfers (directory listings and file transfers) remain encrypted. The deep-inspection firewall is now able to inspect the PASV reply and allow the data connection to become established.
2) Open a specific range of ports on the firewall and force the FTP server to choose ports within this range. FileZilla is an FTP server which provides this option (although it doesn’t yet support the CCC command).