standard vs extended acl issue

azaghul

Have just been reworking my lab & home networks, and have come across an ACL "gotcha" with standard vs extended. I usually use a standard ACL for NAT applied on my 877 ADSL router without issue, but adding the permit 10 & 172 super-nets causes lab traffic to be dropped. I've replicated it in GNS3 using 3725's.

[FONT=courier new]ip access-list standard STD-NAT-ACCESS
 remark HOME NETWORK ACCESS
 permit 192.168.1.0 0.0.0.255
 remark LAB NETWORK ACCESS
 permit 172.0.0.0   0.255.255.255 log
 permit 10.0.0.0    0.255.255.255 log
 remark BLOCK UNMATCHED
 deny   any log <- 10 and 172 traffic dropped here[/FONT]

An extended ACL allows 172 & 10 ranges,

[FONT=courier new]ip access-list extended EXT-NAT-ACCESS
 remark HOME NETWORK ACCESS
 permit ip 192.168.1.0 0.0.0.255     any log
 remark LAB NETWORK ACCESS
 permit ip 172.0.0.0   0.255.255.255 any log <- pass ok
 permit ip 10.0.0.0    0.255.255.255 any log[/FONT][FONT=courier new] <- pass ok[/FONT]
[FONT=courier new] remark BLOCK UNMATCHED
 deny   ip any                       any log[/FONT]

Its probably staring me in the face, as an ACL should only act on a match or keep looking down the list, so shouldn't the standard ACL work?

What am I missing here?

NetworkVeteran

It appears NAT is working with numbered ACLs but not with named ACLs, though IOS 12.4T claims to support both. Any other eyes want to check this over?

It's okay. I'm far from a NAT expert. I won't be offended.

R4#sh run | inc nat
ip nat inside
ip nat outside
ip nat inside
ip nat pool myPool 150.1.41.10 150.1.41.19 netmask 255.255.255.0
ip nat inside source list STD-NAT-ACCESS pool myPool

R4#clear access-list count

R4#! pinging from 172.16.1.5 => 1.1.1.1 (failed)

R4#show access-list
Standard IP access list 7
10 permit 192.168.1.0, wildcard bits 0.0.0.255
20 permit 172.0.0.0, wildcard bits 0.255.255.255
30 permit 10.0.0.0, wildcard bits 0.255.255.255
40 deny any
Standard IP access list STD-NAT-ACCESS
10 permit 192.168.1.0, wildcard bits 0.0.0.255
20 permit 172.0.0.0, wildcard bits 0.255.255.255 log
30 permit 10.0.0.0, wildcard bits 0.255.255.255 log
40 deny any log (2 matches)
Standard IP access list TESTING

R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#ip nat inside source list 7 pool myPool
R4(config)#end
R4#
*Mar 1 00:27:58.387: %SYS-5-CONFIG_I: Configured from console by console

R4#! Pinging from 172.16.1.5 => 1.1.1.1 (success!)

R4#show access-list
Standard IP access list 7
10 permit 192.168.1.0, wildcard bits 0.0.0.255
20 permit 172.0.0.0, wildcard bits 0.255.255.255 (6 matches)
30 permit 10.0.0.0, wildcard bits 0.255.255.255
40 deny any (2 matches)
Standard IP access list STD-NAT-ACCESS
10 permit 192.168.1.0, wildcard bits 0.0.0.255
20 permit 172.0.0.0, wildcard bits 0.255.255.255 log
30 permit 10.0.0.0, wildcard bits 0.255.255.255 log
40 deny any log (4 matches)
Standard IP access list TESTING

Note, those 4 matches of STD-NAT-ACCESS were not from the pings (which send 5 packets), but rather from locally sourced traffic. STD-NAT-ACCESS is not matching anything at all.

*Mar 1 00:29:03.043: %SEC-6-IPACCESSLOGNP: list STD-NAT-ACCESS denied 0 150.1.41.4 -> 0.0.0.0, 4 packets

PS - I tried the OP's scenario with numbered ACLs, because that's what I usually use successfully.

