Dynamic NAT Issue

[gparrish]

Has anyone seen this issue before. This is a listing from the command <sh ip nat trans | incl - >.
This will show all the static entries in the NAT translation table. The first 6 here are true static entries but the remaining 3 entries are not and these users can communicate beyond this router and out to the Internet. This is running on a 3640 with 12.2.16 code. Config is solid and NAT works for most all users without issue. Problem entries can be cleared to fix the problem but they return from random internal addresses.

Router1#sh ip nat trans | incl -
--- 206.107.104.69 10.10.0.7 --- ---
--- 206.107.104.88 10.10.0.12 --- ---
--- 206.107.104.89 10.10.0.11 --- ---
--- 206.107.104.91 10.10.0.10 --- ---
--- 206.107.104.96 10.1.1.17 --- ---
--- 206.107.104.97 10.1.10.5 --- ---
--- 206.107.104.108 10.13.0.213 --- ---
--- 206.107.104.110 10.1.9.63 --- ---
--- 206.107.104.111 10.1.1.181 --- ---

Thanks,
Greg

 

[gconnect]

do a 'show arp' on the router to see who those bogus addys belong to

are those addy's legitiment for your subnet?
do the pc's have norton antivirus installed? they may be contacting the Internet for updates.

if you have a switch in the chain reload it or flush it's arp cache

clear all nat translations (clear ip nat translation *) or better yet reload the router
clear the arp cache on the rtr

are you using windows 2000 computers?
sometimes arp entries can hang in this computers and they may have to be totally shut down and cold booted to clear it

run a sniffer (like ethereal or tcpdump) to see who is replying to the arp requests for these addresses

 

[gparrish]

Thanks for the ideas but these are not bogus addresses. These are client addresses or inside local addresses and thie dynamic NAT address or inside global address showing in the pool. The problem is these entries are displayed like they are static but they are not.

We mapped these entries back to problem users who can not get out to the internet until we clear the nat translations table. So they are all valid but just stuck so to speak. The router takes us across the wan and the arp entries map back workstation across the wan so this is all legit. It is just the correlation of these entries to the clients not being able to communicate out that is the problem. I am hoping someone has ran into this before and know what it is happening.

Thanks,
Greg

 

[sobak]

It seems to me that I remember a similar problem that I was having, I believe Cisco had me run a route-map on my NAT pool with a matching ACL. I'll try to locate more information on this for you but this happened long ago. If I can't find any of my TAC calls on it I'll show you my NAT Pool.....

david e
*end users are just like computers, some you can work with...others just need a simple reBOOTing to fix their problems.*

 

[fmonteiro]

Hi Greg,
I am sorry, but I am not sure I understood your problem. Do you mean you would like to permit access only to static NAT translation?
If this is what you want you may consider using a more restrictive access-list or nor specifying a nat pool at all.
It may help if you post your NAT related commands.

 

[gparrish]

No I am saying the router is configured for static and dynamic entries. All the static entries work fine, these are for people connecting to servers internally. The dynamic entries get hung up occassionally and can get out to the internet. When this happens the 'show ip nat trans' command shows these errant entries appearing just like they were static entries - no outside local or global addresses and this is incorrect.

Thanks,
Greg

 

[sobak]

Greg,

What I had happen happened exactly in reverse, my static entries would take on my dynamic list (I remember the situation now that you explained it). Cisco had me do this..

ip nat pool [name] 216.185.121.125 216.185.121.126 netmask 255.255.255.224
ip nat inside source route-map rmap pool [name] overload

then

route-map rmap permit 10
match ip address 120

then my ACL looked like this.


access-list 120 deny ip host 172.16.4.26 any
access-list 120 deny ip host 172.16.4.81 any
access-list 120 deny ip host 172.16.4.45 any
access-list 120 deny ip host 172.16.4.31 any
access-list 120 deny ip host 172.16.4.35 any
access-list 120 deny ip host 172.16.4.30 any
access-list 120 deny ip host 172.16.4.82 any
access-list 120 deny ip host 172.16.4.29 any
access-list 120 deny ip host 172.16.4.32 any
access-list 120 deny ip host 172.16.4.33 any
access-list 120 deny ip host 172.16.4.22 any
access-list 120 deny ip host 172.16.4.83 any
access-list 120 permit ip 172.16.0.0 0.0.255.255 any

My 172.16.4.xx numbers are my static hosts; the last entry was a catch all to force my non-static clients down the dynamic addresses. This issue resolved my static addresses problem by denying them on the dynamic pool, I believe it should do the reverse as well.


david e
*end users are just like computers, some you can work with...others just need a simple reBOOTing to fix their problems.*

 

[marsmann]

I've seen this before out in the field too.

In my case, it was like Sobak where the Static entries were hung but the dynamics were ok.

I just assumed at the time it was some kind of buffer overflow from the web and cleared transactions and wiped out the arp cache.

It never came back (yet) but now I wonder what really caused it.

Sobak, what was cisco's answer to the cause?

 

[sobak]

Marsmann,

From what I can remember (it was long ago on a different TAC contract) they really were not forthcoming with their answer. I did read in one of the IOS releases something about a fix for Static NAT entries, I think the release was 12.1 but I'd be lyin' if I said I knew that for a fact. I know after I did the above solution, I have not had any problems with my Static NATS.

david e
*end users are just like computers, some you can work with...others just need a simple reBOOTing to fix their problems.*

 

[gparrish]

Thanks David and everyone. Magically the latest code has fixed the problem, not that Cisco can give me a big on this though, yet. We were at 12.2.13, went to 12.2.16 to fix a problem with high cpu due to NAT enties taking on an expire time of 7 weeks. Finally they wanted me to try the latest 12.2.17a and it worked like a champ and the problem has been defeated. Also this is on a 3640.

Thanks again and maybe this will help others.

Greg