LAN to internet trace failing but LAN can access internet

[jasonww04]

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.

[Peter Paluch]

Hi Jason,

A couple of questions:

1. Did the traceroute ever work before?
2. When you perform a traceroute from the router's command line itself, does it work correctly?
3. When the traceroute is performed from a LAN station, does the traceroute run from this station list at least your router?

Thank you!

Best regards,

Peter

[jasonww04]

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.

[Peter Paluch · Accepted solution]

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

[jasonww04]

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.

[Peter Paluch]

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

[jasonww04]

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.

[zulqurnain]

Hi,

this is a known issue with NAT.

removing or clearing it just makes it work.