Problem on 1720 with overload nat

Hi everyone,

I have a problem on a 1720 with the IOS 12.0(3)T. It is connected to two private networks (192.168.X.X and 10.Y.Y.Y), correctly configured on the two network interfaces. I have implemented an nat pool to translate all

192.168.X.X IP addresses on connections going to 10.Y.Y.Y to source address 10.208.7.15 and four static nat allowing 10.Y.Y.Y to access four different servers on 192.168.X.X network. The problem is that the router is working ok after reload for a certain time (I think about 24 hours, altough not sure yet about the lapse of time), changing correctly all 192.168.X.X to the IP address indicated for the pool. After that time it will continue to work, but translating all 192.168.X.X addresses to one of the IP addresses used in the static nat for one fo the four servers. This is efectivelly blocking the communications, since at the other side the firewall is blocking connections that don't have the IP source address the indicate in the nat pool :( Configuration indicate below:

interface Ethernet0 ip address 10.208.7.110 255.255.255.128 no ip redirects no ip directed-broadcast no ip proxy-arp ip nat outside no ip route-cache no ip split-horizon no cdp enable ! interface Ethernet1 ip address 192.168.10.155 255.255.255.0 no ip redirects no ip directed-broadcast no ip proxy-arp ip nat inside ip inspect fw in no ip route-cache no ip split-horizon no cdp enable ! ip nat translation timeout 900 ip nat pool uscita_banca 10.208.7.15 10.208.7.15 prefix-length 25 ip nat inside source list 9 pool uscita_banca overload ip nat inside source static 192.168.10.98 10.208.7.14 ip nat inside source static 192.168.10.221 10.208.7.13 ip nat inside source static 192.168.10.153 10.208.7.12 ip nat inside source static 192.168.10.151 10.208.7.11 ip nat inside source static 192.168.10.150 10.208.7.10 ip classless ip route 0.0.0.0 0.0.0.0 192.168.10.1 ip route 10.0.0.0 255.0.0.0 10.208.7.126 no ip http server

................. access-list 9 permit 192.168.0.0 0.0.255.255

That's the relevant configuration information. Problem observed:

show ip nat trans -> indicate soon after reload that a TCP connection going from

192.168.10.2 to 10.210.15.200 is translated as source address to 10.208.7.15 -> after the problem arise indicate the same connection (a new one, but done from the same computer to the same destination) that the translation uses 10.208.7.13 (which is correctly blocked by the 10.208.7.126 router that provides links to the 10.Y.Y.Y networks).

Has anyone any idea of the reason why the NAT seems not to use anymore the correct IP (10.208.7.15) as indicated in the pool and starts using the

10.208.7.13 indicated in the static nat for one of the servers inside? Is that a bug specific to this 12.0(3)T IOS release?

Thanks a lot, Florin Bota.

Reply to
Florin Bota
Loading thread data ...

Your dynamic nat pool access-list should include DENY entries for the systems that have static NAT addresses specified.

access-list 9 deny 192.168.10.98 access-list 9 deny 192.168.10.221 access-list 9 deny 192.168.10.153 access-list 9 deny 192.168.10.151 access-list 9 deny 192.168.10.150 access-list 9 permit 192.168.0.0 0.0.255.255

I haven't seen this method in cisco documentation, but I had a similar problem years ago and Cisco TAC recommended that I implement DENY statements to resolve it. It worked for me.

Reply to
jdsal

Thanks a lot, i implemened the deny entries indicated by tou and now hope not to have other problems. Anywhere I found a Cisco bug risolved in IOS release 12.1(5)T:

CSCdp27155 IP Network Address Translation (NAT) fails to use addressed from the defined pool. Instead, it uses an address that was already used for static mapping. There is no workaround.

I think this might apply to my case (since after a certain amount of time my router starts using the 10.208.7.13 IP address for NAT, instead of the one indicated in the pool... I'll wait to see if the deny entries will solve the problem, otherwise I will probably have to upgrade to a more recent IOS.

Thanks a lot, Florin Bota.

"jdsal" ha scritto nel messaggio news:48GdnQYnfscwmTzenZ2dnUVZ snipped-for-privacy@comcast.com...

192.168.X.X
Reply to
Florin Bota

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.