Extended Access-List example on Cisco Router

This topic is to discuss the following lesson:

Hi Rene,

One quick question, why do you need to specify: Robocop(config)#access-list 100 deny ip any any log
when at the end of every access list there is the invisible deny command.

Any clarification would be greatly appreciated.

Thanks

P.S. Keep up the good work.

Hi Edmundo,

Adding the log keyword will show all denied packets in your console. This is useful for troubleshooting, debugging or labbing.

1 Like

So if I understand correctly we would still achieve the same results if without entering this command? And the only reason we would use this command is mostly for logging events, troubleshooting or labbing…correct?

Thanks

Yes that’s right. There is always a default deny any at the bottom. Give it a try on a Cisco IOS router…

Hey… that’s really helpful…thnx so much…keep up the good work!

Hi Rene,
Very Good document on access-list , easy to understand . There are lot of options like
established, precedence etc. Any of your post explain about these options in detail.?

Thanks,
Srini

Hi Srini,

Let’s take a look at the different IP options:

R1(config-ext-nacl)#permit ip any any ?
  dscp        Match packets with given dscp value
  fragments   Check non-initial fragments
  log         Log matches against this entry
  log-input   Log matches against this entry, including input interface
  option      Match packets with given IP Options value
  precedence  Match packets with given precedence value
  reflect     Create reflexive access list entry
  time-range  Specify a time-range
  tos         Match packets with given TOS value
  ttl         Match packets with given TTL value

DSCP refers to the DSCP value in the TOS byte:
https://networklessons.com/quality-of-service/ip-precedence-dscp-values/

Fragments refers to fragmented IP packets.

Log will show matched packets on the console (like I did in this example). Log-input does the same but also allows you to select an interface.

Option refers to the option field in the header…there are a lot of options here.

Precedence refers to the precedence value in the TOS byte:
https://networklessons.com/quality-of-service/ip-precedence-dscp-values/

Reflect is for reflexive access-lists:
https://networklessons.com/quality-of-service/ip-precedence-dscp-values/

Time-range for time-based access-lists:
https://networklessons.com/security/cisco-asa-time-based-access-list/

TOS is for some of the non-DSCP or non-precedence values that you can use in the TOS byte.

TTL is to match on a certain time-to-live value in the IP packet header.

There’s also a big list for TCP options:

R1(config-ext-nacl)#permit tcp any any ?
  ack          Match on the ACK bit
  dscp         Match packets with given dscp value
  eq           Match only packets on a given port number
  established  Match established connections
  fin          Match on the FIN bit
  fragments    Check non-initial fragments
  gt           Match only packets with a greater port number
  log          Log matches against this entry
  log-input    Log matches against this entry, including input interface
  lt           Match only packets with a lower port number
  match-all    Match if all specified flags are present
  match-any    Match if any specified flag is present
  neq          Match only packets not on a given port number
  option       Match packets with given IP Options value
  precedence   Match packets with given precedence value
  psh          Match on the PSH bit
  range        Match only packets in the range of port numbers
  reflect      Create reflexive access list entry
  rst          Match on the RST bit
  syn          Match on the SYN bit
  time-range   Specify a time-range
  tos          Match packets with given TOS value
  ttl          Match packets with given TTL value
  urg          Match on the URG bit

Some of these options refer to the IP packet (dscp, option, precedence, tos, ttl). The established is an interesting one…

Established checks TCP headers to see if the ACK bit is enabled, after the three way handshake every TCP header has the ACK bit enabled. You can create an ACL statement that only allows “established” sessions with this. We don’t use it anymore…it has been replaced by:

https://networklessons.com/security/reflexive-access-list/
https://networklessons.com/security/cisco-cbac-configuration-example/
https://networklessons.com/security/zone-based-firewall-configuration-example/

Let me know if you want to know some specific options.

Rene

1 Like

Hi Rene,
Great!. Your reply got many useful information. For doing CCNP , above mentioned links will give very good idea on access-lists topics.

Hi Rene

Robocop(config)#access-list 100 permit icmp 1.1.1.0 0.0.0.255 host 2.2.2.2 echo
Robocop(config)#access-list 100 deny ip any any