PSS - OP, remember to include the lines where you apply an ACL when debugging.

drkat

I guess I'm confused on what's happening.. the standard ACL matches source only addresses while the extended is source+destination

so given you example:


ip access-list standard STD-NAT-ACCESS
remark HOME NETWORK ACCESS
permit 192.168.1.0 0.0.0.255
remark LAB NETWORK ACCESS
permit 172.0.0.0 0.255.255.255 log
permit 10.0.0.0 0.255.255.255 log
remark BLOCK UNMATCHED
deny any log <- 10 and 172 traffic dropped here

I'm gonna assume you're not sourcing your traffic from 172.0.0.0/8 but from another network

Did we debug nat on this? I dont use GNS so I cant lab this so I'll play devils advocate - not unless the sourced supernet is causing an issue with the ACL..

debug ip packet detail <access-list> gives what?

NetworkVeteran

drkat wrote: »

I guess I'm confused on what's happening.. the standard ACL matches source only addresses while the extended is source+destination

drkat, see my post above, which shows what happens to packets from 172.x.x.x and much more show/debug output. The no-translation thing happens when a named standard ACL is used but not when a numbered standard ACL is used. Fishy! See anything interesting?

NetworkVeteran

4#! ping to 1.1.1.1 with numbered ACL
R4#
*Mar 1 00:09:55.995: mapping pointer available mapping:0
*Mar 1 00:09:55.999: NAT*: i: icmp (172.16.1.5, 43827) -> (1.1.1.1, 43827) [13227]
*Mar 1 00:09:56.003: NAT*: i: icmp (172.16.1.5, 43827) -> (1.1.1.1, 43827) [13227]
*Mar 1 00:09:56.003: NAT*: s=172.16.1.5->150.1.41.10, d=1.1.1.1 [13227]
*Mar 1 00:09:56.011: NAT: installing alias for address 150.1.41.10
R4#
*Mar 1 00:09:58.011: NAT*: i: icmp (172.16.1.5, 44339) -> (1.1.1.1, 44339) [13228]
*Mar 1 00:09:58.015: NAT*: i: icmp (172.16.1.5, 44339) -> (1.1.1.1, 44339) [13228]
*Mar 1 00:09:58.015: NAT*: s=172.16.1.5->150.1.41.10, d=1.1.1.1 [13228]
*Mar 1 00:09:58.031: IP: s=150.1.41.1 (FastEthernet0/1), d=150.1.41.4, len 59, rcvd 0
*Mar 1 00:09:58.031: IP: tableid=0, s=150.1.41.4 (local), d=150.1.41.1 (FastEthernet0/1), routed via FIB
*Mar 1 00:09:58.035: IP: s=150.1.41.4 (local), d=150.1.41.1 (FastEthernet0/1), len 59, sending
*Mar 1 00:09:58.043: NAT*: o: icmp (1.1.1.1, 44339) -> (150.1.41.10, 44339) [13228]
R4#
*Mar 1 00:09:58.043: NAT*: s=1.1.1.1, d=150.1.41.10->172.16.1.5 [13228]
*Mar 1 00:09:58.275: IP: s=150.1.41.1 (FastEthernet0/1), d=150.1.41.4, len 40, rcvd 0
R4#
*Mar 1 00:09:59.051: NAT*: i: icmp (172.16.1.5, 44595) -> (1.1.1.1, 44595) [13229]
*Mar 1 00:09:59.055: NAT*: i: icmp (172.16.1.5, 44595) -> (1.1.1.1, 44595) [13229]
*Mar 1 00:09:59.055: NAT*: s=172.16.1.5->150.1.41.10, d=1.1.1.1 [13229]
*Mar 1 00:09:59.071: NAT*: o: icmp (1.1.1.1, 44595) -> (150.1.41.10, 44595) [13229]
*Mar 1 00:09:59.071: NAT*: s=1.1.1.1, d=150.1.41.10->172.16.1.5 [13229]
R4#
*Mar 1 00:10:00.095: NAT*: i: icmp (172.16.1.5, 44851) -> (1.1.1.1, 44851) [13230]
*Mar 1 00:10:00.095: NAT*: i: icmp (172.16.1.5, 44851) -> (1.1.1.1, 44851) [13230]
*Mar 1 00:10:00.095: NAT*: s=172.16.1.5->150.1.41.10, d=1.1.1.1 [13230]
*Mar 1 00:10:00.115: NAT*: o: icmp (1.1.1.1, 44851) -> (150.1.41.10, 44851) [13230]
*Mar 1 00:10:00.115: NAT*: s=1.1.1.1, d=150.1.41.10->172.16.1.5 [13230]
R4#
*Mar 1 00:10:01.135: NAT*: i: icmp (172.16.1.5, 45107) -> (1.1.1.1, 45107) [13231]
*Mar 1 00:10:01.139: NAT*: i: icmp (172.16.1.5, 45107) -> (1.1.1.1, 45107) [13231]
*Mar 1 00:10:01.139: NAT*: s=172.16.1.5->150.1.41.10, d=1.1.1.1 [13231]
*Mar 1 00:10:01.155: NAT*: o: icmp (1.1.1.1, 45107) -> (150.1.41.10, 45107) [13231]
*Mar 1 00:10:01.155: NAT*: s=1.1.1.1, d=150.1.41.10->172.16.1.5 [13231]
R4#
R4#
R4#
R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#no ip nat inside source list 7 pool myPool
Dynamic mapping in use, do you want to delete all entries? [no]: yes
R4(config)#
*Mar 1 00:10:22.951: NAT: no portlist for proto 1 globaladdr 150.1.41.10 port 43827
*Mar 1 00:10:22.955: NAT: no portlist for proto 1 globaladdr 150.1.41.10 port 44339
*Mar 1 00:10:22.955: NAT: no portlist for proto 1 globaladdr 150.1.41.10 port 44595
*Mar 1 00:10:22.955: NAT: no portlist for proto 1 globaladdr 150.1.41.10 port 44851
*Mar 1 00:10:22.955: NAT: no portlist for proto 1 globaladdr 150.1.41.10 port 45107
*Mar 1 00:10:22.955: NAT: deleting alias for 150.1.41.10
*Mar 1 00:10:22.955: NAT: deleting alias from redundancy list for 150.1.41.10
R4(config)# ip nat inside source list STD-NAT-ACCESS pool myPool
R4(config)#e
*Mar 1 00:10:34.911: ipnat_add_dynamic_cfg_common: id 3, flag 5, range 1
*Mar 1 00:10:34.911: id 3, flags 0, domain 0, lookup 0, aclnum 0, aclname STD-NAT-ACCESS, mapname idb 0x00000000
*Mar 1 00:10:34.911: poolstart 150.1.41.10 poolend 150.1.41.19
R4(config)#end
R4#
R4#
*Mar 1 00:10:36.931: %SYS-5-CONFIG_I: Configured from console by console
R4#! ping 1.1.1.1 again with named ACL
R4#

