The problem that the Policy-based Routing affects intra-domain NAT

 The client used the USG5350 V1R3, and accessed the double-port: GigabitEthernet0/0/0：X.X.204.177/24, passed the tunnel 1. The IP of GigabitEthernet0/0/1 is X.X.38.82/24,and passed the tunnel 2. There is a vender switch 9306 accessed at the below, several network segments are in the access layer. There are two servers connected directly with the core switch, and their IP are 172.10.200.7/24 and 172.10.200.11/24 respectively.
The topology and configuraton is attached in the accessories.
The client wanted to configure the Domain NAT and let the internal network users to access the internal server through the public network. Policy-based routing and static routing are configured successfully, whereas, the domain NAT can’t take effect.

none

1. Get the USG53530 version message, detailed configuration and networking topology.
2. Check the domain NAT, and make sure it’s correct.
nat-policy zone trust  
        policy 0
        action source-nat
        address-group 0
3. Having verified, there is a default routing from the core switch to USG5350.
4. Check the Policy-based routing:
traffic classifier class1
if-match acl 3001
#
traffic behavior behavior1
  remark ip-nexthop X.X.204.1 output-interface GigabitEthernet0/0/0
#
qos policy mypolicy
classifier class1 behavior behavior1

Then, check the ACL 3001:
acl number 3001    
description celueluyou
rule 0 permit ip source 172.10.200.7 0
rule 5 permit ip source 172.10.200.11 0

As the policy-based policy, the packets whose sources are 172.10.200.7 and 172.10.200.11 all access the external network from the interface G0/0/0. As a result, when the internal PC access the server, the packets from the server are all sending to the interface G0/0/0, then the PC can’t receive them.
5. Resolving method: correct the ACL 3001, which is be used in the policy-based routing.
acl number 3001   
rule 0 deny ip destination 172.10.200.0 0.0.0.255
rule 5 deny ip destination 10.0.0.0 0.255.255.255
rule 10 deny ip destination 192.168.0.0 0.0.0.255
rule 15 permit ip source 172.10.200.7 0
rule 20 permit ip source 172.10.200.11 0
Hence, the policy-based routing will not make the packet whose destination is in the internal network sending to the external network by mistake.
When we had taken this modification, the result was satisfactorily.

1. The configuration orders of domain NAT in the USG5350 V1R3 are different from the other device, is there some wrong of user’s configuration?
2. Is there some wrong of routing?
3. Is the new version can’t be compatible?

1. The configuration of domain NAT in USG 5350 V1R3 is different from the other device, and there isn’t any example. If we configure the policy source or policy destination is any, we can’t see the configuration message by the order “dis cur”, we may wrongly guess the user’s configuration was wrong.
2. Reading the user’s configuration patiently, check that is there some relationship between the problem and the domain NAT configuration (such as the policy-based routing in this case). Don’t take the problem to the research department in a hurry.