standard vs extended acl issue

azaghulazaghul Member Posts: 569 ■■■■□□□□□□
in CCNP
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?icon_redface.gif
· Share on FacebookShare on Twitter

Comments

  • NetworkVeteranNetworkVeteran Member Posts: 2,338 ■■■■■■■■□□
    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. :p

    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.
    · Share on FacebookShare on Twitter
  • drkatdrkat Banned Posts: 703
    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?
    · Share on FacebookShare on Twitter
  • NetworkVeteranNetworkVeteran Member Posts: 2,338 ■■■■■■■■□□
    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?
    · Share on FacebookShare on Twitter
  • NetworkVeteranNetworkVeteran Member Posts: 2,338 ■■■■■■■■□□
    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#
    · Share on FacebookShare on Twitter
  • NetworkVeteranNetworkVeteran Member Posts: 2,338 ■■■■■■■■□□
    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.
    · Share on FacebookShare on Twitter
  • networker050184networker050184 Mod Posts: 11,962 Mod
    Quite the detective work there NetworkVeteran!
    An expert is a man who has made all the mistakes which can be made.
    · Share on FacebookShare on Twitter
  • azaghulazaghul Member Posts: 569 ■■■■□□□□□□
    Pics make it easier...

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

    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
    · Share on FacebookShare on Twitter
  • drkatdrkat Banned Posts: 703
    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?
    · Share on FacebookShare on Twitter
  • NetworkVeteranNetworkVeteran Member Posts: 2,338 ■■■■■■■■□□
    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.
    · Share on FacebookShare on Twitter
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    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!
    · Share on FacebookShare on Twitter
  • azaghulazaghul Member Posts: 569 ■■■■□□□□□□
    Thank you all....we continue to learn the "oddities" within the IOS.
    · Share on FacebookShare on Twitter
  • drkatdrkat Banned Posts: 703
    Oh I'm sorry I thought the OP had the extended working
    · Share on FacebookShare on Twitter
  • azaghulazaghul Member Posts: 569 ■■■■□□□□□□
    drkat wrote: »
    Oh I'm sorry I thought the OP had the extended working

    All working now, both extended and standard...
    · Share on FacebookShare on Twitter
Sign In or Register to comment.