NetworkVeteran

Gadzooks! I got it. It's actually the log statements causing problems!

I got it to work when I changed it as follows--

Standard IP access list STD-NAT-ACCESS
10 permit 192.168.1.0, wildcard bits 0.0.0.255
20 permit 172.0.0.0, wildcard bits 0.255.255.255
30 permit 10.0.0.0, wildcard bits 0.255.255.255
40 deny any

And here's the explanation--

Cisco Website wrote:

Does Cisco IOS NAT support ACLs with a "log" keyword?

A. When you configure Cisco IOS NAT for dynamic NAT translation, an ACL is used to identify packets that can be translated. The current NAT architecture does not support ACLs with a "log" keyword.

networker050184

Quite the detective work there NetworkVeteran!

azaghul

Pics make it easier...

I'm not the NAT expert either, its something you setup, get working and forget about.

All routers and PC can ping each other, all but BR1 can ping the Internet using the STD-NAT-ACCESS. HQ and BR1 (and others not shown) are part of the lab network, HQ bridges the 2 networks.

In GNS3 I'm running 12.4T on a 3725, at home I'm running 15.1M on the 877. The only reason I changed to extended ACL was (from my reading) it gives more logging details.


Extra Janus code:

[FONT=courier new]interface FastEthernet0/0
 description TO INTERNET
 ip address 220.233.x.x 255.255.255.252
 ip nat outside
 ip virtual-reassembly
 speed 100
 full-duplex
