This virtualization thing is not reserved for servers or desktops. There are virtualization concepts in the network world. Segmenting a switch with VLANs is one example. Another example is virtual IPS sensor where we can have up to four virtual sensors within a single appliance. Finally, we have a concept of virtual firewalls with the ASA: we could have many virtual firewalls, also called contexts, in one physical appliance. This is what we are going to deal with in this blog.
With the ASA box and a valid license we could have several virtual firewalls inside the ASA and each of them is configured and maintained separately. For instance, a service provider could have 10 clients that need similar security policy that could be met with an ASA. Why would ISP buy 10 appliances when they could buy only one, carve out 10 logical firewalls and assign each organization’s admin a control over their respective firewall? Of course we, as admins in the ISP itself, would have another, 11th virtual firewall to manage the whole system.
Now before we yell a “yeeeeee!” there is one thing we need to have in mind: some features that, in my opinion, are absolutely a must-have, are not available in this deployment:
- there is no VPN support of any kind
- no routing protocols
- no QoS
- no multicast (this one – I could live without )
One would say that those features should be separated from a firewall feature in a first place. Well, I will leave this for a debate. I’m pretty sure these features will be available some day in a virtual environment.
Let’s take a look at this diagram:
This is common way of implementing virtual firewalls. We can see that there is one physical ASA device with two virtual firewalls or contexts. There is a 3rd context called admin context, but that one is for us, not the customers.
Customer1 has a router and who knows what else behind it and that router is connected to our ASA. Physical of course. We then assign this interface (or subinterface) to one context. This is the inside part. The ASA is connected to border router and to the Internet over it.
Same goes with Customer2.
Now admin from Customer1 can connect to his/hers firewall, and set it up the way he/she wants. They don’t even know that they are in the virtual world! Same goes for Customer2. If they want to allow access to each other it’s ok. They agree on a security policy and implement it. We (as SP admins) don’t care. As long as everything in the physical world is ok, of course.
Now a little bit about technical stuff… Most often our firewall is in a single mode. We need to switch mode and reboot appliance. This is what happens when we do so: current running config is saved on flash in old_running.cfg file. This is if we wanted to go back to a single mode. The running config is split into two parts:
- System execution space
This holds configuration part such as enabling/disabling interfaces, speed and duplex, boot commands, failover, …. This is where we fall in when connect to an ASA via console prompt. From this space we create and initialize all other contexts, including admin context. This part of config is stored in NVRAM.
- Admin context
Admin context holds network related stuff: IP addresses, nameifs, syslog servers, AAA servers, routes, … Our physical ASA uses this context to talk to the outside world. This part of config must be stored locally, on a flash in a file called, say, admin.cfg.
- Customer context
This is not a part of a current running config but rather created by us from within a system execution space. All commands related to customer security policy are typed in by a customer admin, and are stored in a separate file named, say, Customer1.cfg. This file can be stored locally or somewhere on the network. If stored on the network, the ASA uses admin context to fetch a context file.
Ok, so far we were writing, but in the next blog we will be typing. We will use the diagram from above to make all this stuff happen. Stay tuned…