The Problem: You’re setting up inter-VLAN routing on your Cisco ASA firewall (5510, et al) using sub-interfaces. There should be no restrictions on what traffic can flow where between the internal VLANs, so you’ve set the same security level on all of the sub-interfaces and have added the configuration command(s) to allow “same security” traffic to move freely.
Should work like a champ, right? Not so fast! Things never work quite as planned when we’re talking about Cisco’s powerful but often frustrating line of firewalls.
When you use a separate internal router for inter-VLAN routing, this type of setup is sometimes referred to as a “router on a stick”. But as pointed out in an earlier blog post more and more small and mid-sized companies don’t want to spend the money on an extra router (or have an extra point of failure), so they’re just using their ASAs to do the inter-VLAN routing.
The main difference here is that the ASA is also the gateway out to the Internet, which means that it performs NAT. Another difference is that Cisco still hasn’t made the inter-VLAN routing implementation very user-friendly on ASAs. But it does work if you know how to set it up.
The Solution: From a technical standpoint, the main issue here is that the ASA also does NAT whenever inside traffic connects out to anywhere else. You might think that it would know to keep the same addresses when traffic flows from one VLAN-assigned same-security interface to another, but it doesn’t. You have to add static commands for every possible subint-to-subint (vlan-to-vlan) interconnection and specifically tell it to use the same addresses before and after NAT. See below for an actual configuration.
Configuration: Here’s a typical configuration for setting this up on an ASA 5510, along with some comments.
Let’s say that you are routing for 3 different VLANs via sub-interfaces on the physical E0/0 interface. The base configuration on the ASA looks something like this:
no ip address
ip address 192.168.2.1 255.255.255.0
ip address 192.168.3.1 255.255.255.0
ip address 192.168.4.1 255.255.255.0
description Primary Internet
ip address 22.214.171.124 255.255.255.0
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface
global (outside) 1 interface
nat (inside) 1 192.168.2.0 255.255.255.0
nat (wireless) 1 192.168.3.0 255.255.255.0
nat (servers) 1 192.168.4.0 255.255.255.0
Note the two same-security-traffic statements that allow traffic to flow between and within interfaces and sub-interfaces that have the same security level. This prevents you from having to add access lists, but that’s about it.
Inter-VLAN routing won’t work with the above configuration as is. You might think you could just add some additional globals for the sub-ints, but that also won’t do the job with this setup. What you need are a series of static entries, basically telling it not to NAT traffic between the various sub-ints (actually, it does NAT them, but keeps the same IP address before and after). You’ll need a separate static for each subint-to-subint (vlan-to-vlan) connection. For each one, the first sub-int specified is the one whose IP network you need to enter twice in the static statement.
For example, to get the above configuration to work, you would add the following:
static (inside,wireless) 192.168.2.0 192.168.2.0 netmask 255.255.255.0
static (inside,servers) 192.168.2.0 192.168.2.0 netmask 255.255.255.0
static (wireless,inside) 192.168.3.0 192.168.3.0 netmask 255.255.255.0
static (wireless,servers) 192.168.3.0 192.168.3.0 netmask 255.255.255.0
static (servers,inside) 192.168.4.0 192.168.4.0 netmask 255.255.255.0
static (servers,wireless) 192.168.4.0 192.168.4.0 netmask 255.255.255.0
Once you get those statics in there, inter-VLAN routing will work just fine. But it’s a bit ugly, isn’t it?!? For N number of VLANs, you need (N-1) x N of these statements, so for just 5 total VLANs you need 20 of them.
Discussion: Cisco needs to re-think the way that ASAs work in terms of VLANs and routing. It would be great if they realized how their devices are actually being used out in the field, and put some thought into making things more user-friendly. Who are the actual end users of Cisco gear? The people using the network to check their friends’ Facebook statuses, or the people who actually have to install this gear and administer it on a day-to-day basis? The correct answer is both, but you sometimes get the sense that Cisco only cares about the former.
At the end of the day, this type of extra configuration is not really a huge deal, but it’s the type of thing that can throw you for a loop and make your work-day seem longer than it should. The good news is that, once you get it working, it works well. And it’s nice to eliminate that separate router and do things on the ASA instead.