Understanding Wildcard Masks

Introduction to Wildcard Masks
Before I begin, I should mention how important it is that you have solid binary to decimal and decimal to binary math skills.  In order to develop these masks (and understand them) at the the fastest speed possible, you need to know your math.  So if you are weak in this area, now would be a good time to practice!  Cisco has a binary math game on the Cisco Learning Network.  You can find it here, but note that you will need a Cisco login and username.  If you aren't on the Cisco Learning Network, I highly encourage you to sign up! They have great study resources and places where you can ask questions on concepts that you don't understand.


Wildcard Mask Logic
When you write an ACL statement, you identify the addresses that you want to either deny or permit access to by matching it with a wildcard mask.  The logic behind comparing an IP address with the mask is this:

• For each 0 in each octet of the wildcard mask, the IP address that is being compared against the network statement must match in the corresponding octet.
• At the binary level, each 0 must means the IP address binary must match the corresponding bit value of the network statement
• Anything other then zero indicates the acceptable range of IP addresses that do not have to match the network statement
• At the binary level, each 1 means that the IP address binary does not have to match the corresponding bit value of the network statement

It's likely that you may be confused after reading these "rules".  If so, write these down or copy and paste them into a file and compare the rules against the following examples as you go through them.

Also, before I get started with these, understand that there are shortcuts to creating wildcard masks, and once you get good at it, you can write them out much faster then breaking it down into the binary.  The problem is that if you don't understand what is happening at the binary level, you will really be missing out, especially when it comes to creating some more..interesting ACL statements (I'll throw in one at the bottom of this post).

Example 1
The following ACL would match any host with a source IP from the network 10.0.0.0/24 and apply the "deny" action, preventing the traffic from passing through the interface

deny ip 10.0.0.0 0.0.0.255

IP address 10.0.0.1 would match this statement.  Why?  Lets look at this at the bit level

wildcrd mask:  00000000.00000000.00000000.11111111

network addr: 00001010.00000000.00000000.00000000

ip address    :  00001010.00000000.00000000.00000001

In green, I have highlighted the bit values that must match, given the wildcard mask.  As you can see, the IP address will be matched as long as the bit values in the first three octets are the same-or the address begins with 10.0.0.X  and the fourth octet, as the wildcard mask is all 1's here, can be any value.  So network addresses 10.0.0.1-10.0.0.255 will be matched.

Excercise 1

Lets try a basic wildcard mask excersise.

Determine the range of addresses that will be matched and denied by the following ACL statement. 

deny ip 192.168.0.0 0.0.1.255

Begin by breaking down the network statement and wildcard masks down into binary.  Determine which bits must match, and which do not.  Finally, do the math on the bits that do not have to match to determine the acceptable range of addresses that will be matched by this statement.  When you think you have it, jump down to see the answer!

Excercise 1 answer: Addresses 192.168.0.1 - 192.168.1.255

Start by breaking down the network statement (192.168.0.0)  and wildcard mask (0.0.1.255) into their associated bits.

    mask : 00000000.00000000.00000001.11111111

network: 11000000.10101000.00000000.00000000

Now that you have your mask and network in binary form, you know which bit values must match.  Here, you can see that the address must at least be 192.168.X.X  for the first two octets.  The third octet can be confusing when you are doing this for the first time.  The wildcard mask is a 1 for the 8th bit value of the third octet.  Remembering the previous rules, you know that a "1" value means the mask does not check this bit.  Therefore, the bit can either be on or off, and the remaining octet is entirely composed of 1's.  Therefore, the acceptable range of possible network addresses is 192.168.0.1-192.168.1.255

Excercise 2: Determine if an Address will be matched

Given the following ACL statement, determine if address 192.10.16.224 will be matched

deny ip 192.10.0.0 0.0.15.255

Solve this by taking your network statement, wildcard mask, and IP address, and breaking them down into binary.  When you think you have the answer, jump down to check and see an explanation

Answer: No, because the range of addresses that will be matched is 192.10.0.1-192.10.15.255

Begin by breaking down your addresses into bit values.

mask:    00000000.00000000.00001111.11111111

network:11000000.00001010.00000000.00000000

address: 11000000.00001010.00010000.11100000

Now you see that when you break it down into binary, how simple the wildcard masks really become. As an added bonus, by repeating this practice, you get to improve on your binary to decimal math skills-a skill that in my opinion, is essential if you want any chance at passing the CCNA. In this above example, the "1" value in the address in the fourth digit of the third octet, does not match the mask!  According to the mask, that value must be a 0.  Since it is not, the address will not be matched and will be ignored.  How did I determine the acceptable range?  Math-you can see that the "1's" begin in the fifth digit of the third octet.  This place has a value of 8.  8+4+2+1 = 15.  So you know that in the third octet, the acceptable values are 0 through 15.  The fourth octet is composed entirely of 1's and is ignored by the mask.  Therefore, your acceptable range is 192.10.0.1-192.10.15.255

Shortcuts..

Some of you may be aware of a few shortcuts.  An example of one, is that the wildcard mask itself is the upper most limit of the value in each octet that can be matched.

0.0.15.255

is the same as our range 192.10.0.1-192.10.15.255

However, now I will show you the problem with relying entirely on shortcuts.  Lets say you have a network

10.0.0.0 and you want to only match IP addresses with an even number (maybe you have an eccentric networking scheme and all of your hosts have an even IP address).  So, you only want to match IP addresses 10.0.0.2, 10.0.0.4, 10.0.0.6, and so on.  How do you determine this?  Unfortunately, the shortcut method, will not work here.  You need to understand how this works at the bit level.  Breaking it down, you can see how you would perform this task:

mask:     00000000.00000000.00000000.11111110

network:00001010.00000000.00000000.00000000

Because the last value of the fourth octet must be turned "off", mathematically, you cannot have any odd numbers!  So, any IP address in the 10.0.0.X network with an even number in the fourth octet will be matched.

I find that the shortcuts can be handy-as long as you fully understand what is taking place when you apply them.  In my experience, if I rely only on the shortcuts, I tend to forget what is taking place, and I don't keep my understanding of the matching logic as sharp as I need to.  You can find a number of these shortcuts in other tutorials, but the only other one that I sometimes use is what I term the "magic number - 1" shortcut.  Say for example you wanted to build a wildcard mask that would block addresses in the 10.0.0.1-10.0.0.3 range.  You know that by looking at this range, this would be a /30 address.  The "magic number" (or incremental value) of a /30 is 4.  Subtract one, and you would get the value you would need for your wildcard mask, or 0.0.0.3.  At the binary level, we know this is true, because if you add the values of the last two bits together, you get 3.  So the mask 0.0.0.3 will match addresses 10.0.0.1, 10.0.0.2, and 10.0.0.3.  You know it won't match 10.0.0.4 and up because the values of those bits must be equal to 0 in order to be matched by the wildcard logic.

An Introduction to ACLs

Before I post up the lab, I'm going to cover some important topics in a series of posts:

• 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