Free CCNA | Extended ACLs | Day 35 | CCNA 200-301 Complete Course

Welcome to Jeremy’s IT Lab. This is a free,  complete course for the CCNA. If you like these videos, please subscribe to follow along with the  series.

Also, please like and leave a comment, and share the video to help spread this  free series of videos. Thanks for your help. In this video we will cover extended ACLs, access  control lists.

Everything we covered in Day 34 about the purpose of ACLs, how they work, how  to apply them to interfaces, etc. is the same for extended ACLs. The only difference is that  extended ACLs can do more specific matching than standard ACLs, which can only match  based on the source IP address of the packet.

As a reminder, ACLs are topic  5. 6 of the exam topics list, which states that you must be able to configure  and verify access control lists. After this video, you’ll know everything you need to know to  answer questions about ACLs on the CCNA exam.

Here’s what we’ll cover in today’s video.  First up, I’ll show you another way to configure numbered ACLs. This applies  to both standard and extended ACLs.

Then I’ll show you how to edit ACLs, in  case you want to add or remove specific entries in a specific order. Finally I’ll  introduce extended numbered and named ACLs. Although the commands are a little longer  because they can match based on more variables, the configuration method in general  is the same as for standard ACLs.

As always, watch until the end of the quiz for  a bonus question from ExSim for CCNA by Boson Software. Boson ExSim simulates the difficulty  and style of the real CCNA exam better than any other practice exams. If you want to get Boson  ExSim, follow the link in the video description.

Let’s get started. In day 34 you learned that  numbered ACLs are configured in global config mode. For example, here’s a simple ACL denying  192.

168. 1. 1 but permitting all other traffic.

The entries of ACL 1 are configured directly from  global config mode with the ACCESS-LIST command. You also learned that named ACLs are configured  with subcommands in a different config mode. Here’s the same ACL, configured as a named ACL.

The IP ACCESS-LIST STANDARD command is used  to enter standard named ACL config mode, and then subcommands within that mode  are used to configure each entry of the  ACL. However, in modern Cisco IOS you can also  configure numbered ACLs in the exact same way as named ACLs. Here’s a numbered ACL, configured  in the same way as the named ACL above.

Be aware that this is just a different  way of configuring numbered ACLs, but if you check the ACL in the running  config it will be displayed as if it was configured using the traditional  method, directly from global config mode. Let me demonstrate. From global config  mode I entered IP ACCESS-LIST STANDARD and then checked the options.

Notice that both  numbered and named ACLs are valid options. So, I configured ACL 1 using the named ACL  configuration method, IP ACCESS-LIST STANDARD 1 and then the two separate entries. However,  after checking the running config it displays as if I configured it using the traditional  numbered ACL method, configuring the entries from global config mode.

If it ends up being  just like a regular numbered ACL, why configure it in named ACL config mode? Well, there are  a few advantages to using this config mode. Let me show you those advantages.

First, you  can easily delete individual ACL entries with the command NO, followed by the entry number.  Let’s see how that works. First, I used DO SHOW ACCESS-LISTS, and you can see an ACL that I have  configured.

It has four entries, with sequence numbers 10, 20, 30, and 40. These are the default  sequence numbers, starting at 10 and increasing by 10, but remember that in named ACL config mode  you can also specify the sequence number manually. Okay, then I used the command NO 30  from named ACL config mode for ACL 1.

Then I checked the ACL again, and now you  can see that entry 30 has been deleted. This is very convenient for editing  ACLs. How about when configuring ACLs using the traditional numbered ACL  method, from global config mode?

Let’s see how it works. Here’s the same ACL,  with the same four entries. I also checked it out in the running-config.

Then I tried to delete  the same entry as before, sequence number 30, by using NO in front of the command. NO  ACCESS-LIST 1 DENY 192. 168.

3. 0 0. 0.

0. 255. So, did that delete that entry?

I checked with SHOW  ACCESS-LISTS, but nothing appears. Just to make sure I checked the running-config, but again  nothing was displayed. I deleted that entry, but I didn’t just delete that entry.

I deleted  the whole ACL! When configuring or editing numbered ACLs from global config mode, you can’t  delete individual entries, you can only delete the entire ACL. So, if you want to edit it you  have to delete it and then remake it from zero.