for this case, Robocop cannot ping to ED209 ip 192.168.12.1

how can i allow robocop to ping ED209 192.168.12.1

When the access-list is applied inbound on Robocop, you’ll need to permit the ICMP return traffic from ED209. Something like this:

permit icmp host 192.168.12.1 host 192.168.12.2

Or you could make it more “specific” by adding echo-reply at the end of that statement.

2 Likes

Hi Rene hope ur well geode Avond meneer ! Took CCNA today and didn’t pass unfortunately I had booked exam and I didn’t feel quite ready bit annoyed since I knew that I hadn’t practised a specific area which I now need to practice ! And this area I scored 0 per cent on the post test break down … ! I need to practice practice practice … My score was encouraging enough overall so I will go back to study after a well earned week off

Wanted to say that your e-book for CCNA has been really helpful and would recommend it to anybody especially from point of view as a technical reference point for understanding the topics ground up from a practical hands on perspective

Hi Will,

Sorry to hear you didn’t pass the exam! You now do know what the exam is like and the things that you still need to focus on, that will make it much easier the next time you attempt it. Glad to hear you like the book!

Rene

Quick question.

So if I do permit tcp any any eq telnet will that only match traffic DESTINY to port 23? IE 192.168.1.1:12345 > 4.2.2.2:23 MATCH however what about the return traffic?

4.2.2.2:23 > 192.168.1.1:12345? I’m thinking about a QoS classification where that would only match the first half of the conversation.

Does that make sense?

Hi William,

That’s correct.

If you use “permit tcp any any eq telnet” then it will only match traffic that has destination port 23. In your example, it will match 192.168.1.1:12345 > 4.2.2.2:23.

The return traffic will be 4.2.2.2:23 > 192.168.1.1:12345, the source port will be 23 and the destination port is 12345.

Rene

1 Like

So for QOS wouldn’t you want to mark both parts of the conversation and give it proper BW? How would you accomplish that without NBAR?

The answer to this depends on where traffic is flowing relative to where you have applied a QoS service-policy. If you take a simple network like this:

Client ---- Router ---- Server

Where you want to reserve bandwidth for telnet traffic from the client to the server and from the server back to the client, it would be something like this (all from the Router):

ip access-list extended ACL_TELNET-CLIENT-2-SERVER
permit tcp host <CLIENT> host <SERVER> eq 23

class-map CM_TELNET-CLIENT-2-SERVER
match access-group ACL_TELNET-CLIENT-2-SERVER

policy-map PM_TELNET-CLIENT-2-SERVER
class CM_TELNET-CLIENT-2-SERVER
bandwidth 100

Interface from Client----->  (config-if)#service-policy input PM_TELNET-CLIENT-2-SERVER

Now you just repeat the template that is above to capture the traffic coming back from the Server to the Client. The key difference will be how you write your ACL:

ip access-list extended ACL_TELNET-SERVER-2-CLIENT
permit tcp host <SERVER> eq 23 host <CLIENT>

class-map CM_TELNET-SERVER-2-CLIENT
match access-group ACL_TELNET-SERVER-2-CLIENT

policy-map PM_TELNET-SERVER-2-CLIENT
class CM_TELNET-SERVER-2-CLIENT
bandwidth 100

Interface from Server----->  (config-if)#service-policy input PM_TELNET-SERVER-2-CLIENT
1 Like

In my experience this isn’t common practice, do you guys see it? I see more like reserving bandwidth in one direction, not the return. Is that fair to say?

The safest approach is to set QoS in both directions. At my company, we are concerned with prioritizing VOIP, print jobs, and SSH. VOIP is a bit easier since the VOIP server and phones automatically mark their traffic as DSCP EF, so we just trust those markings, but with the others, we do, in fact, mark them similar to the example I provided earlier where the classifier for return trip looks to the source port, not the destination.

If you knew that your remote sites, for example, had more of a problem with downloads saturating the bandwidth than uploads, you probably could set QoS in just the one direction and be fine. We set it both ways “just in case.”

1 Like