Nov
19

Hello to all our faithful blog readers, I hope this post find you very well, and enjoying your studies!

Access list tasks are a common CCIE Lab Exam feature, and I wanted to take a moment to show how easy it can be for a candidate to miss one thing or many things in such a task.

Here is the task topology and the task itself. Following that we have the proposed solution by a Mock Student :-)

Can you find the errors in his or her ways?

The Topology

The Task

Security

Traffic Filtering

8.1 Configure a security filter on R3 that will accomplish the following for traffic entering the router from the direction of R2:

  • Allow Telnet from R2 (S0/1) to R1 (Lo1)
  • Allow BGP traffic through the router
  • Allow ICMP ping traffic between R1 (Lo1) and R2 (Lo1)
  • Block any traffic sourced from RFC 1918 addresses – log these violations and include Layer 2 address information

4 points

The Proposed Solution

!
access-list 100 permit tcp host 32.0.1.2 eq telnet host 192.168.100.1 eq telnet
access-list 100 permit tcp any any eq bgp
access-list 100 permit icmp host 22.10.1.2 host 192.168.100.1
access-list 100 permit icmp host 192.168.100.1 host 22.10.1.2
access-list 100 deny ip 10.0.0.0 0.255.255.255 any log
access-list 100 deny ip 172.16.0.0 0.0.255.255 any log
access-list 100 deny ip 192.168.0.0 0.0.255.255 any log
!
interface Serial1/2
ip access-group 100 in

NOTE: I have posted a solution to this blog in the comments. The solution post date is November 20th, 2008.


You can leave a response, or trackback from your own site.

44 Responses to “Access Control Lists (How to Fail a Task without Really Trying)”

 
  1. Pierre-Louis says:

    Are the routers still alive after this ??? ;)

    Bye
    PL

  2. Hello Pierre-Louis!

    Yes the routers are fine – the Mock Student even successfully verified everything! :-)

  3. Thomas says:

    access-list 100 permit tcp host 32.0.1.2 [gt 1024] host 192.168.100.1 eq telnet
    access-list 100 deny ip 10.0.0.0 0.255.255.255 any log-input
    access-list 100 deny ip 172.16.0.0 0.15.255.255 any log-input
    access-list 100 deny ip 192.168.0.0 0.0.255.255 any log-input
    interface Serial1/3

  4. ck1976 says:

    access-list 100 deny ip 172.16.0.0 0.0.255.255 any log is using the wrong wildcard should be 0.15.255.255

  5. ck1976 says:

    last 3 lines in the acl will also need the log-input option rather than just log

  6. 172.16.0.0 is a /12, not a /16, per RFC 1918

  7. Also, the log statements should be log-input to include Layer 2 information.

  8. Ahriakin says:

    The biggest is the ACL is on the wrong interface, the Telnet ACL uses telnet as a source aswell as destination, BGP wasn’t allowed as both a source and destination (also could be more specific), log statements should be log-input.

  9. Carol says:

    i’m thinking on one of the rfc 1918 address which is wrong..

    172.16.0.0/12

    access-list 100 deny ip 172.16.0.0 0.15.255.255 any log

  10. Ian says:

    The ACL is on the wrong interface (or I’ve read it wrong) and the mask for 172.16.0.0 is wrong.

  11. Fernando says:

    Two things come to mind:

    Serial interface is wrong. Should be 1/3 in, and not 1/2 in.

    Shouldn’t the Telnet line read:
    access-list 100 permit tcp host 32.0.1.2 host 192.168.100.1 eq telnet

  12. Sesano says:

    I see 2 errors here.

    The first task says telnet from R2 to R1, hence the correct acces list should be;

    access-list 100 permit tcp host 32.0.1.2 host 192.168.100.1 eq telnet

    The acces group should be applied to R3 s1/3 interface in the “in” direction.

    Also to log L2 information, all the RFC1918 acces list should have log-input at the end (instead of just log).

    Also there seem to be an implicit deny all at the end of the solution and that should be changed by adding 1 more extra line of command

    access-list 100 permit ip any any

  13. Carlos says:

    the access-list should be applied on the interface S1/3 not on S1/2!

  14. Steve says:

    The telnet part looks fine to me.

    For BGP i’d add the line
    access-list 100 permit tcp any eq bgp any

    The question mentions icmp ping traffic specifically. it also says “between” so we need to handle both ways.
    access-list 100 permit icmp host 192.168.100.1 host 22.10.1.2 echo
    access-list 100 permit icmp host 192.168.100.1 host 22.10.1.2 echo-reply
    access-list 100 permit icmp host 192.168.100.1 host 22.10.1.2 echo
    access-list 100 permit icmp host 192.168.100.1 host 22.10.1.2 echo-reply
    As mentioned by a few people use log-input for to include layer2 info.

    access-list 100 deny ip 10.0.0.0 0.255.255.255 any log-input
    access-list 100 deny ip 172.16.0.0 0.15.255.255 any log-input
    access-list 100 deny ip 192.168.0.0 0.0.255.255 any log-input

    The diagram shows a RIPv2 domain so we need to also allow rip.
    access-list 100 permit udp any any eq 520

    Apply it to the correct interface
    interface Serial1/3
    ip access-group 100 in

  15. Steve says:

    oops! I meant to put.
    access-list 100 permit icmp host 192.168.100.1 host 22.10.1.2 echo
    access-list 100 permit icmp host 192.168.100.1 host 22.10.1.2 echo-reply
    access-list 100 permit icmp host 22.10.1.2 host 192.168.100.1 echo
    access-list 100 permit icmp host 22.10.1.2 host 192.168.100.1 echo-reply

  16. Bryan says:

    I don’t think you should ever NEED an ACL to end with specific deny statements. They would be denied anyway by the implicit deny all.

  17. Colin says:

    Yeap, explicit deny any not required unless you want to log.

    Worth noting for others though that if you have an ACL specified but it doesn’t exist the default tends to be to permit any. Try it out with SNMP communities for example.

  18. Stan I says:

    There is no echo at the echo of the two ICMP lines, which means that it will match ALL ICMP, not just ping as per requirement.

  19. Carlos says:

    access-list 100 permit tcp host 32.0.1.2 host 192.168.100.1 eq telnet

    access-list 100 permit tcp any any eq bgp
    access-list 100 permit tcp any eq bgp any

    access-list 100 permit icmp host 22.10.1.2 host 192.168.100.1 echo-reply

    access-list 100 permit udp any 224.0.0.9 eq 520

    access-list 100 deny ip 10.0.0.0 0.255.255.255 any log-input

    access-list 100 deny ip 172.16.0.0 0.15.255.255 any log-input

    access-list 100 deny ip 192.168.0.0 0.0.255.255 any log-input

    interface Serial1/3
    ip access-group 100 in

  20. Bryan stated:
    “I don’t think you should ever NEED an ACL to end with specific deny statements. They would be denied anyway by the implicit deny all.”

    Very true, there is an implicit deny all at the end of every access list however, if you explicitly deny traffic then the router doesnt have to process the packet as it searches in order, top-down, until it finds a permit statement and then implicitly denies it.

  21. NTllect says:

    errors are:

    1) telnet sessions are sourced from any port, not from 23, so the first line:
    access-list 100 permit tcp host 3.0.1.2 host 192.168.100.1 eq 23

    2) BGP can be sourced from tcp 179 and destined to, so one more line required for this

    access-l 100 per tcp any eq 179 any

    3) ICMP should be allowed from R2 to R1, so line 4 is useless, since we choose direction from R2 to R1

    4) RFC 1918 specifies that scope 172.16.0.0 to 172.32.255.255 is reserved, so line 6 should be corrected as follows

    deny ip 172.16.0.0 0.15.255.55 any log-input

    Interesting here is:
    >Block any traffic sourced from RFC 1918 addresses – log these violations and include Layer 2 address information

    is it acceptable to deny ip any any log-input instead of specifying exact address?

    Also, what about other traffic? should it be allowed? or denyed?

  22. Datiko says:

    I think solution must look like this:

    access-list 100 permit udp any any eq 520
    access-list 100 permit tcp any eq bgp any
    access-list 100 permit tcp any any eq bgp
    access-list 100 permit tcp host 32.0.1.2 host 192.168.100.1 eq telnet
    access-list 100 permit icmp host 22.10.1.2 host 192.168.100.1
    access-list 100 deny ip 10.0.0.0 0.255.255.255 any log-input

    access-list 100 deny ip 172.16.0.0 0.15.255.255 any log-input

    access-list 100 deny ip 192.168.0.0 0.0.255.255 any log-input

    int s 1/3
    ip access-group 100 in

  23. LEB says:

    I would also add RIP, since the topology states that all routers are in the RIP domain.

    access-list 100 permit udp any any eq rip

  24. john says:

    followed by implicit deny and also interface is wrong

  25. Carlos Yoncon says:

    Comments for each part:

    0) ACL direction and interface:

    interface serial1/3
    ip access-group 100 in

    1) For telnet session can be sourced from any port:

    access-list 100 permit tcp host 32.0.1.2 host 192.168.100.1 eq 23

    2) For BGP depending on which router stablishes peering first and taking care of the “through” wording, session can be sourced from or to port 179:

    access-list 100 permit tcp any eq bgp any
    access-list 100 permit tcp any any eq bgp

    3) ICMP should be allowed echo-reply from R2, since from R1 (echo) is not being restricted:

    access-list 100 permit icmp host 22.10.1.2 host 192.168.100.1 echo-reply

    4)RIPv2 should be allowed from R2

    access-list 100 permit udp host 22.10.1.2 host 224.0.0.9 eq 520

    4) Correct scope for RFC 1918 and log-input for L2 address logging

    access-list 100 deny ip 10.0.0.0 0.255.255.255 any log-input
    access-list 100 deny ip 172.16.0.0 0.15.255.255 any log-input
    access-list 100 deny ip 192.168.0.0 0.0.255.255 any log-input

  26. Chris Lonsberry says:

    Okay.. I’ll take a shot…

    (Allow RIP broadcasts from R2)
    access-list 100 permit udp host 32.0.1.2 host 224.0.0.9 eq rip

    (Allow telnet to R1-Lo1 from R2 Serial)
    permit tcp host 32.0.1.2 host 192.168.100.1 eq telnet

    (Allow BGP)
    permit tcp any eq bgp any

    (Allow R2 Lo1 to ping R1 Lo1. Remember that this ACL is only inbound on the serial interface form R2)
    permit icmp host 22.10.1.2 host 192.168.100.1 echo

    (This was ambiguous to me whether R1 needed to ping back. The question stated “traffic entering from the direction of R2. Since I don’t think this would be taken off in a lab if you entered it… someone correct me if I’m wrong… I’d add this to allow R2 Lo1 to reply to pings from R1 Lo1 (if desired. Again.. remember that there’s no ACL on the other serial interface.. nor is there an outbound ACL on S1/3)

    permit icmp host 22.10.1.2 host 192.168.100.1 echo-reply

    (Deny RFC1918 stuff – note the subnet masks. I have to admit that I forgot the log-input.. as opposed to log.. but I would’ve figured it out if I was on a router. The ? is our friend.)
    deny ip 10.0.0.0 0.255.255.255 any log-input
    deny ip 172.16.0.0 0.15.255.255 any log-input
    deny ip 192.168.0.0 0.0.255.255 any log-input

    !
    (and finally… let’s put it on the right interface.)
    interf S1/3
    ip access-group 100 in

  27. Chris Lonsberry says:

    Whoops.. hosed that all up… let’s try again…

    Okay.. I’ll take a shot…

    (Allow RIP broadcasts from R2)
    access-list 100 permit udp host 32.0.1.2 host 224.0.0.9 eq rip

    (Allow telnet to R1-Lo1 from R2 Serial)
    access-list 100 permit tcp host 32.0.1.2 host 192.168.100.1 eq telnet

    (Allow BGP)
    access-list 100 permit tcp any eq bgp any

    (Allow R2 Lo1 to ping R1 Lo1. Remember that this ACL is only inbound on the serial interface form R2)
    access-list 100 permit icmp host 22.10.1.2 host 192.168.100.1 echo

    (This was ambiguous to me whether R1 needed to ping back. The question stated “traffic entering from the direction of R2. Since I don’t think this would be taken off in a lab if you entered it… someone correct me if I’m wrong… I’d add this to allow R2 Lo1 to reply to pings from R1 Lo1 (again.. remember that there’s no ACL on the other serial interface.. nor is there an outbound ACL on S1/3)

    access-list 100 permit icmp host 22.10.1.2 host 192.168.100.1 echo-reply

    (Deny RFC1918 stuff – note the subnet masks. I have to admit that I forgot the log-input.. as opposed to log.. but I would’ve figured it out if I was on a router. The ? is our friend.)
    access-list 100 deny ip 10.0.0.0 0.255.255.255 any log-input
    access-list 100 deny ip 172.16.0.0 0.15.255.255 any log-input
    access-list 100 deny ip 192.168.0.0 0.0.255.255 any log-input

    !
    (and finally… let’s put it on the right interface.)
    interf S1/3
    ip access-group 100 in

  28. Ray says:

    I’ll take a shot too.. but I forgot about the RIP traffic.. Good catch Chris!

    Telneting to R1 on port 23.
    access-list 100 permit tcp host 32.0.1.2 host 192.168.100.1 eq telnet

    BGP destination is port 179, the local port can be random, right?
    access-list 100 permit tcp any any eq 179

    R1 is allowed to request an ICMP ping to 192.168.100.1. There is no ACL that will filter the return ICMP Packet from R2. R2 will send a ICMP packet out of Serial 1/3 (no filtering), but R1 will send a ICMP replay packet to R2. Right?
    access-list 100 permit icmp host 22.10.1.2 host 192.168.100.1 echo-request
    access-list 100 permit icmp host 22.10.1.2 host 192.168.100.1 echo-reply

    These lines are added because we need to log violations and Layer 2 info.
    access-list 100 deny 10.0.0.0 0.0.0.255 any log-input
    access-list 100 deny 172.16.0.0 0.15.255.255 any log-input
    access-list 100 deny 192.168.0.0 0.0.255.255 any log-input

    Assigned to serial 1/3, because its closer to the source (R2). I guess it could be either interfaces but maybe different ACL lines.
    interface serial 1/3
    ip access-group 100 in

  29. The Mock Student :-) had made 8 major mistakes in the configuration. Here is my correct configuration.

    One of the most scary things is that due to slow RIP convergence, the student could have pinged after the application of the erroneous access list and it would have appeared the list did not break connectivity.

    Also, another real tricky one is the fact that if you did the steps in the order presented, you end up permitting BGP traffic sourced from the RFC 1918 address space. Doh!

    Do you start to see how you can be 100% sure that you received full points for a task, when in fact you received 0?

    Thank you all for participating in our blog here at Internetwork Expert!

    !
    access-list 100 deny ip 10.0.0.0 0.255.255.255 any log-input
    access-list 100 deny ip 172.16.0.0 0.15.255.255 any log-input
    access-list 100 deny ip 192.168.0.0 0.0.255.255 any log-input
    access-list 100 permit tcp host 32.0.1.2 host 192.168.100.1 eq telnet
    access-list 100 permit tcp any any eq bgp
    access-list 100 permit tcp any eq bgp any
    access-list 100 permit icmp host 22.10.1.2 host 192.168.100.1 echo
    access-list 100 permit icmp host 22.10.1.2 host 192.168.100.1 echo-reply
    access-list 100 permit udp any any eq rip
    access-list 100 deny ip any any log
    !
    interface Serial1/3
    ip access-group 100 in

  30. Jeff says:

    Requirement #1 – Allow Telnet from R2 (S0/1) to R1 (Lo1)

    access-list 100 permit tcp host 32.0.1.2 host 150.1.1.1 eq 23

    Requirement #2 – Allow BGP traffic through the router

    access-list 100 permit tcp any any eq 179
    access-list 100 permit tcp any eq bgp any

    Requirement #3 – Allow ICMP ping traffic between R1 (Lo1) and R2 (Lo1)

    access-list 100 permit icmp host 192.168.100.1 host 22.10.1.2 echo
    access-list 100 permit icmp host 192.168.100.1 host 22.10.1.2 echo-reply
    access-list 100 permit icmp host 192.168.100.1 host 22.10.1.2 echo
    access-list 100 permit icmp host 192.168.100.1 host 22.10.1.2 echo-reply

    Requirement #4 – Block any traffic sourced from RFC 1918 addresses – log these violations and include Layer 2 address information

    access-list 100 deny ip 10.0.0.0 0.255.255.255 any log-input
    access-list 100 deny ip 172.16.0.0 0.15.255.255 any log-input
    access-list 100 deny ip 192.168.0.0 0.0.255.255 any log-input

    Implicit Requirement #4 – The diagram shows a RIPv2 IGP running, so…

    access-list 100 permit udp any any eq 520

    ACL order, applied inbound on R3′s interface Serial1/3:

    access-list 100 remark — DENY RFC1918 ADDRESSES –
    access-list 100 deny ip 10.0.0.0 0.255.255.255 any log-input
    access-list 100 deny ip 172.16.0.0 0.15.255.255 any log-input
    access-list 100 deny ip 192.168.0.0 0.0.255.255 any log-input
    access-list 100 remark — PERMIT RIP TRAFFIC –
    access-list 100 permit udp any any eq 520
    access-list 100 remark — PERMIT BGP TRAFFIC –
    access-list 100 permit tcp any any eq 179
    access-list 100 permit tcp any eq bgp any
    access-list 100 remark — PERMIT TELNET FROM R2 TO R1 LOOPBACK –
    access-list 100 permit tcp host 32.0.1.2 host 150.1.1.1 eq 23
    access-list 100 remark — PERMIT ICMP PING —
    access-list 100 permit icmp host 150.1.1.1 host 150.1.2.2 echo
    access-list 100 permit icmp host 150.1.1.1 host 150.1.2.2 echo-reply
    access-list 100 permit icmp host 150.1.2.2 host 150.1.1.1 echo
    access-list 100 permit icmp host 150.1.2.2 host 150.1.1.1 echo-reply
    access-list 100 remark — END OF ACL –

  31. Jeff says:

    Ooops, I forgot to mention that the first issue I saw was requirements to permit traffic to/from certain loopback interfaces that didn’t have addressing depicted in the diagram :)

  32. Jeez Jeff – picky, picky :-)

    Go ask the proctor real nicely for clarification on the diagram :-)

  33. Sesano says:

    Hi,

    I will like to clarify an issue with your solution,

    Question says “Allow ICMP ping traffic between R1 (Lo1) and R2 (Lo1)”

    Your solution looks to me for the icmp part that it will only allow echo & echo reply coming from R2, what happens if R1 generates the echo, this will be dropped by the ACL before it even gets to R2 (even though you have correctly allowed R2 to reply if it receives an echo from R1).

    Please help me clarify.

    Thanks,

    Olu

  34. Hi Olu!

    When R1 generated the echo, the response from R2 matches this line:

    access-list 100 permit icmp host 22.10.1.2 host 192.168.100.1 echo-reply

    Here are the results of show access-list after verifying the ping in both directions.

    R3#sh access-list
    Extended IP access list 100
    10 deny ip 10.0.0.0 0.255.255.255 any log-input
    20 deny ip 172.16.0.0 0.15.255.255 any log-input
    30 deny ip 192.168.0.0 0.0.255.255 any log-input
    40 permit tcp host 32.0.1.2 host 192.168.100.1 eq telnet
    50 permit tcp any any eq bgp
    60 permit tcp any eq bgp any
    70 permit icmp host 22.10.1.2 host 192.168.100.1 echo (5 matches)
    80 permit icmp host 22.10.1.2 host 192.168.100.1 echo-reply (5 matches)
    90 permit udp any any eq rip (45 matches)
    100 deny ip any any log

    I think what you might have missed here is the fact that the ping response to R1 will be sourced from R2.

    Thanks again for participating in our blog!

  35. Khaled says:

    Hi
    At the end i understand that it s better to have a

    access-list 100 deny ip any any log

    But if you don t have this last line are you still ok with the answer ?

  36. NTllect says:

    Firstly, thanks for this entry, very useful!

    I just can’t figure out why RIP will be blocked, traffic destined to router itself is not subject for ACL check. But, during vol.2 we faced such issues, can you please explain?

  37. ck1976 says:

    NTllect, I believe the RIP statement is needed because the traffic sourced by the router is not subject for the ACL check. Any traffic passing through the router or that has the destination of the this router will be subject to the ACL.

  38. Wayne says:

    I know I am a little late in the game, but I just saw this blog post today so thought I would share here what I would have done. I like to use named standard and extended ACL’s : (just my preference)

    ip access-list extended Filter
    remark Block RFC1918 addresses
    deny ip 10.0.0.0 0.255.255.255 any log-input
    deny ip 172.16.0.0 0.15.255.255 any log-input
    deny ip 192.168.0.0 0.0.255.255 any log-input
    remark allow RIPv2 traffic
    permit udp any any eq rip
    remark allow telnet traffic
    permit tcp host 32.0.1.2 host 192.168.100.1 eq telnet
    remark allow BGP traffic
    permit tcp any any eq bgp
    permit tcp any eq bgp any
    remark allow ping traffic
    permit icmp host 22.10.1.2 host 192.168.100.1 echo
    permit icmp host 22.10.1.2 host 192.168.100.1 echo-reply
    deny ip any any log

    int s1/3
    ip access-group Filter in

    Thanks,
    Wayne

  39. Black Jack says:

    Im assuming that the question did not explictly ask for ONLY icmp traffic between the two hosts, hence allowing icmp for any would be a valid solution, I presume. Unfortunatly the proctor is in hidding so I could not ask him.

    access-list 100 permit tcp host 32.0.1.2 host 192.168.100.1 eq telnet
    access-list 100 permit tcp any eq bgp any
    access-list 100 permit tcp any any eq bgp
    access-list 100 permit icmp any any
    access-list 100 deny ip 10.0.0.0 0.255.255.255 any log-input
    access-list 100 deny ip 172.16.0.0 0.15.255.255 any log-input
    access-list 100 deny ip 192.168.0.0 0.0.255.255 any log-input
    access-list 100 permit any any

    int Serial1/3
    ip access-group 100 in

  40. Black Jack says:

    Typo on the last statement,

    access-list 100 permit ip any any

  41. Routeriguez says:

    access-list 100 deny ip 10.0.0.0 0.255.255.255 any log-input
    access-list 100 deny ip 172.16.0.0 0.15.255.255 any log-input
    access-list 100 deny ip 192.168.0.0 0.0.255.255 any log-input
    access-list 100 permit tcp host 32.0.1.2 host 192.168.100.1 eq telnet
    access-list 100 permit tcp any eq bgp any
    access-list 100 permit tcp any any eq bgp
    access-list 100 permit icmp host 22.10.1.2 host 192.168.100.1 eq echo
    access-list 100 permit icmp host 22.10.1.2 host 192.168.100.1 eq echo-reply
    access-list 100 permit udp any any eq rip

    int s1/3
    ip access-group 100 in

    The question seemed a little vague to me because the diagram lacked loopback addresses and it seemed worded to imply traffic originating from the routers themselves instead of the networks attached to the router. I chose the safe route (no pun intended) by choosing the latter. I didn’t “deny any any log” at the end because there was no requirement for that, but I understand it’s good practice if you want to debug your ACL. Would it have passed anyway?

  42. I think verifying the loopback addresses with a proctor is a great idea. I love the 100 deny ip any any log to help ensure we have not broken anything else in the network. While I am fairly certain it would not fail you on the task, I think it is prudent to remove it upon your second round of verifications.

  43. [...] is a solution to discover which K values are in use on the remote neighbor. Locally, create an access-list to match on EIGRP [...]

  44. mo_1980 says:

    Hi!

    The ACL should be for traffic entering the router from the direction of R2, but there are no RFC 1918 addresses on that side in the diagram.
    Do you still need to put the below lines on top of the ACL?

    access-list 100 deny ip 10.0.0.0 0.255.255.255 any log-input
    access-list 100 deny ip 172.16.0.0 0.15.255.255 any log-input
    access-list 100 deny ip 192.168.0.0 0.0.255.255 any log-input

 

Leave a Reply

Categories

CCIE Bloggers