If an ACL has many entries, this is obviously not  a fun task. So, if you want to edit an ACL you definitely should use named ACL config mode. Note  that, if you prefer, you can configure a numbered ACL in global config mode, and then just use named  ACL config mode when you need to edit the ACL.

Okay, so that’s the first advantage  of using named ACL config mode, even if you’re configuring numbered ACLs.  You can delete individual entries with NO, followed by the entry number. Here’s another  advantage.

You can insert new entries in between other entries by specifying the sequence number.  When configuring an ACL from global config mode, you can’t specify the sequence number. The  entry is simply added to the end of the ACL, and the sequence number is automatically set to 10  higher than the current highest sequence number.

However from named ACL config mode you can  set the sequence number, so you can insert new entries in the middle of an ACL. Let’s  take a look. Here’s that same ACL from before, after deleting entry 30.

Let’s configure  a new entry with sequence number 30. So, I used 30 DENY 192. 168.

2. 0 0. 0.

0. 255 to create  a new entry, specifying the sequence number of 30. Then I checked the ACL, and you can see the new  entry was inserted between entries 20 and 40, and it has the sequence number of 30 that I  specified.

I also checked the running config, and notice as I showed you before that it  is displayed like the ACL was configured in global config mode, and the new entry was  inserted between the 2nd and 4th entries. Okay, those are a couple advantages of using named ACL  config mode even when configuring numbered ACLs. Let me show you one more  powerful method of editing ACLs.

There is a resequencing  function that helps edit ACLs. The command is IP ACCESS-LIST RESEQUENCE, followed  by the ACL ID, whether that’s a number or a name, and then the starting sequence number and the  increment that you want to use to increase the sequence numbers. Okay, that might be hard to  understand, so let me show you how it works.

Here’s an ACL, but notice the sequence numbers. It  seems someone made the bad decision of sequencing the entries 1, 2, 3, 4, and 5. Note that the  displayed order is 1, 3, 2, 4, 5, but that’s just because of what I explained in the previous  video, IOS sometimes reorders the /32 ACL entries.

So, what’s bad about these entry numbers? Well,  now it’s impossible to insert an entry in between the other entries. For example, maybe you want to  insert another deny entry somewhere in the middle.

However, it’s impossible because there  are no free sequence numbers in between. Let’s use the resequence command to fix this.  I used the command IP ACCESS-LIST RESEQUENCE 1 10 10.

1 is the ACL number, what  about those two 10s? The first one is the starting sequence number. It means, change  the sequence number of the first entry to 10.

How about the second 10 of the command?  It’s the increment. It means, add 10 for every entry after that, after the first  entry.

So, I used SHOW ACCESS-LISTS again, and the ACL has been resequenced. Note that the  same order is kept, DENY 192. 168.

1. 1 at the top, then DENY 3. 1, then DENY 2.

1, then DENY 4. 1, and  finally PERMIT ANY. However, the sequence numbers have been changed, starting at 10 for the top  entry and adding 10 for each entry after that.

That’s how ACL resequencing works. Now it’s simple  to add new entries in between the current entries. Note that this command is done from global config  mode.

It works for numbered and named ACLs, standard and extended ACLs, so all ACLs. Okay, let’s get to the main part of this  lecture, extended ACLs. Extended ACLs function mostly the same as standard ACLs.

They can be  numbered or named, just like standard ACLs. If you configure an extended numbered  ACL, you can use the following ranges. 100 to 199, and 2000 to 2699.

You definitely  should memorize these ranges for the exam. Make sure you know the standard ACL ranges  from last video too, 1 to 99 and 1300 to 1999. Extended ACLs are processed from top  to bottom, just like standard ACLs.

However, here’s the big difference. They  can match traffic based on more parameters, so they are more precise, and  more complex, than standard ACLs. You can really specify exactly what traffic  you want to deny and what traffic you want to permit, specific kinds of traffic from  specific hosts to specific destinations.

For the purpose of this video, we will  focus on matching based on these parameters. Layer 4 protocol and port number, source IP  address, and destination IP address. To configure an extended numbered ACL entry from global config  mode, the command is ACCESS-LIST, then the number.

Make sure this number is in one of the ranges  above, 100 to 199 or 2000 to 2699. Then PERMIT or DENY. After that you can specify the  protocol, such as TCP or UDP, then the source IP address and the destination IP address. 

How about configuring an extended named ACL? It starts with IP ACCESS-LIST EXTENDED, and then  the name or number. Just like in standard ACLs, extended numbered ACLs can also be  configured in named ACL config mode.

