cleanning up crazy inside nat list

Sep 08, 2005 4 Replies

Most of my router have deny for all the other remote subnets in my network. They also have a permit for the nat subnet in the router's subnet. Do I need all this deny statements? or is the permit statement enought? I will have to add a few statements because we added a couple of routers and they are not listed in this access-list. Everywhere i am looking on the internet in only shows a permit statement for the subnet inside the router. Can anyone clarify this?. this is my nat inside list


access-list 100 deny ip 10.x.y.0 0.0.0.255 10.x.10.0 0.0.0.255 access-list 100 deny ip 10.x.y.0 0.0.0.255 10.x.20.0 0.0.0.255 access-list 100 deny ip 10.x.y.0 0.0.0.255 10.x.30.0 0.0.0.255 access-list 100 permit ip 10.x.y.0 0.0.0.255 any access-list 100 deny ip host 10.x.y.17 any access-list 100 permit ip host 10.x.y.17 any



In article , wrote: :Most of my router have deny for all the other remote subnets in my :network. They also have a permit for the nat subnet in the router's :subnet. Do I need all this deny statements? or is the permit statement :enought? I will have to add a few statements because we added a couple :of routers and they are not listed in this access-list. Everywhere i am :looking on the internet in only shows a permit statement for the subnet :inside the router. Can anyone clarify this?. this is my nat inside list

:access-list 100 deny ip 10.x.y.0 0.0.0.255 10.x.10.0 0.0.0.255 :access-list 100 deny ip 10.x.y.0 0.0.0.255 10.x.20.0 0.0.0.255 :access-list 100 deny ip 10.x.y.0 0.0.0.255 10.x.30.0 0.0.0.255 :access-list 100 permit ip 10.x.y.0 0.0.0.255 any

If you were to remove those first 3 deny's, then you would end up NAT'ing the traffic going to your other remote subnets, but your VPN is expecting internal IP ranges.

:access-list 100 deny ip host 10.x.y.17 any :access-list 100 permit ip host 10.x.y.17 any

host 10.x.y.17 is part of 10.x.y.0 0.0.0.255 so the permit of

10.x.y.0 0.0.0.255 to any will be processed (because it is higher in the list) and permit the NAT, with the ACL search not getting as far as the deny of host 10.x.y.17 to any (or the subsequent permit of host 10.x.y.17 to any). Those last two lines are not doing you any good.

Hi,

Usually the deny entries in a NAT access-list are used in conjunction with VPN configurations exluding the specific traffic from being NAT'ed across the VPN tunnels.

However there might be more specific reasons in your case as to deny specific hosts internet access or atleast not NAT them so they won't be translated.

The last 2 lines in the access-list from what I can see are pretty much useless.

First it permits 10.x.y.* to anywhere, then it denies 10.x.y.17 which is already permitted, then it permits 10.x.y.17.

First review whether you have any VPN's configured and then redo the access-list accordingly. Access-lists are processed top to bottom. If you need to block/not translate the 10.x.y.17 host and have VPN's setup then your access-list should look something like this:

access-list 100 deny ip 10.x.y.0 0.0.0.255 10.x.10.0 0.0.0.255 access-list 100 deny ip 10.x.y.0 0.0.0.255 10.x.20.0 0.0.0.255 access-list 100 deny ip 10.x.y.0 0.0.0.255 10.x.30.0 0.0.0.255 access-list 100 deny ip host 10.x.y.17 any access-list 100 permit ip 10.x.y.0 0.0.0.255 any

Hope this helps,

Rob

Thanks, I dont know what host 17 is so i will delete that rule. I have several crypto maps with other remote office and vpn comin in in the main office. I guess Ill update the denies. I have tunels to 10.x.10.0 and 10.x.20.0 but i dont have a tunel to 10.x.30.0, will it be bad if I add denies to subnets witch dont have tunnels like 10.x.30.0?

Do you have a host .17? Ping return anything?

If you don't have a 10.x.30.0 subnet then simply don't include it in the access-list.

NAT access-lists with deny statements do not deny traffic they simply don't NAT that traffic.

This should be sufficient. access-list 100 deny ip 10.x.y.0 0.0.0.255 10.x.10.0 0.0.0.255 access-list 100 deny ip 10.x.y.0 0.0.0.255 10.x.20.0 0.0.0.255 access-list 100 permit ip 10.x.y.0 0.0.0.255 any

Rob

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required