- Introduction to ACLs
- Understanding Wildcard masks
- Standard and Extended ACL configuration
- ACL troubleshooting
- NAT configuration
Following these posts, I will tie everything in together in the lab.
So, what is an ACL and what does it do?
You might be asking, what is an ACL? ACL stands for access control list. It is a basic way of filtering traffic based on source and destination IP's, along with the type of traffic. Thinking in terms of firewalls, an ACL would be an example of a stateless firewall (excluding reflexive ACL's, but more on that later.) This means that this rudimentary firewall does not look at the "entire picture" of the conversation between two devices. The ACL only inspects each individual packet based on source, destination, and type. Stateful filters are considered to be more advanced because they are capable of reconstructing the "conversation" between two different devices. This will become easier to understand if you try the lab. Later on I intend to illustrate using a stateful firewall with this exact same topology, so it will be easier to see the differences between stateful and stateless inspection.
How does the router understand ACLs?
At the most basic level, a router uses an ACL to inspect a packet's header for the source IP, destination IP, and can then be further expanded on to match TCP and UDP port numbers and some other parameters. Depending on the statements in the ACL, the router either decides to discard the packet, or allow it to pass. The parameters as to what is to be inspected in the packet's header are configured in a series of ACL statements, which are processed in order of configuration. If the packet matches a statement, it is either filtered or it is allowed to pass through. At the end of every ACL is an implicit deny all statement-basically, if a packet comes into the interface, and does not match any of the statements, it will be dropped. This is important to remember.
ACLs can be used for several other purposes (such as defining NAT pools and QoS) but I am only covering IP ACL's in this overview. An IP ACL has two options if it matches a packet. It can deny the packet, and drop it, or it can permit the packet, and allow it to pass. We will use ACL's for NAT translation as well, but the concept is fairly similiar in that the permit keyword is used to instruct the router that matched packets are to be translated with NAT.
Placement of ACL's in terms of Direction
An ACL can be applied to a router interface either "in" or "out". This can be a slightly confusing topic at first, and it can trip people up. What this means is if you apply an ACL outbound on a router, the router inspects the traffic leaving that interface. If you apply an ACL inbound on a router interface, the router inspects traffic entering the interface. This may sound very simple, but its important not to overlook the placement of ACLs. When you actually start configuring ACL's and you need to determine where you have to place them this concept can get start to become very confusing.
Personally, I like to picture a brick wall in front of the interface. If I've applied the ACL inbound, I also picture a little arrow pointing towards the router. If its outbound, the arrow is reversed. It might also be helpful to draw this onto a piece of paper or whiteboard with your topology after you've configured the ACL's so you can keep track of what you've done and grasp the concept easier.
Example
To illustrate what I have covered so far, I am going to show a standard ACL statement. There are two main "types" of ACL's that can be configured- standard ACL's and extended ACLs. Standard ACLs filter based on matching the source IP address. Extended ACLs can filter based on source and destination IP, source and destination port, and a few other parameters as well. The placement of the ACLs varies depending on if it is a standard or extended ACL.
In this example, we have two routers, connected over the 10.0.0.0/30 WAN link. Lets say that we want to prevent PC1 from sending traffic to PC2. Using a standard ACL, best practice states to put a standard ACL on the interface closest to the destination you want to prevent traffic from reaching, An extended ACL should be placed on the interface closest to the source IP. The reason for this is fairly simple. If we put an ACL on R2's serial interface, or on one of R1's interfaces, we might prevent legitmate traffic from PC1 from reaching other destinations-either in R2's network, or perhaps, beyond R2. I've found that when it comes to configuring and troubleshooting problems with ACL's, where you've placed them, and what direction they are facing, tends to be the culprit of the problem.
To remember this, I think in terms of opposites: extended ---> close; and standard ---> far. So take a look at the diagram, and remember that you want to prevent PC1 from sending traffic to PC2, but you still want it to be able to communicate with any other device within R1's network and R2's network. Where would you place the ACL to accomplish this?
This is not the style that the entries are formatted in, but just to understand the concept, assume your ACL looks like this:
IF source = 10.1.0.100, deny
IF source = any, permit
Remember-the ACL processes the statements in order. So if the 10.1.0.100 entry is not matched, the packet will be allowed to pass through the interface
Analysis
If you decided the correct location is R2's fa0/0 port, facing outbound, then you would be correct. Putting the ACL anywhere else would not meet the requirements of this scenario. If you put the ACL inbound on R1's fa0/0 interface, you would cut off PC1 from it's default gateway (R1 10.1.0.1), and subsequently, the rest of the topology.
If you placed the ACL on R2's serial port, facing inbound, you would prevent PC1 from communicating with R2 and any other network attached to R2. You might wonder, what would happen if the ACL was placed outbound on R2's serial interface? Considering that the standard ACL checks only on source IP, nothing would be filtered in this instance. If PC1 pinged PC2, the packet would pass through R2 since the direction of the ACL is applied outbound. When PC2 replied to PC1's ping, the source IP is now 10.2.0.100. which would not match the pseudo entry "IF source = 10.1.0.100, deny".
To wrap things up, remember some of the points I made above
- Standard ACL's are placed as close to the destination as possible
- Extended ACLs are placed as close to the source as possible
- Draw it out at first, or do what you need to do to picture the inbound versus outbound placement of ACLs.
- There is an implicit deny all statement at the end of every ACL
No comments:
Post a Comment