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!