Over the last decade we have seen the increased footprint of physical firewalls. Audits and compliance require traffic isolation, segregation, and application tiers to meet the check boxes. This has seen a vast sprawl of the data centre firewall. Such sprawl has been to the collective moan of networking and security administrators. It also is felt the most in IT departments capital expenditure budgets. The firewall as evolved from a simple packet forwarding device with some layer 3 and 4 services to integrating IPS and IDS functionality, application and user authentication, and becoming an integral layer for full stack security. No longer are we bound to the physical box anymore. The firewall administrators and network architects now have the tools to collapse the footprint of the early 2000’s desire to place physical devices everywhere.
The issue that has arisen is that no one box can do it all. No device can filter traffic, provide IPSec route-based VPNs, provide application identity, and consume a vast amount of sessions at the same time. Firewalls were clustered to perform a function or a service within the data centre. North/South traffic was passed via the DC edge to allow user access whilst East/West would pass via a transparent firewall – especially between database and web app tiers.
Physical firewalls these days share their place with virtual appliances within the enterprise network. Within the virtual platform of VMware or HyperV, firewall companies have developed in hypervisor solutions. The section below provides an overview of the firewall types and what should be considered:
- Routed firewalls are the standard firewall out of the box. Performing L3 routing, NAT, VPN, and many other features, this device is the most familiar for many readers. Routed firewalls provide a great service in the internet edge and can serve as a potential termination point. Generally deployed in little clusters or HA pairs protecting the enterprise at multiple places is the perfect use case for routed firewalls. NAT, VPN termination, IPS features, and DMZ functionality play to the use case of routed mode.
- Transparent firewalls operate at the data-link layer and are affectionately known as the bump-in-the-wire firewall. Designed to be transparent – hence the name – the firewall does not modify L3 headers unless NAT is involved. It can inspect packets and filter based on L3 parameters and acts as a firewall in that regard. There are a few caveats and software limitations that should be compared before a transparent solution is chosen.
Virtual firewalls are delivering in many methods. Traditionally x86 would not allow fast enough processing with the exiting grunt we had. Software has fixed a lot of things – it will only take time before software can deliver at line rate performance of merchant silicon and even the custom ASICs. Only until recently has the industry been able to gain stable purchase on software and realised strong competitive advantages.
- Hypervisor VM’s such as the vASA, VSG, vSRX provide a virtualised firewall that tenants, VMs, and customers can use. Inside the hypervisor allows far more flexibility. If designed in such a way, VM’s no longer need to leave a virtual environment for L3 termination, firewall checks, or load balancing as this can be done inside the hypervisor.
- Multi-context firewalls allow abstraction of the physical firewalls. Through partitioning the firewalls physical resources akin to server virtualisation a context can be assigned to a function or customer . This allows execution of business rules such as isolation, compliance, or design constraints.
- Multi-mode allows further extension of multi-context insofar as to assign a firewall mode to each context. Tradition dictated that if one context was assigned a mode, all contexts must be that mode. This would mean you would have a firewall cluster or HA pair executing on function only with the benefit of different business rules in each context.
- Recently advances have allowed multi-context multi-mode firewalls and has provided a boost in physical firewall functionality through abstraction and virtualisation. This allows expanded function and can accommodate the different requirements of a multi-tenant data centre.
Strong analysis of the business case, technical requirements, and how they are interpreted will lead a design to leverage the right technology for the use case. This will drive the desired outcome. It is important to consider not only the current state of the network now and the resolution of current issues but future migration paths, roadmaps, and how what you’re considering installing will help in delivering the future state architecture.