Once you’re in extended named ACL config mode,  you can specify the permit or deny statements, the protocol, source and destination, etc. Because  you already know the differences between numbered and named ACL configuration, I will just focus on  configuring extended ACLs using the named method. Just don’t forget that you can configure extended  numbered ACLs from global config mode, too.

Now, as I wrote above, extended ACLs are  much more complex than standard ACLs. There are lots of different variations and  options that can be used when configuring the access list entries. I’ll just show you some  basic options that you need to know for the CCNA, but I won’t explore every possible option that can  be used.

If you want to explore the commands more, try it out in a lab and use the question  mark to see what options there are. First I’ll explain how extended ACLs can match  based on protocol. From extended named ACL config mode, I entered DENY and used the question  mark to see the options.

Let me point out a few. First up, you can use an IP protocol  number. What’s an IP protocol number?

Think back to Day 10 of this course, about the  IPv4 header. There is a protocol field which identifies the protocol that is encapsulated  inside of the IP header, such as TCP or UDP. So, you can identify the protocol by  the number in the IPv4 protocol field.

Or, you can use the name of the protocol, options  are listed here. Most people prefer the name, since it’s easier to remember, but if you want to  use the protocol number here are some examples. IP protocol number 1 is ICMP, 6 is TCP,  17 is UDP, 88 is EIGRP, and 89 is OSPF.

I briefly mentioned some of these earlier in  the course. I recommend remembering these five, they might come up somewhere on the exam. But  as I said, usually you’ll use the protocol name in ACLs.

Here you can see EIGRP, ICMP,  and OSPF. So, you can use an extended ACL to block OSPF messages on an interface, for  example. Or deny ICMP packets to deny pings.

However, for this lesson we are going to focus  on these two, TCP and UDP, as well as one more. That is IP itself. If you use the IP option,  it matches all IP packets.

We use this option when we don’t care about the protocol, we just  want to deny or permit all packets. For example, if you want to put a ‘permit any’ statement at the  end of an ACL, you would use the IP option here. Now let’s see how to add the source and  destination IP addresses to this ACL entry.

So, I selected TCP as the protocol. So, any IP packets  with a TCP segment inside will match this part of the entry. However, we still have to specify the  source and destination IP addresses to match.

Note that, in extended ACLs to specify a /32  source or destination you have to use the HOST option or specify the wildcard mask. You can’t  just write the address without either of those. In standard ACLs that is  possible, but not extended.

Okay, so I decided to use ANY to match all  source IP addresses. Now we can specify the destination IP address. There are many more  options here related to the Layer 4 port number, but I’ll cover that later.

So, for the  destination address these are the options, the destination address, ANY, or HOST to specify  a single destination. I decided to specify the destination 10. 0.

0. 0, and now I have to enter the  wildcard mask. I specified a /24 wildcard mask, and now this entry is complete.

So, what is the  function of this entry? It will deny all packets that encapsulate a TCP segment, from any source  IP address to destination network 10. 0.

0. 0/24. This is just a single entry, of course, to  write a complete ACL we would probably add more entries after this, but now I want you to  practice writing a few extended ACL entries.

Here are a few practice questions.  These aren’t entries in the same ACL, just individual entries so you can  practice writing entries for extended ACLs. If you can, pause the video and try to write out  each entry on your own before I show the answers.

Okay, let’s check each one, number 1 first.  How can you write an extended ACL entry that permits all traffic? The answer is PERMIT IP  ANY ANY.

We use IP to match all protocols, and then we can use ANY for both the source  and destination to match all IP addresses. This is like PERMIT ANY in a standard ACL.  Okay, how about number 2?

Prevent 10. 0. 0.

0/16 from sending UDP traffic to 192. 168. 1.

1/32.  Here’s the answer, DENY UDP 10. 0.

0. 0 0. 0.

255. 255 HOST 192. 168.

1. 1. Instead of HOST, another  option is to write out the wildcard mask at the end instead, 0.

0. 0. 0.

Next let’s  check number 3. Prevent 172. 16.

1. 1/32 from pinging hosts in 192. 168.

0. 0/24. What  protocol does ping use?

Let’s check the answer. DENY ICMP, that’s the protocol for ping. I  said we’ll focus on the TCP, UDP, and IP options, but still make sure you’re aware that ICMP  is used for ping.

