Basics of Access Control Lists

[David Damerjian]

This purpose of this article is to explain the basics of implementing Access Control Lists (ACLs) for subscribers and interfaces, how to troubleshoot them, and to point out the most important gotchas.

ACLs are used to control the flow of packets in and out of the system. If you are looking for more features such as the ability to track packet counts for certain types of traffic, then you may want to investigate the Enhanced Charging Service (ECS) feature, which itself still requires a basic use/knowledge of ACLs to redirect packets to the ECS module for further processing.

Working with ACLs involves specifying ACL name(s), adding rules or filters to them, and then applying them to any subscriber(s), interface(s), or context(s). The order that various ACL(s) gets applied to data flowing through the system is explained and pictured with a nice diagram in the chapter on IP Access Control Lists in the PDSN Admin Guide and there is no need to repeat it here.

So as to quickly show how simple implementing ACLs can be, here is a very simple example of an ACL definition and its application to a subscriber template.

ip access-list test-acl

            deny host 1.1.1.1

permit any

exit

subscriber name testuser                                  

            ip access-group test-acl in

            ip access-group test-acl out

exit

If applying at the interface level, substitute the commands in an interface instead of in a subscriber:

interface 18/1-PDN

            ip access-group test-acl in

            ip access-group test-acl out

            ip address 192.168.51.150 255.255.255.0

exit

When applying an ACL at either the subscriber or interface level, the direction MUST be specified, and if both directions are desired, then two separate configuration lines are required. The meaning of the directions is as follows, when applied to:

Interfaces – “in”: all packets coming into the chassis from the wire on that interface

                        “out”: all packets going out of the chassis on the wire on that interface

Subscribers – “in”: all packets coming in FROM particular subscriber(s)

                        “out”: all packets going out TO particular subscriber(s)

Context – “in” and “out” cannot be specified at the context level – there is no such concept

It is very important that an ACL be applied in the proper context. For instance, you might assume that applying an ACL in the source context (where the RP interface is located that communicates with the Radio Access Network (RAN) and ultimately the subscriber) to block subscriber traffic is valid, but it is not. The reason is is that subscriber traffic on the RP interface is encapsulated in GRE packets, and the ACL only examines the outermost packet, in which case it would potentially be analyzing the PCF and/or PDSN addresses which have nothing to do with the actual subscriber data contained in the packet. There may very well be a valid reason to apply an ACL at this level, understanding that it won’t be subscriber specific. As an example, you may want to filter certain types of packets coming from certain PCFs.

In the destination context though, there is no encapsulation of subscriber data as it leaves or enters an interface on the chassis, and so subscriber packets including source/destination ip address/port and protocol types can be analyzed and processed.

Applying a subscriber ACL has one more twist. The subscriber template will need to be defined in both the source and destination contexts. It is in the source context that the ACL is actually assigned to the user, but it is in the destination context that the rules are actually defined and applied.

You can use Radius to return the ACL name to apply to a subscriber. The format is:

Filter-Id = {in | out}:<ACL name>

For example:

Filter-Id = in:test-acl

Filter-Id = out:test-acl

If you have configured things properly, when the call is up, run the command “show subscriber full username <test user NAI>” and look for the lines:

active input acl: test-acl                 active output acl: test-acl

Input represents the In direction and output represents the Out direction.

Also this command outputs the number of packets received from and sent to the subscriber along with packets dropped in both directions. In this example, 10 pings were dropped coming from the subscriber (and never sent out from the chassis to the destination)

input pkts: 10                         output pkts: 0        

input bytes: 680                       output bytes: 0          

input bytes dropped: 680               output bytes dropped: 0        

input pkts dropped: 10                 output pkts dropped: 0

Adding rules to the ACL is fairly straightforward, and both the PDSN Administration Guide, chapter “IP Access Control Lists”, and the CLI Reference Guide, “ACL Configuration Mode Commands” explain the usage of the various commands available for doing so.

Two of the simpler commands that may not be completely clear are:

{deny | permit} host source_address

{deny | permit} host source_address source_wildcard

These are essentially shortcut commands and they only apply to the source IP header field of a packet, NOT to the destination IP header field. If you want to apply a rule based on the destination IP header field (and you don’t care about the source IP field), use one of the other available commands and simply use the “any” keyword for the source. An example would be: “deny log ip any 192.168.51.200 0.0.0.0 protocol 1”

This would deny ICMP packets of any source and a destination of 192.168.51.200.

Some of the commands require standards knowledge of protocol numbers as in the previous example. You can find this information at http://www.iana.org/ as it is not covered in the manual and may change as the standards do.

The most important thing to remember about ACLs is that there is an implicit “deny any” at the end of the ACL. So, you need to add a “permit any” at the end, otherwise any packets that did not match any of the rules will end up being denied. Also remember that by default a new rule is always added at the end, and so you may want to use the “before” and “after” keywords to insert rules where you want, otherwise you can completely delete the ACL and re-add it and all the properly ordered rules all at once with a copy and paste operation.

Another keyword that is useful for troubleshooting is “log”. By adding this keyword, monitor subscriber traces will show when a packet meets the criteria of an applied ACL. The logs can also be viewed by executing the logging filter active facility acl-log command and to start logging with logging active in the system’s Exec mode. Here is an example of a monitor subscriber log message for the example ACL rule mentioned just above:

INBOUND>>>>> 17:21:59:901 Eventid:25000(0)

PPP Rx PDU (72)

IP 72: 20.20.20.133 > 192.168.51.200: icmp: echo request (ttl 64, id 1, len 68)

INBOUND>>>>> 17:21:59:922 Eventid:21050(4)

Input ACL match found (ACL Name : test-acl) (68)20.20.20.133 > 192.168.51.200: icmp: echo request (ttl 64, id 1, len 68)

Imported from Starent Networks Knowledgebase Article # 10420