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>

Reminder

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

upgrade

Source NAT and NAT Server Conflict When the USG5500 Implements Bidirectional NAT

Publication Date:  2015-11-02 Views:  129 Downloads:  0
Issue Description
When PC1 accesses AR1 (Untrust->Trust), the source address is translated based on nat server 2 zone trust, instead of action source-nat. Therefore, the source address is translated incorrectly.

Handling Process
Step 1 When PC1 on the Internet initiates an accesses to AR1 on the intranet (Untrust->Trust), both the source and destination addresses need translation.

Translating the source address:

nat address-group 1 192.168.17.250 192.168.17.250
nat-policy interzone trust untrust inbound
policy 0
action source-nat
address-group 1

Translating the destination address:

nat server 0 zone untrust global 10.190.17.129 inside 192.168.17.1

On PC1, ping virtual IP address 10.190.17.129. The firewall generates the following session entry. The source and destination addresses are translated correctly.

[SRG]display firewall session table
23:23:21  2015/05/19
Current Total Sessions : 5
icmp  VPN:public --> public 10.191.255.2:25685[192.168.17.250:2053]-->10.190.17
.129:2048[192.168.17.1:2048]
--------------------------------------------------------------

Step 2 When AR1 on the intranet proactively accesses PC1 on the Internet (Trust->Untrust), both the source and destination addresses need translation.

Translating the source address:

nat server 0 zone untrust global 10.190.17.129 inside 192.168.17.1 (configured. nat server 0 for the Internet to access the interanet will apply)

Translating the destination address:

nat server 2 zone trust global 192.168.17.66 inside 10.191.255.2

On AR1, ping virtual IP address 192.168.17.66. The firewall generates the following session entry. The source and destination addresses are translated correctly.

[SRG]display firewall session table
23:33:54  2015/05/19
Current Total Sessions : 1
icmp  VPN:public --> public 192.168.17.1:53675[10.190.17.129:53675]-->192.168.1
7.66:2048[10.191.255.2:2048]

Step 3 Use PC1 to access AR1 again. The firewall generates the following session entry, but the source address is incorrectly translated. nat server 2, not source nat is matched.

[SRG]display firewall session table 
23:39:14  2015/05/19
Current Total Sessions : 5 
icmp  VPN:public --> public 10.191.255.2:30236[192.168.17.66:30236]-->10.190.17 
.129:2048[192.168.17.1:2048]

----End
Root Cause
When PC1 accesses AR1, the source address preferentially matches nat server 2 zone trust global 192.168.17.66 inside 10.191.255.2. Therefore, the source address is translated to 192.168.17.66.
Solution
Add no-reverse to the nat server 2 zone trust global 192.168.17.66 inside 10.191.255.2 command, so that when PC1 initiates an access to the intranet, the source address preferentially matches action source-nat instead of nat server 2. Then the source address can be translated to IP address 192.168.17.250 in the NAT address pool.

END