Then HOST 172. 16. 1.

1 192. 168. 0.

0 0. 0. 0.

255. Again, instead of  HOST you could use the wildcard mask 0. 0.

0. 0. Okay, we’ll do some more practice later  but for now let’s go a little deeper.

So let’s talk about matching TCP and UDP port  numbers. When you specify TCP or UDP as the protocol to match, you can optionally specify the  source and/or destination port numbers to match. This is optional, if you just specify  TCP or UDP without the port numbers, all port numbers will be matched.

So, here’s  the command without specifying the port numbers. I chose ‘DENY TCP’, but of course this  works with PERMIT statements and with UDP as well. If you want to specify the source TCP or  UDP port, you specify it after the source IP address and wildcard mask like this.

EQ,  followed by the source port is just one option. For example, EQ 80 means equal to port  80, so it matches TCP source port 80. Another option is GT, greater than.

For example  GT 80 matches all ports greater than 80, so 81 and up. There is also LT, less than.  LT 80 matches all port numbers less than 80, so 79 and below.

NEQ is not equal, so for  example NEQ 80 matches all ports except 80. The final option is RANGE, for example RANGE  80 100 matches all port numbers from 80 to 100. After the destination IP address, the same  options are available to match the destination port number.

Although you should know these  different options, EQ, GT, LT, NEQ, and RANGE, the most common choice is EQ, to match traffic for a  specific port number. Hopefully you remember these port numbers from Day 30 of the course. If not, I  recommend taking the time now to learn them again.

So, in this example I didn’t specify the host  port, I just entered DENY TCP ANY, and then went straight to the destination IP, HOST 1. 1. 1.

1. Then  I entered EQ to match a specific port, and you can see the options below. You can enter the specific  port number, or you can enter the keyword instead, such as WWW to match HTTP, which is port 80.

Lots  of common port numbers don’t have a keyword here you can use, though, so make sure you learn the  actual numbers. So, I entered port 80, for HTTP. What is the effect of this ACL entry?

It denies  all packets destined for IP address 1. 1. 1.

1/32, TCP port 80. Okay, in the next I’ll have  you practice writing some more ACL entries, but let me say one more point. After the  destination IP address and/or destination port numbers, there are many more options  you can use to match in an extended ACL.

These aren’t necessary to learn for the CCNA, but  some options are ACK, to match the TCP ACK flag. FIN, to match the TCP FIN flag.  SYN, to match the TCP SYN flag.

TTL, to match packets with a specific TTL, time to  live, value in the IPv4 header. And DSCP, to match packets with a specific DSCP, differentiated  services code point, value in the IPv4 header. Finally, note that if you specify the protocol,  source IP, source port, destination IP, destination port, etc, a packet must match ALL  of those values to match the ACL entry.

Even if it matches all except one of the parameters,  the packet won’t match that entry of the ACL. So, extended ACLs let you be very specific  about what traffic you want to match. Okay, here’s some more practice for writing  individual extended ACL entries.

I recommend pausing the video to try to solve these yourself,  but now let’s check the answers. Number 1, allow traffic from 10. 0.

0. 0/16 to access the server at  2. 2.

2. 2/32 using HTTPS. And here’s the answer.

PERMIT TCP, because we need to match HTTPS,  which uses TCP. Then the source IP address is 10. 0.

0. 0/16, and we don’t need to specify a source  port number. The destination IP is 2.

2. 2. 2/32.

I used a /32 wildcard mask, but you can  use HOST 2. 2. 2.

2 instead, of course. Finally, I used EQ 443 to match only HTTPS, which  uses TCP port 443. Okay, that’s number one.

Next, number 2. Prevent all hosts from using  source UDP port numbers from 20000 to 30000 from accessing the server at 3. 3.

3. 3/32. And  here’s the answer.

DENY UDP ANY RANGE 20000 30000 HOST 3. 3. 3.

3. So, this matches all packets  using a UDP source port from 20000 to 30000, with a destination of 3. 3.

3. 3. Okay, finally  number 3.

Allow hosts in 172. 16. 1.

0/24 using a TCP source port greater than 9999 to access all  TCP ports on server 4. 4. 4.

4/32 except port 23. Here’s the answer. The protocol is  TCP, the source IP is 172.

16. 1. 0/24, the source port is anything greater than 9999, the  destination IP is 4.

