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

Networking:

Networking description:
G0/0/0 is Unicom link address 58.23.90.58
G0/0/1 is telecom link address 121.205.3.126
The 8008 port of Unicom address and telecom address respectively mapping the 8008 port of internal server
Requirements:
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 121.205.3.126 8008 inside 10.1.11.206 8008 no-reverse
nat server 15 protocol tcp global 58.23.90.58  8008 inside 10.1.11.206 8008 no-reverse
ip route-static 0.0.0.0 0.0.0.0 GigabitEthernet0/0/0 121.205.3.1
ip route-static 0.0.0.0 0.0.0.0 GigabitEthernet0/0/1 58.23.90.57
Through the 8008 port of telecom address 121.205.3.126 can visit internal server, but through the unicom address 58.23.90.58 can't visit.

None.

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

Through the above command we can see:
When access 58.23.90.58:8008, 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 10.1.11.206 0
acl number 3011
rule 15 permit ip source 10.1.11.106 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 10.1.0.0 0.0.255.255
policy destination 121.205.3.126 0
policy destination 58.23.90.58 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 10.1.0.0 0.0.255.255
rule 1 deny ip destination 10.1.100.2 0
rule 2 deny ip destination 1.1.1.1 0
rule 3 deny ip destination 1.1.1.2 0
rule 5 permit ip source 10.1.11.206 0

acl number 3011
rule 0 deny ip destination 10.1.0.0 0.0.255.255
rule 1 deny ip destination 10.1.100.2 0
rule 2 deny ip destination 1.1.1.1 0
rule 3 deny ip destination 1.1.1.2 0
rule 5 permit ip source 10.1.11.106 0

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.