Applying Access Lists to Interfaces

After an access list has been created, it ultimately needs to be applied to an interface in order to filter traffic. Access lists can be applied in one of two ways – inbound or outbound. Differentiating between the two and understanding both is critical.

Inbound. When an access list is applied to an interface as inbound, the access list is evaluated when a packet attempts to enter that interface. In other words, an inbound access list controls which types of traffic are allowed to enter the router through that particular interface.

Outbound. When an access list is applied to an interface as outbound, the access list is evaluated when a packet attempts to exit an interface. In other words, an outbound access list controls which types of traffic are allowed to exit the router through that interface.

I understand that the difference between configuring an access list as inbound or outbound can be a little confusing. It’s actually easier to understand with an example. Consider the figure below. In it, our router has three interfaces (E0, S0, and S1), each connected to a different network. For the purpose of illustration, I’m going to add one very simple access lists to the router, on interface E0.

Figure: Router connecting three networks, with an outbound access list applied to interface E0.

Notice that the access-list is applied as an outbound access list on interface E0. It denies access to hosts from network 192.168.15.0/24, and permits all other traffic.
Let’s look at the impact of this outbound access list. It specifies that traffic from hosts on network 192.168.15.0/24 should be denied. The steps below outline what will happen when host 192.168.15.30 attempts to communicate with a server on network 192.168.35.0/24.

1. Host 192.168.15.30 will recognize that the server it wants communicate with is on a remote network, and will forward packets its default gateway, router interface S1.
2. The router will use its routing table to determine that these packets should be forwarded out interface E0.
3. Recall that interface E0 has an outbound access list applied. It will be evaluated for all packets that attempt to exit interface E0. In this case, the source address of the packets (192.168.15.30) matches the first rule specified, and according to the access list, the packets are dropped.

In this case, the access list isn’t evaluated until traffic tries to exit interface E0. Had a host on network 192.168.25.0 attempted to access a server on network 192.168.35.0, it would have been permitted to pass through the outbound access list. It would not have been affected by the first rule, while the second rule permits all other traffic to pass.
However, this outgoing access list does a little more than just stop systems on network 192.168.15.0 from initiating communications with hosts on network 192.168.35.0. For example, if a host on network 192.168.35.0 attempted to communicate with a server on network 192.168.15.0, the following would happen.

1. Host 192.168.35.16 would recognize that the host it wants communicate with is on a remote network, and would forward packets via its default gateway, router interface E0.
2. The router will use its routing table to determine that these packets should be forwarded out interface S1. Note that the access list on E0 didn’t apply – these packets are entering, not exiting, interface E0. The access list is outbound only.
3. The packets will reach the server at 192.168.15.200, who will send a reply. The reply will reach the router, who will check its routing table, and determine that the packets are to be forwarded out interface E0.
4. Unfortunately, because the source address in the reply is coming from network 192.168.15.0, the router will drop the packets, since the outbound access list denies traffic from network 192.168.15.0, according to the first rule.

As you can see, even one simple access list can have many repercussions. The outbound access list applied to interface E0 stopped traffic from network 192.168.15.0 from reaching network 192.168.35.0. However, this means that all traffic with a source address of 192.168.15.0 is blocked, even when it’s a reply from a request that originated on network 192.168.35.0.

Going a step further, let’s add an inbound access list on interface E2. The access list will also include two rules. The first will deny hosts on network 192.168.25.0 from accessing telnet services on any network, while the second will permit all other types of traffic to pass, as shown in the figure below.

Figure: The inbound access list on interface S1 denies telnet traffic from hosts on network 192.168.25.0/24, but allows all other traffic.

In this example, imagine that host 192.168.25.99 tries to initiate a telnet session with Server A.

1. Host 192.168.25.99 will recognize that Server A is on a different network, based on the destination IP address. It will send the packets to its configured default gateway, interface E2.
2. Since traffic is attempting to enter interface E2, the inbound access list will be evaluated. In this case, the first rule specifies that any telnet traffic originating in network 192.168.25.0/24 should be denied. The router will drop the packets immediately.

Even though telnet traffic is denied via the inbound access list, all other traffic is still allowed to pass. If host 192.168.25.99 attempted an HTTP connection with ServerA, the rules in the access list would be evaluated. The first rule wouldn’t apply (since this isn’t telnet traffic), and the second rule permits all other traffic to pass. Again, recognize the importance of that second rule – if it didn’t exist, all traffic from network 192.168.25.0/24 would be denied. While the first rule denies telnet traffic only, without the second rule, the implicit “deny all” at the end of the access list would stop all traffic from network 192.168.25.0/24 from being allowed to enter interface E2. If that’s your goal, it’s probably a better idea to just shut down the interface. Both would have the same end result. Every access list requires at least one permit statement to do anything useful.

For any interface (or subinterface), only one inbound and outbound access list can be applied per protocol. In other words, an interface could have one IP and one IPX access list applied inbound, and one IP and one IPX access list applied outbound. You could not have 2 IP access lists applied inbound on the same interface. However, you can have multiple access lists associated with a single physical interface through the use of subinterfaces. For example, an inbound IP access list could be applied to both interface s0 and interface s0.1.

Tip: For any interface (or subinterface), only one inbound and outbound access list can be applied per protocol.

One important note before we actually begin implementing access lists. Any access lists applied to interfaces will not impact traffic that originates from the router where the access lists are defined. For example, configuring an outbound access list that denies telnet traffic will not deny a telnet session initiated from the router from leaving that interface.