4. 4. 4/32, and the destination port is anything except 23.

Quite a specific  entry, but that’s the power of extended ACLs. Okay, let’s return to our network from Day 34  to configure and apply a few extended ACLs. Here are the requirements.

Hosts in  192. 168. 1.

0/24 can’t use HTTPS to access SRV1. Host in 192. 168.

2. 0/24 can’t access 10. 0.

2. 0/24.  And none of the hosts in 192.

168. 1. 0/24 or 2.

0/24 can ping 10. 0. 1.

0/24 or 2. 0/24.  So, we’ll use one ACL each to fulfill these requirements, and in this case they will all  be on R1, I’ll explain why soon.

First I’ll configure an ACL for this requirement, hosts in  192. 168. 1.

0/24 can’t use HTTPS to access SRV 1. Here’s the ACL. After entering extended named  ACL config mode, I made a deny statement that matches TCP traffic coming from 192.

168. 1. 0/24. 

The destination IP address is 10. 0. 1.

100/32, SRV1, and the destination port is 443, which  is HTTPS. That fulfills the requirement. Then I used PERMIT IP ANY ANY to allow all other  traffic.

Okay, that’s the ACL, but now we have to apply it to an interface. Which interface  should we apply it to, and in which direction? For standard ACLs, the rule is to apply them  as close to the destination as possible.

Why is that? It’s because standard  ACLs aren’t very specific, they only match the source IP address. So, if you  apply them close to that source, you’ll probably block more traffic than intended.

Because  extended ACLs are much more specific, the rule is the opposite. Extended ACLs should  be applied as close to the source as possible, to limit how far the packets travel in the network  before being denied. Because they can be very specific, if configured correctly there isn’t much  risk of blocking more traffic than you intended.

So, you should apply them close to the  source, so routers don’t waste resources processing packets that will just be dropped.  So, which interface should we apply this ACL to, where is the source? We should apply it inbound on  R1’s G0/1 interface.

So, if a PC in this network tries to access SRV1 using HTTPS, the  packet will be dropped right away at R1. Next up, let’s fulfill that second requirement,  hosts in 192. 168.

2. 0/24 can’t access 10. 0.

2. 0/24. Again, I’ll create a new ACL on R1.

Of course,  if you think you’re ready, pause the video and try to write out the ACL yourself. But  I’ll show you my solution now. Here it is.

Specifying IP as the protocol basically  matches all packets, anything with an IP header. Then I simply specified the source,  192. 168.

2. 0/24, and then destination, 10. 0.

2. 0/24. Finally I added PERMIT IP ANY  ANY to allow all other traffic.

So, which interface should this ACL be applied  to? Remember, extended ACLs should be applied as close to the source as possible. In this case,  the source is 192.

168. 2. 0/24, so I applied the ACL inbound on R1’s G0/2 interface.

Okay, now  the second requirement has been fulfilled. Finally, the third requirement. None of the hosts  in 192.

168. 1. 0/24 or 2.

0/24 can ping 10. 0. 1.

0/24 or 2. 0/24. So, what protocol does ping use?

We  should deny that protocol, and make a few entries to specify each source and destination. Pause the  video if you want to try it out, but here’s my solution. So, I created three deny entries that  match ICMP, two for source IP 192.

168. 1. 0/24, but only one for 192.

168. 2. 0/24.

Why is that? It’s  because in the previous ACL we already blocked all traffic from 192. 168.

2. 0/24 to 10. 0.

2. 0/24,  so we don’t need to include it in this ACL. If you included it, it’s not a problem of  course, but I just wanted to show you that it’s not necessary.

At the end of the ACL, I once  again included a PERMIT IP ANY ANY statement. Which interface should this ACL be applied to,  and in which direction? We should prevent hosts in both 192.

168. 1. 0/24 and 2.

0/24 from reaching  the servers’ networks. So, I think the best option is here, outbound on G0/0. This way the  ACL applies to both 192.

168. 1. 0/24 and 2.

0/24. So, here are the three ACLs I just configured. As I have said before, ACL configuration  can be quite flexible, so this isn’t the only solution that works.

Actually, this is  definitely not the most efficient solution. If you want a challenge, try to make a more  efficient solution, that uses less ACLs or less entries, and fulfills the requirements. If  you can find one, post it in the comment section!

