cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
567
Views
0
Helpful
7
Replies

Outside NAT to pool malfunction ?

All,

I've configured a outside-to-inside nat as follwing:

interface FastEthernet0/0

ip nat inside

!

interface FastEthernet1/0

ip nat outside

!

ip nat pool pool-TSI2ARCOR 10.192.48.1 10.192.63.254 netmask 255.255.240.0

ip nat outside source list 2004 pool pool-TSI2ARCOR

!

access-list 2004 permit tcp 10.144.255.128 0.0.0.31 gt 0 10.14.0.0 0.0.0.255 gt 0

access-list 2004 permit tcp 10.144.255.128 0.0.0.31 gt 0 10.14.5.0 0.0.0.255 gt 0

access-list 2004 permit tcp 10.144.255.128 0.0.0.31 gt 0 10.14.6.0 0.0.0.255 gt 0

access-list 2004 permit tcp 10.144.255.128 0.0.0.31 gt 0 10.14.7.0 0.0.0.255 gt 0

Every works fine until the first packet arrives which match to the acl 2004. From this time every traffic from outside to inside is natted (and also a net entry exist within the translation table). It seems that the extended acl ist used as a standard acl.

The IOS Version is 12.3(10).

HELP !!!!

7 Replies 7

a.awan
Level 4
Level 4

This is normal behavior when you use access-lists with NAT. The reason is that the router creates a simple translation based on the ACL. This simple translation will only have (in your case) the outside local and outside global addresses mapped to eachother for all inside addresses. Therefore, once the the translation is created for an outside address all traffic sourced from that address will be NATTED as the router will not even consider the ACL once it sees a valid translation in the NAT table. The workaround is to use route-maps. Change your configuration to:

no ip nat outside source list 2004 pool pool-TSI2ARCOR

route-map nat permit 10

match ip address 2004

ip nat outside source route-map nat pool pool-TS12ARCOR

clear ip nat translations *

Try this out and let us know if you have any issues.

Hi,

thanks for responose but this is what I've tried before.

If you look at it carefully it is not the same configuration. In the configuration i sent i am using route-maps that in turn use access-lists. Read the following article for details in case you want to understand the difference between using a list directly or using it via a route-map:

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080093fca.shtml

Hi,

sorry, I've tried it whith route-maps but it was the same behavior. Route-maps work fine from inside to outside but not from outside to inside.

Thanks for clarifying that. I do not see why it should be any different for outside to inside with route-maps. If it is indeed happening as you are describing then i do not know how to circumvent this. Can you post the exact configuration you have tried with route-maps that did not work? Try to post the show ip nat translations (normal and detailed version).

Can anyone test this quickly with a couple of lab routers?

Here it is:

access-list 2004 permit ip 10.144.255.128 0.0.0.31 10.14.0.0 0.0.0.255

access-list 2004 permit ip 10.144.255.128 0.0.0.31 10.14.5.0 0.0.0.255

access-list 2004 permit ip 10.144.255.128 0.0.0.31 10.14.6.0 0.0.0.255

access-list 2004 permit ip 10.144.255.128 0.0.0.31 10.14.7.0 0.0.0.255

route-map map-TSI2ARCOR permit 10

match ip address 2004

exit

ip nat pool pool-TSI2ARCOR 10.193.0.1 10.193.255.254 prefix-length 16

ip nat outside source route-map map-TSI2ARCOR pool pool-TSI2ARCOR

Looks good. With this configuration do a clear ip nat translations * and then initiate the traffic and post the resulting show ip nat translation output.