07-16-2012 08:50 AM - edited 03-04-2019 04:59 PM
I'm having such a weird issue. Any device on the LAN, including the router's interface, show nothing but stars for all intermediate hops in a trace route. The weird part is that all devices on the LAN can reach the target of the trace via RDP, HTTP, HTTPS, ping, telnet, etc. It's like every trace is going through a VPN, even when it is actually going to a random internet address.
I've attached my config.
Solved! Go to Solution.
07-17-2012 01:06 PM
Hello Jason,
This is interesting. So far, I have no clear idea why this happens but for some reason, this seems like a problem related to NAT.
I have noticed that in your configuration, you are using a route-map to control the NAT process. However, this route-map merely references an extended ACL, and therefore, it is an unnecessary complication of the configuration. There may be a subtle difference in how IOS performs the NAT if controlled by ACL and by a route-map. My suggestion - a blind shot - is therefore to remove the line
ip nat inside source route-map NAT pool NAT overload
and replace it with
ip nat inside source list NAT pool NAT overload
Can you give it a try? Thank you!
Best regards,
Peter
07-16-2012 09:22 AM
Hi Jason,
A couple of questions:
Thank you!
Best regards,
Peter
07-16-2012 11:58 AM
1. I'm not sure if it ever worked before.
2. trace from the router's cli works only if I don't source it from the LAN interface. trace 63.123.252.1 works but the following does not:
trace
63.123.252.1
172.18.113.1
3. the router's LAN interface is always included in the traces from workstations but that's the only IP until the target is reached.
07-17-2012 01:06 PM
Hello Jason,
This is interesting. So far, I have no clear idea why this happens but for some reason, this seems like a problem related to NAT.
I have noticed that in your configuration, you are using a route-map to control the NAT process. However, this route-map merely references an extended ACL, and therefore, it is an unnecessary complication of the configuration. There may be a subtle difference in how IOS performs the NAT if controlled by ACL and by a route-map. My suggestion - a blind shot - is therefore to remove the line
ip nat inside source route-map NAT pool NAT overload
and replace it with
ip nat inside source list NAT pool NAT overload
Can you give it a try? Thank you!
Best regards,
Peter
07-17-2012 01:25 PM
I'll try it but years ago a Cisco tech told me it is better to use route-maps in your NAT overload statement, even if it does just reference an ACL.
07-17-2012 05:38 PM
Hi Jason,
I'll try it but years ago a Cisco tech told me it is better to use route-maps in your NAT overload statement, even if it does just reference an ACL.
That was perhaps a best practice configuration style but I would personally challenge it. It is about using an additional level of indirection (a route-map referencing an ACL instead of referencing the ACL directly) without any particular need to have that indirection in place.
Best regards,
Peter
07-18-2012 10:57 AM
Last night I tried changing the NAT statement and even though I cleared the NAT translations a dozen times, it wouldn't let me remove the statement. Today, the customer told me everything is working as it should. So while it does seem the problem was with the NAT, apparently clearing the established NATs fixed the problem.
07-18-2012 12:04 PM
Hi,
this is a known issue with NAT.
removing or clearing it just makes it work.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide