Loading ...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.
Are the routers still alive after this ???
Bye
PL
Hello Pierre-Louis!
Yes the routers are fine - the Mock Student even successfully verified everything!
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
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
last 3 lines in the acl will also need the log-input option rather than just log
172.16.0.0 is a /12, not a /16, per RFC 1918
Also, the log statements should be log-input to include Layer 2 information.
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.
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
The ACL is on the wrong interface (or I’ve read it wrong) and the mask for 172.16.0.0 is wrong.
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
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
the access-list should be applied on the interface S1/3 not on S1/2!
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
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
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.
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.
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.
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
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.
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?
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
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
followed by implicit deny and also interface is wrong
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
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
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
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
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
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 –
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
Jeez Jeff - picky, picky
Go ask the proctor real nicely for clarification on the diagram
Anthony,
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
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!
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 ?
Firstly, thanks Anthony 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?
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.
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
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
Typo on the last statement,
access-list 100 permit ip 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 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?
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.