interface Vlan1
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly
ip nat inside source list NAT-ACCESS interface FastEthernet0/0 overload[/FONT]

pings from BR1 were matching the deny any of STD-NAT-ACCESS (from show access-lists)
show logging displayed no details
there were no %SEC-6-IPACCESSLOGNP: list STD-NAT-ACCESS denied errors

I was fairly sure that permit 172.0.0.0 and 10.0.0.0 were correct, but without any errors to view (and why it wasn't working) was making it hard to debug.

PS...this is bizare...now working after being left overnight? ping from BR1

JanusGNS3#sh access-l
Standard IP access list STD-NAT-ACCESS
10 permit 192.168.1.0, wildcard bits 0.0.0.255 log
20 permit 172.0.0.0, wildcard bits 0.255.255.255 log
30 permit 10.0.0.0, wildcard bits 0.255.255.255 log (3 matches)
40 deny any log (42 matches)
Extended IP access list EXT-NAT-ACCESS
10 permit ip 192.168.1.0 0.0.0.255 any log
20 permit ip 172.0.0.0 0.255.255.255 any log
30 permit ip 10.0.0.0 0.255.255.255 any log (1 match)
40 deny ip any any log (6 matches)

some of the deny matches are from the first 2 ping packets (which it shouldn't) and some EIGRP updates (which it should) being dropped

PPS @ drkat

debug ip packet detail <access-list> is only good for numbered ALCs, so not working here. tried dropping the <access-list> ID but no detail shown

drkat

NetworkVeteran wrote: »

Gadzooks! I got it. It's actually the log statements causing problems!

I got it to work when I changed it as follows--

Standard IP access list STD-NAT-ACCESS
10 permit 192.168.1.0, wildcard bits 0.0.0.255
20 permit 172.0.0.0, wildcard bits 0.255.255.255
30 permit 10.0.0.0, wildcard bits 0.255.255.255
40 deny any

And here's the explanation--

nice job! but what about named vs numbered + extended ??

didnt u say it worked on numbered std as well as extended ? or was the cisco quote shortened?

NetworkVeteran

drkat wrote: »

nice job! but what about named vs numbered + extended ??

My numbered ACL had no log statements. That's why it worked beautifully. My named ACL had log statements. That's why it was behaving so strangely. The OP should remove the 'log' keywords from the ACLs he's using for NAT since Cisco doesn't support that functionality.

OP wrote:

debug ip packet detail <access-list> is only good for numbered ALCs, so not working here. tried dropping the <access-list> ID but no detail shown

debug ip nat <acl> also only takes numbered ACLs. I like the pretty naming of the named ACLs, but they sure do have limitations when compared to numbered ones.

Forsaken_GA

NetworkVeteran wrote: »

My numbered ACL had no log statements. That's why it worked beautifully. My named ACL had log statements. That's why it was behaving so strangely. The OP should remove the 'log' keywords from the ACLs he's using for NAT since Cisco doesn't support that functionality.


debug ip nat <acl> also only takes numbered ACLs. I like the pretty naming of the named ACLs, but they sure do have limitations when compared to numbered ones.

Yeah, I'm glad you found it, saved me from having to go dick with my NAT setup, as I'm NAT'ing several IP ranges with a standard numbered ACL and not running into any issues. Good work running it down!

azaghul

Thank you all....we continue to learn the "oddities" within the IOS.

drkat

Oh I'm sorry I thought the OP had the extended working

azaghul

drkat wrote: »

Oh I'm sorry I thought the OP had the extended working

All working now, both extended and standard...