Finally, here’s how to check which  ACLs are applied to an interface. The command is SHOW IP INTERFACE, then the  interface name. We often use SHOW IP INTERFACE BRIEF, but the regular version of the command  without BRIEF gives us more information.

This is just part of the output, it’s quite long so I  cut it off. Here’s the part I wanted to show you. Here you can see which ACL is applied  outbound and which is applied inbound, or if there is no applied ACL it  just says ‘not set’.

Of course, you can also check in the running config,  but it’s always good to know other commands, both for the exam and for ‘real-world’ purposes.  So, remember that command, SHOW IP INTERFACE. Before moving on to the quiz, let’s  review what we covered in today’s video.

First I showed you another way to configure  numbered ACLs. Basically, you can configure numbered ACLs in named ACL config mode. What is  the big advantage of that?

It’s editing ACLs. Named ACL config mode lets you delete individual  ACL entries, and specify the sequence number of new entries to insert them in the middle of an  ACL. Then I showed you extended numbered and named ACLs.

Extended ACLs are much more powerful than  standard ACLs, as they can match traffic based on protocol, source and destination IP addresses,  source and destination port numbers, etc. This makes them more complex to configure, but  you just need some practice to get comfortable with them. Remember to watch until the end of  the quiz for a bonus question from ExSim for CCNA by Boson Software, the best practice exams for the  CCNA.

Okay, let’s go to question 1 of the quiz. Which ACL, when applied outbound on R1’s G0/0, permits only PC1 to access the TFTP server  on SRV1? Below there are four extended ACLs, 100, 101, 102, and 103.

Pause the  video to think about your answer. Okay, the answer is 103. Entry 10 permits  UDP traffic from PC1 to access port 69, TFTP, on SRV1.

Note that,  when entering this command, I actually entered the port number of 69,  but IOS automatically converted it to TFTP. Then, entry 20 denies all other hosts from sending  UDP traffic to port 69 on SRV1. Finally, entry 30 permits all other traffic.

ACL 102 is similar, but  instead of specifying the port on the destination, SRV1, it specifies the source port, which  is incorrect. Okay, let’s go to question 2. What effect will the following command have on  ACL1?

Here is the command, NO ACCESS-LIST 1 DENY 10. 0. 2.

0 0. 0. 0.

255. And here is ACL1. A,  traffic from 10.

0. 2. 0/24 will be permitted.

B, ACL 1 will be deleted. C, the command  will not work, it will be rejected. Or D, traffic to 10.

0. 2. 0/24 will be permitted. 

Pause the video to think about your answer. The answer is B, ACL 1 will be deleted.  Configuring numbered ACLs from global config mode does not allow you to delete individual  entries.

Even if you specify a certain entry with the NO command, the entire ACL will be deleted.  If you want to delete an individual entry, you’ll need to use named ACL config  mode. Okay, let’s go to question 3.

Which command was used to resequence ACL 199? Here’s ACL 199 before being resequenced.  And here it is after.

Here are the commands, which one was used to resequence ACL 199?  Pause the video to think about the answer. The answer is C, IP ACCESS-LIST RESEQUENCE  199 5 10.

After IP ACCESS-LIST RESEQUENCE, you must specify the name, the new sequence number  of the top entry, and then the increment used to increase the sequence number of the  following entries. This command tells the router to use 5 for the first entry, and  then increase it by 10 for entries after that, so from 1, 2, 3, 4, and 5 it became 5, 15,  25, 35, and 45. Let’s go to question 4.

Which of the following ACLs would prevent  R1 from forwarding OSPF packets out of G0/2? Below are ACLs 110 to 113. Pause the  video to think about your answer.

The answer is ACL 112. Its first entry  denies protocol number 89, which is OSPF. PERMIT IP ANY ANY is added to allow other  packets, and then it is applied outbound on G0/2, so R1 won’t forward OSPF packets  out of that interface.

By the way, protocol number 88 from ACLs 111 and 113 is EIGRP,  not OSPF. Okay, let’s move on to question 5. ACL 150 isn’t having the intended  effect.

How can it be fixed to deny HTTP and HTTPS traffic from 192. 168. 1.

0/24  to 10. 0. 2.

0/24, but allow other traffic? Select two. Okay, so you can see ACL 150 and the  network topology below.

Here are the options. A, swap the source and destination IPs.  B, move the PERMIT IP ANY ANY statement to the beginning of the ACL.

