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>


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


USG2210 double export do port mapping, the return path is not consistent

Publication Date:  2012-11-26 Views:  492 Downloads:  0
Issue Description

Networking description:
G0/0/0 is Unicom link address
G0/0/1 is telecom link address
The 8008 port of Unicom address and telecom address respectively mapping the 8008 port of internal server
Unicom users through Unicom address access, telecom user through the telecom address access.
Customer equipment is used as the up export link, NAT server configuration is as follows:
nat server 14 protocol tcp global 8008 inside 8008 no-reverse
nat server 15 protocol tcp global  8008 inside 8008 no-reverse
ip route-static GigabitEthernet0/0/0
ip route-static GigabitEthernet0/0/1
Through the 8008 port of telecom address can visit internal server, but through the unicom address can't visit.

Alarm Information
Handling Process
USG2200-hidecmd]display firewall session table verbose_hide both-direction sour
ce global
tcp  VPN:public --> public                                                  
  Zone: untrust--> trust  TTL: 00:00:05  Left: 00:00:03                       
  Interface: Vlanif1  NextHop:  MAC: 80-fb-06-b0-0d-4d             
  <--packets:0 bytes:0   -->packets:1 bytes:60                         >[]                    
  tcp  VPN:public --> public                                                  
  Zone: trust--> untrust  TTL: 00:00:05  Left: 00:00:03                       
  Interface: GigabitEthernet0/0/0  NextHop:  MAC: 00-e0-fc-65-0c-01
  <--packets:0 bytes:0   -->packets:1 bytes:64                         []-->

Through the above command we can see:
When access, message enters from the interface GigabitEthernet0/0/1 (unicom interface), the return message is sent from GigabitEthernet0/0/0 (telecom interface), upstream router will discard this kind of message if opened URPF (strictly routing check).
acl number 3010
rule 15 permit ip source 0
acl number 3011
rule 15 permit ip source 0
Now from the external network through the Unicom and telecom address all can access, but from the inside through the public network address can’t access, and in equipment can’t ping the address of server. Let's look at domain NAT:
nat-policy zone trust
policy 1
action source-nat
policy source
policy destination 0
policy destination 0
address-group 3
The domain NAT has no problem, so the problem is in policy-based routing, because policy-based routing has the first priority, when returning the package, it will also match policy-based routing and directly forward out from the external network interface. At this time we need to deny the policy-based routing. Configuration is as follows:

acl number 3010
rule 0 deny ip destination
rule 1 deny ip destination 0
rule 2 deny ip destination 0
rule 3 deny ip destination 0
rule 5 permit ip source 0

acl number 3011
rule 0 deny ip destination
rule 1 deny ip destination 0
rule 2 deny ip destination 0
rule 3 deny ip destination 0
rule 5 permit ip source 0
Root Cause
1, telecom address can access, namely the address of the server can be reached.
2, in the external network can Telnet the 8008 port of unicom address, and when through the unicom address access, there is session, namely the mapping has no problem.
3, suspect may be port problems, replace the 8008 into other ports, such as port 10000, but still can’t access.
4, problems may be the return path is not consistent, it has appeared similar case before.
When the double export link did port mapping, upstream router opened URPF (strictly routing checking). If the path didn’t consistent, it would lose message, leading to some ports can’t access, it is suggested that using the above methods to solve, at the same time need to pay attention to the configuration of the policy-based routing.