Troubleshooting Policy Routing and NAT Redirection Issue on AR2240 Interface GE0/0/0
This article details a troubleshooting case on an AR2240 device where policy routing and NAT redirection prevented an internal host from reaching a server via a public IP, explains the root cause of missing ACL rules, and provides the configuration changes that resolved the issue.
The AR2240 internal interface GE0/0/0 was configured with a policy route that caused internal user HostA to be unable to access an internal server via the public address 112.64.180.10; removing the policy route restored connectivity.
Alarm information : HostA could not ping the server's public IP address.
Processing steps :
Step 1 – Display current configuration and examine the policy routing settings. The configuration showed that traffic from the internal network to the public address 112.64.180.10 was exempted from redirection:
acl number 2000<br/>rule 10 permit source 192.168.0.0 0.0.0.255<br/>acl number 2999<br/>rule 5 permit<br/>acl number 3001<br/>rule 11 permit ip source 192.168.0.0 0.0.255.255 destination 112.64.180.10 0<br/>traffic classifier vlan11 operator or<br/>if-match acl 3001<br/>traffic classifier vlan10 operator or<br/>if-match acl 2000<br/>traffic behavior vlan11<br/>traffic behavior vlan10<br/>redirect ip-nexthop 112.64.180.9<br/>traffic policy vlan10<br/>classifier vlan11 behavior vlan11<br/>classifier vlan10 behavior vlan10<br/>Interface GigabitEthernet0/0/0<br/>ip address 172.16.100.1 255.255.255.0<br/>traffic-policy vlan10 inbound<br/>nat server protocol tcp global interface GigabitEthernet0/0/2 www inside 192.168.0.140 www<br/>interface GigabitEthernet0/0/2<br/>description LianTong<br/>ip address 112.64.180.10 255.255.255.252<br/>nat server protocol tcp global current-interface www inside 192.168.0.140 www<br/>nat outbound 2999Step 2 – Trace the ping process from HostA to the server:
First stage (client → server): Source Destination 192.168.1.100 112.64.180.10 192.168.1.100 192.168.0.140 // NAT translation 172.16.100.1 // NAT translation 192.168.0.140
Second stage (server → client): Source Destination 192.168.0.140 172.16.100.1 // No matching ACL 3001, redirected 192.168.0.140 192.168.1.100 // NAT translation 112.64.180.10 // NAT translation 192.168.1.100
Root cause : During the second stage, the server’s response to the client did not match ACL 3001, causing the traffic to be redirected incorrectly.
Solution : Add a rule to ACL 3001 to exempt traffic from the internal network to the public address 172.16.100.1, preventing redirection:
acl number 3001<br/>rule 11 permit ip source 192.168.0.0 0.0.255.255 destination 112.64.180.10 0<br/>rule 12 permit ip source 192.168.0.0 0.0.255.255 destination 172.16.100.1 0 // added rule for internal‑to‑public trafficAfter applying the new configuration, the issue was resolved and HostA could successfully ping the server via the public IP.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Practical DevOps Architecture
Hands‑on DevOps operations using Docker, K8s, Jenkins, and Ansible—empowering ops professionals to grow together through sharing, discussion, knowledge consolidation, and continuous improvement.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
