Answers: Extended Numbered ACL 1

Wendell
By Wendell June 24, 2016 13:10

This lab requires you to think about two big ideas. First, you have to think about how to configure the syntax of extended numbered ACLs to match well-known destination ports. Also you need to think about the most efficient location and direction to enable the ACL. Think through your own answer to the lab requirements first, and then check your answers here.

Answers

Figure 1: Topology Used in Extended ACL Lab

 

Example 1: R2 Config

 

Commentary

The primary use of access-lists is to control which traffic is allowed to come in and go out of the interfaces of a device. On Cisco devices there are a number of different ways to configure them; for IPv4 the two main methods are via the use of standard or extended ACL’s. Standard ACL’s are simpler and only allow matching based on the source IP host or network of the traffic. Extended ACL’s are more complex and allow matching on both source and destination host or network as well as matching based on the protocol being used. It is important to note however that ACL’s are not limited to the blocking or permitting of specific traffic, they are also used in a number of different features from Network Address Translation (NAT) to route-maps.

With this lab you were tasked with configuring an extended ACL that would be used to block specific traffic from one subnet to another. For the subnets, the requirements used two subnets: a source subnet of 20.0.1.0/24, and a destination subnet of 10.0.3.0/24. To match those subnets, you would use the same wildcard mask of 0.0.0.255. You could calculate the wildcard mask to use to match a subnet by taking the DDN mask (255.255.255.0 in each case) and subtract it from 255.255.255.255, leaving 0.0.0.255.

The matching requirements also listed many well-known ports, all of which can be matched with keywords rather than the actual port numbers. In particular, to match packets from subnet 20.0.1.0/24 to subnet 10.0.3.0/24, to the destination port with HTTP (port 80), use this command:

access-list 101 deny tcp 20.0.1.0 0.0.0.255 10.0.3.0 0.0.0.255 eq www

Similarly, to match FTP control traffic, FTP data (which uses a different port), and TFTP traffic, use these additional commands:

access-list 101 deny tcp 20.0.1.0 0.0.0.255 10.0.3.0 0.0.0.255 eq ftp

access-list 101 deny tcp 20.0.1.0 0.0.0.255 10.0.3.0 0.0.0.255 eq ftp-data

access-list 101 deny udp 20.0.1.0 0.0.0.255 10.0.3.0 0.0.0.255 eq tftp

The final requirement was to permit all other traffic, remember that without this statement all traffic will be blocked by the implicit deny at the end of all ACL’s. That statement could be explicitly switched to permit all remaining traffic by configuring the access-list 101 permit ip any any command at the end of the ACL.

The last step is to apply the ACL to the appropriate interface. Generally, Cisco suggests applying standard ACLs to the interface that is closest to the destination, and applying extended ACLs to the interface that is closest to the source. In this case, R2 is connected to the source subnet, so apply the ACL inbound on router R2, so apply the ACL on R2’s G02/1 subinterface using the ip access-group 101 in command.

Extended Numbered ACL 1
PPP over Ethernet 1
Wendell
By Wendell June 24, 2016 13:10
Write a comment

2 Comments

  1. Khalil Shuker December 28, 12:04

    Dear wendell

    referring to the dangerous Inbound ACL,we had told
    about , I prefer to apply this extended ACL
    at R2 Gi0/1 as outbound ,
    Any Advice???

    Reply to this comment
  2. certskills January 8, 10:02

    Khalil,
    Only those confident with ACLs should enable an inbound ACL in production, particularly at a remote site, and particularly if you have no other electronic means of accessing the router/switch console. If you’re comfortable enough to know that your ACL will not deny any necessary overhead traffic, then I’d call that confident enough to use them.

    I’d say that testing and experience trumps logic on paper, for sure. EG, you use the same ACLs, or ACLs with similar closing lines to permit all required overhead, and you use these ACLs regularly, then go for it. But I’d be cautious about a new ACL, or ACL with unfamiliar lines, or an ACL with few/no lines matching overhead protocols, then enabled inbound in production. Maybe at least test the lines permitting the overhead protocol somewhere safer, and then use them at remote sites.

    Wendell

    Reply to this comment
View comments

Write a comment

Comment; Identify w/ Social Media or Email

Subscribe

Subscribe to our mailing list and get interesting stuff and updates to your email inbox.

Thank you for subscribing.

Something went wrong.

Search

Categories