Extended IPv4 ACL Drill 2 – Answers
Extended IPv4 ACLs? No problem. Matching packets going towards the client? A little more of a problem. Deciding whether you need to match ARP and OSPF in your ACL? Even more of a problem. This latest drill makes you think about ACL location + direction, syntax, plus those overhead protocols. As usual, check on the post about the requirements first so that this post makes sense.
Ground Rules
Often times, the words that describe the requirements for an ACL can be interpreted in several ways. So, before reading these answers, consider:
- Your answer may be correct per your interpretation of the requirements…
- …while being different from the answer listed here.
On to the answers!
Subnets in Use
All the answers will use the subnets of host A and Server S, so a few words about those first.
First, because the packets that drive this ACL will be flowing towards host A’s subnet, and from server S’s subnet, the source field in the ACL statements should refer to server S’s subnet, and the destination should refer to host A’s subnet.
Second, you just need to do a little math to take the router interface address/mask combo connected to those subnets to convert those numbers to the correct values to put in the ACL. First, to match the subnet of host A, to find the address and wildcard mask to use:
- R1’s G0/1 interface address/mask is 172.16.1.1/25.
- To match the subnet, use the subnet ID, calculated as 172.16.1.0.
- Convert prefix mask /25 to dotted decimal mask 255.255.255.128
- Subtract it from 255.255.255.255 to get 0.0.0.127
- Use 0.0.0.127 as the wildcard mask in the ACL statement.
For subnet 3, using the same logic:
- R3’s G0/1 interface address/mask is 172.16.3.3/27
- To match the subnet, use the subnet ID, calculated as 172.16.3.0.
- Convert prefix mask /25 to dotted decimal mask 255.255.255.224
- Subtract it from 255.255.255.255 to get 0.0.0.31
- Use 0.0.0.31 as the wildcard mask in the ACL statements.
For reference, the exercise uses the topology in Figure 1:
Figure 1: Topology Used in the ACL Drill
Answers
Of note for this particular answer:
- The ACL is located on R1, in the direction pointing away from the server. As a result, any matching of well-known ports should be a match of the ACL’s source port number
- Any ACL statement that matches a port number should use either the tcp or udp keywords.
- As an inbound ACL, the ACL will attempt to filter all IPv4 messages. In this case, that means:
- You need to add statements to permit OSPF packets, because those use IPv4
- You do NOT need to add statements for ARP, because ARP does not actually use IPv4 (ARP is a separate protocol, and is not encapsulated in IP packets.)
The answers for requirement set 1, for the explicitly identified applications, before getting to the defaults and overhead messages:
ip access-list extended eacl02 permit tcp 172.16.3.0 0.0.0.31 eq telnet 172.16.1.0 0.0.0.127 permit tcp 172.16.3.0 0.0.0.31 eq 80 172.16.1.0 0.0.0.127 permit tcp 172.16.3.0 0.0.0.31 eq 25 172.16.1.0 0.0.0.127
Partial Answer
Next, for the defaults, the requirement about denying all other TCP and UDP packets, while permitting all other IP packets besides those, might be a bit tricky. The logic intended by the combined requirements is this sequence:
- Permit packets for apps Telnet, World Wide Web, and SMTP
- Deny all other TCP and UDP traffic (that wasn’t already permitted)
- Permit all other IP traffic (that wasn’t already denied)
With that in mind, the following answer adds the matching for all other TCP, then UDP, and then IP.
ip access-list extended eacl02 permit tcp 172.16.3.0 0.0.0.31 eq 23 172.16.1.0 0.0.0.127 # uses 23 for Telnet permit tcp 172.16.3.0 0.0.0.31 eq 80 172.16.1.0 0.0.0.127 # uses 80 for WWW permit tcp 172.16.3.0 0.0.0.31 eq 25 172.16.1.0 0.0.0.127 # uses 25 for SMTP deny tcp any any deny udp any any permit ip any any ! interface serial0/0/0 ip access-group eacl02 in
Possibly Complete Answers; Adds Matching for TCP, UDP, IP
Finally, regarding OSPF and ARP, to restate, ARP does not use IP, so an IPv4 ACL will never filter an ARP message. However, OSPF uses IP; the OSPF messages are encapsulated directly into IP packets, using IPv4 protocol number 89. And when an OSPF message arrives in R1’s S0/0/0 interface, R1 would consider that packet based on the IPv4 ACL as configured, possibly denying (filtering) the OSPF message/
With the latest configuration, those OSPF packets would be permitted already, due to the ending permit ip any any command at the end of the ACL. However, you could have matched it explicitly in a couple of ways. You could have matched on the common destination IP addresses used by OSPF (224.0.0.5 and 224.0.0.6), or by matching the IPv4 OSPF protocol number by using protocol number 89, or by using the ospf keyword (permit ospf any any).
ip access-list extended eacl02
permit tcp 172.16.3.0 0.0.0.31 eq telnet 172.16.1.0 0.0.0.127
permit tcp 172.16.3.0 0.0.0.31 eq 80 172.16.1.0 0.0.0.127
permit tcp 172.16.3.0 0.0.0.31 eq 25 172.16.1.0 0.0.0.127
=============================
permit ip any host 224.0.0.5
permit ip any host 224.0.0.6
or
permit ospf any any
or
permit 89 any any
=============================
deny tcp any any
deny udp any any
permit ip any any
I know this question might be a bit out of scope for this post, but If the above lines for OSPF are correct alternatives…how would I know how limit the OSPF advertisements from only the specific Routers…
Would it only matter the physical directly connected neighbor or do you have to specify each neighbor?
permit 89 172.16.23.0 0.0.0.7 host 224.0.0.5
permit 89 172.16.23.0 0.0.0.7 host 224.0.0.6
permit 89 172.16.12.0 0.0.0.3 host 224.0.0.5
permit 89 172.16.12.0 0.0.0.3 host 224.0.0.6
Thanks!
Yep. If the goal was to limit to certain neighbors, yes, that ACL logic would work. However, that might break OSPF. Normally, all OSPF routers attached to the same subnet would need to be able to become neighbors. Or, in some WAN cases, when they were not, you’d have to build in some design features by which only a certain limited set of routers (at the hub sites) could become the DR or BDR. Certainly stuff beyond CCNA.
Would it be needed to specify each neighbor or just the physically connected Router for the OSPF?
permit 89 172.16.23.0 0.0.0.7 host 224.0.0.5
permit 89 172.16.23.0 0.0.0.7 host 224.0.0.6
permit 89 172.16.12.0 0.0.0.3 host 224.0.0.5
permit 89 172.16.12.0 0.0.0.3 host 224.0.0.6
Thanks!
Nah, the permit ospf any any would be plenty good if the idea is to permit all incoming OSPF packets.
Hi Wendell,
I just did this ACL drill and wantd to check the answers here. I was surprised that all of the ACLs involves the subnet 172.16.3.0, the LAN off R3. But on the diagram it is also listed as R2. Which is completely logical, but on the diagram I saw R2 (to which the server is connected) so I searched the table for R2’s subnet which is 172.16.2.0.
Also, shouldn’t the ports be the source ports in this scenario? But I think i could be completely wrong here.
Hi Daniel,
My mistake. Just noticed today per another comment that I have some errors in naming the routers. I’m sure that’s the issue with the confusion between your answer and what’s listed here. Let me take a look real quick and fix it. Thanks for the comment.
Wendell
Daniel,
After further review, if you treat the far right-side router as R3, and it’s LAN subnet as the subnet where the server (S) sits, that should match up well with the sample answer. However, for the inbound ACL answer on router R1, given the assumptions you made, you can still compare your logic to what’s in the same answer – should be very similar, other than the subnet numbers.
Wendell
Wendell,
Thank you for your reply. I’ve overcome the subnet question, but I think found another problem. In the partial answer you listed the acl statements with the ports being the source ports, according to your explanation above that. And I think this is the right answer as the directon of the packets is from the server to the host (right to left), with the servers originating the packets.
In your final answer however, you list the statements with ports being in the destination section.
So which is the right one?
Daniel
Hi Wendell, I think there is a mistake on the completed answer. I think you inverted the permit line instead of using :
permit tcp 172.16.3.0 0.0.0.31 eq 23 172.16.1.0 .0.0.0.127
you used
permit tcp 172.16.1.0 0.0.0.127 172.16.3.0 0.0.0.31 eq 23 # uses 23 for Telnet.
Hi Wendell
First off, I want to thank you for taking the time to share this with us, it is an invaluable work and it is been very helpful for me.
I noted that the ACL allocation is in the int the R1’s int S0/0/0 but I was wondering if the most recommended allocation would be closer to the source of the packets, avoiding R3 to process this information.
Luis Mario
Hi Luis,
You’re welcome!
I agree, if choosing for good design practices, “as close to the source as possible while avoiding unintended consequences” is the best rule. Definitely a goal in real networks.
Hello,
Midou is right, the ACEs source/destination “addresses wildcard” in the second part of the answer are inverted.
The “partial answer” is correct but the “Possibly Complete Answers; Adds Matching for TCP, UDP, IP” is not.
Hi Nicholas,
Yep, you’re right. I just swapped the address fields. Thanks!