NAT Server Mapping Failures on the USG

Publication Date:  2015-11-03 Views:  770 Downloads:  0
Issue Description
This document summarizes NAT server mapping failures on USG firewalls and the solutions. In scenarios described in this document, the configurations are all correct.
Handling Process
A customer has a server. The private IP address is 192.168.1.100, and the public IP address is 1.1.1.1. On the firewall, the server mapping is configured as follows:

nat Server  10 protocol tcp global  1.1.1.1 80 inside 192.168.1.100 80

Fault 1: The firewall does not have any policy that permits packets.

Symptom: The access fails, and no session is displayed on the firewall.

View the session table. The following information is displayed:
           display firewall session table verbose  destination inside 192.168.1.100
             Current Total Sessions : 0

Solution: Configure a policy in the interzone to permit packets destined to the server.

Fault 2: The carrier disables a port.

Symptom: The access fails, and no session is displayed on the firewall.

Solution: Contact the carrier.

Fault 3: No gateway is specified for the server, or the intranet route is incorrect.

Symptom: The access fails, and only the forward session is displayed on the firewall.

View the session table. The following information is displayed:
           display firewall session table verbose destination inside 192.168.1.100
           Current Total Sessions : 1
            telnet  VPN:public --> public
            Zone: untrust--> trust TTL: 00:00:00  Left: 00:00:10
           Output-interface: GigabitEthernet0/0/1    NextHop: 192.168.1.100  MAC: xx-xx-xx-xx
           <--packets:445 bytes:20841   -->packets:0 bytes:0
           x.x.x.x:56221-->1.1.1.1:80[192.168.1.100:80]

Solution 1: Set a gateway for the server or rectify the route fault.

Solution 2: If the route is correct and the server cannot be configured for some reason, enable NAT on the LAN interface to translate the public IP addresses of packets to a private IP address.

Fault 4: Some special applications have access anomalies. For example, the FTP server can be logged in, but the resources are inaccessible.


Symptom: Some special applications have access anomalies. For example, the FTP server can be logged in, but the resources are inaccessible. The session information is correct, and the session has both forward and return data.

Solution: Enable NAT ALG in the interzone.

The command is as follows:
                 firewal interzone trunst untrust
                 detect ftp

Note: Fault 4 can be referenced to resolve both PPTP and SIP faults.

Fault 5: In dual-link scenarios, the sticky load balancing function causes access failures.

Symptom: A customer maps a server to two interfaces. Sometimes, the access succeeds, but sometimes the access fails. When the access fails, the firewall has only forward session data.

Solution: Upgrade the USG to a version later than V300R001C00SPC700 because earlier versions do not provide the sticky load balancing function.
Suggestions
The most effective method to resolve a server mapping failure is to view the session status.

1. If no session is displayed, the policy action might be deny or the carrier has disabled the port.

2. If the session has only forward data, the intranet server is faulty, or the route is incorrect.

3. If the session has both forward and return data but the access fails, the application might be special.

END