C, apply  the ACL inbound on G0/1, not outbound. D, apply the ACL inbound on G0/0, not G0/1.  E, the protocol should be TCP, not UDP.

Or F, the port numbers should be 88 and 404. Pause  the video to think about your answers, select two. The answers are C and E.

The ACL should be  applied inbound because we are trying to filter traffic entering the G0/1 interface from the  192. 168. 1.

0/24 subnet. So, C is correct. Also, HTTP and HTTPS both use TCP as their Layer  4 protocol, not UDP.

So E is also correct. Okay, that’s all for the quiz. Now let’s do  a bonus question from Boson ExSim for CCNA.

Okay, here's today's Boson ExSim practice  question. We have a network here connected to the Internet. We have Router1, and three  servers.

Music Server1, Music Server2, and a web server. Here's the question. You have  been hired as a consultant for Music World Corp.

You need to limit access from the Internet  to the music download servers, Music Server1 and Music Server2. These two servers should  only allow FTP connections from the Internet. The web server is not subject to this policy  and should not be restricted.

Other servers on the 10. 10. 10.

0/24 subnet should not  allow any connections from the Internet. You have already issued the access-list 101  permit tcp any host 10. 10.

10. 20 command and applied the access list outbound on the F0/0  interface. Okay, so this ACL entry here, permit TCP any host 10.

10. 10. 20, satisfies this  part of the requirements.

The web server is not subject to this policy and should not be  restricted. So that requirement is already fulfilled. So, what requirement do we have  to fulfill?

It's this one here. You need to limit access from the Internet to the music  download servers. These two servers should allow only FTP connections from the Internet. 

Okay, so here are the options. We have A, B, C, and D. So, pause the video, look at these four  access list entries, and select the best answer.

Okay, let's check. So, I think the correct answer  is A, and let me explain. So, we want to permit FTP connections to Music Server1 and Music  Server2.

So we're permitting any source IP address, so anything from the Internet, so connect  to 10. 10. 10.

0, this is /30. So that includes Music Server1 and Music Server2. But it  doesn't include Web Server, for example.

And 'equals FTP', so that allows FTP connections  to Music Server1 and Music Server2. And then after that on this access list there would be a  implicit deny, so that denies all other traffic. So I think that satisfies the requirements.

We are  allowing all TCP connections to the web server, and we are allowing only FTP connections to Music  Server1 and Music Server2, and then the implicit deny blocks all other traffic. Okay, so let's  check the answer. I'll click on show answer.

And that is correct. So,  here is Boson's explanation. You can pause the video here if you want to  read the explanation, and I recommend you do.

As I have said before, this is one of  the great things about Boson ExSim. Okay, so that's the explanation. There  are also references to the chapter in Cisco's official cert guide and some  Cisco documentation which you can read.

Okay, that's Boson ExSim for the  CCNA. If you want to get ExSim, follow the link in the video description. These  are by far the best practice exams for the CCNA.

Once again, follow that link  in the video description. There are supplementary materials for this video. There is a flashcard deck to  use with the software ‘Anki’.

There will also be a packet tracer practice  lab so you can get some hands-on practice. That will be in the next video. Sign up for my  mailing list via the link in the description, and I’ll send you all of the flashcards  and packet tracer lab files for the course.

Before finishing today’s video I want  to thank my JCNP-level channel members. To join, please click the ‘Join’ button under the  video. Thank you to Aaron, Junhong, OJ, Magrathea, TheGunguy, Njabulo, Benjamin, Tshepiso,  Justin, Prakaash, Nasir, Erlison, Apogee, Marko, Flodo , Daming, Joshua,  Jhilmar, Ed, Value, John, Funnydart, Scott, Marek, Velvijaykum, C Mohd, Mark, Yousif, Sidi,  Boson Software, Devin, Lito, Yonatan, and Vance.

Sorry if I pronounced your name incorrectly,  but thank you so much for your support. This is the list of JCNP-level members at the time  of recording by the way, November 29th 2020. If you signed up recently and your name isn’t on  here don’t worry, you’ll be in future videos.

Thank you for watching. Please  subscribe to the channel, like the video, leave a comment, and share the  video with anyone else studying for the CCNA. If you want to leave a tip, check the links in the  description.

I'm also a Brave verified publisher and accept BAT, or Basic Attention Token, tips  via the Brave browser. That's all for now.