More from less. We need more from less and to utilize efficiently what we have. It is almost a pillar of IT. In the firewall world, traditionally you had a handful on a 1:1 customer ratio. With contexts better utilization and consolidation can occur.
Firewall virtualization provides a way to create multiple firewalls inside a single physical device. A licensed, scaling feature, Contexts allow the application of unique security policies in a physical firewall. Customer A and Customer B of ISP A can utilize a hosted offering. ISP A can sell a firewall service where all they have done is created a context and assigned resources. Both customers are sharing ISP A’s physical firewall!
The context structure is broken up into three primary parts. The system context controls physical port assignments, context creations, and fail over information if required. The administration context is a landing point that allows the administration of the device. It serves as a management ingress to other contexts. Each virtual firewall is within the overall system context. Think inception!
It is important to remember that policy inheritance does not occur between contexts. This is important to note that this is due to isolation. A context doesn’t know about the other context by default. The system context will leverage the administration context for connectivity to the network. The system space is responsible for the creation of contexts.
A multi context deployment looks like this
mode multiple admin-context ADM-1 context ADM-1 allocate-interface Ethernet0/2 allocate-interface Ethernet0/3 config-url disk0:/admin.cfg context C1-CTXT allocate-interface TenGigabitEthernet0/8 C1-CTXT allocate-interface TenGigabitEthernet0/7 C1-CTXT config-url disk0:/C1-CTXT.cfg context C2-CTXT allocate-interface GigabitEthernet0/0 C2-CTXT allocate-interface GigabitEthernet0/1 C2-CTXT config-url disk0:/C2-CTXT.cfg
Treat them each as their own firewall. Unless you’re a serverhugger, you wouldn’t know the difference.
It is important to understand that there are some caveats. Major caveats to using transparent and routed mode with contexts. Before 8.5.1 you had to choose either transparent or routed. This meant no mixing routing and transparent. This impacted designs for much larger places. After 8.5.1 you could do per context modes which helped alleviate the issues. Before 9.0 you still could not use EIGRP, OSPFv2, OSPFv3, RIP, Multicast routing and Site to Site/Remote Access VPNs. 9.0 brought many improvements and reduced the caveat list to just OSPFv3, RIP, Mutlicast Routing, and Remote access VPNs. It is important to understand and be aware of such caveats when evaluating your requirements.
As VMware increased hardware usages and reduced wasted resources, ASA contexts do the same in the firewall space. Traditionally the requirements of transparent made contexts useless if you needed a router firewall too but with the 9.0 additions it is worth revisiting. Contexts in a Multi tenant or isolation centric environment may make life that little bit easier. After all, it is an ASA!
I’ve always seen contexts as a half way house between single context, multiple customer and dedicated firewalls for each customer.
The key is to use contexts for customers who don’t mind sharing infrastructure but have different security policies. I’ve seen people try to justify contexts for any multi-tenant platform, where the only difference between customers were the ACLs being applied, the argument being that each customers config is more manageable.
I always counter that using standards and baselines for configurations will negate that considerably.
Nice post.
Thanks Matt.
I agree with your comments regarding contexts. I think it is very important to understand what benefits contexts bring and where they are applicable. If you’re selling a product that has a shared instance then piling it all into a context is fine with me. Rules/virtualization/vlans/vrfs are all there to isolate customers from each other.
If you’re looking (now thanks to 8.5.6) to have many applications of the firewall such as a routed context/ transparent context then I think that is the way to go.
I suppose it all comes back to what you’re selling and what are the business drivers associated to it.