Distributing Firewall Services Among Hypervisors
Virtual computing changes the compute operational landscape by introducing a software abstraction layer. All physical compute components (NICs, CPU etc) get bundled into software, managed as software objects, not as individual physical components. Virtualization offers many benefits in the agility and automation arena but its full capabilities are hindered by statically provisioning network functions. Server virtualization allows administrators to spin up a VM in seconds (Containers – 250ms) yet it potentially takes weeks to provision the physical network to support the new VM. The compute and network worlds lack any type of symmetry, however, their combined service integration is vital to support the application stack.
Network virtualization creates a similar abstraction layer to what we see in the compute world. It keeps the network in line with compute in terms of agility and automation. Network services including Layer 2 switching, Layer 3 routing, load balancing and firewalling now become a service available in the software. Moving physical to software changes the operational landscape of networking to match that of compute. Both compute and network are now decoupled from the physical hardware, meaning they can be provisioned at the same time.
Initially, we started to abstract network services with the vswitch installed on the hypervisor. It was very basic and could only do simple network services. There was no load balancing or firewalling. Now, with recent network virtualization techniques we introduce a lot more network services into software. One important service enabled by network virtualization is distributed firewallIing. The distributed model offers a distributed data plane with central programmability. Rules get applied via a central entity so there is no need to individually configure the vNIC. The vNIC may have specific rule sets but all the programming is done centrally.
VM mobility is very limited if you can’t move the network state with it. Distributing the firewalling function allows the firewall state ( connections, rule tables etc) to move with the VM. Firewalls are now equally mobile. Something 10 years ago I thought I would never see. As a side note, docker containers do not move like VM’s do. They usually get restarted, very quickly with a new IP address.
Distributed Firewalling – Spreading Across The Hypervisor
Traditional security paradigms are based on a centrally focused design; a centrally positioned firewall device, usually placed on a DMZ, intercepts traffic. It consists of a firewall physically connected to the core and traffic gets routed from access to the core with manual configuration. There is no agility. We had a lot of firewalls deployed on a per application basis but nothing was targeting east to west traffic. As you are probably aware, the advent of server virtualization meant there was more east to west than north to south. Traffic is staying in the data center so we need an optimal design to fully inspect it. Protecting the application is obviously key but the solution should also support automation and agility.
Physical firewalls lack any type of agility. They can’t be moved. If a VM moves from one location to another the state in the original firewall does not move with the VM. Resulting in traffic tromboning for egress traffic. There are hacks to get around this but they complicate network operations. Stretched HA firewall designs across two data centers is not recommended as a DCI failure will break both data centres. Efficient ingress traffic should be fixed with proper application architecture and DNS-based load balancing.
We are in the world of multi-tenancy and physical devices are not ideal for multi-tenant environments. Most physical firewalls offer multiple contexts but the code is still shared. To properly support multi-tenant cloud environments, we need devices that were originally built in mind to support multi-tenant environments. Physical devices were never built to support cloud environments. They were evolved to do this with VRFs and contexts. We then moved on to firewall appliances in VM format. They offer slightly better agility but still suffered traffic tromboning and a potential network choke point. Examples of VM based firewalls include vShield App, vASA and vSRX Gateway. There is only so much you can push into software. Generally, you can get up to 5 Gbps with a reduced feature set. I believe Paolo Alto can push up to 10 Gbps. Be sure to check the feature parity between the VM and corresponding physical device.
Network evolution now offers distributed network services among hypervisors. The firewalling function takes a completely different construct and is embedded as-a-service in the hypervisor kernel network stack. All hypervisors become one big firewall in software. There is no longer one single device to manage and we have a new firewall-as-a-service landscape. Distributing firewalling offers a very scalable model. Firewall capacity is expanded along with the addition of extra hypervisors offering a scale-out distributed kernel data plane. Essentially, the distributed firewall performance scales horizontally as more hosts are added. Distributed firewalling is similar to connecting every VM directly to a separate firewall port. An ideal situation yet impossible in a physical world. Now, that the VM has a direct firewall port, there is no traffic tromboning or network choke points. All VM ingress and egress traffic gets inspected statefully, right at the source and destination, not at a central point in the network. This brings a lot of benefits, especially with the security classification.
Security – Decoupled From IP Addressing
In the traditionall word, security classification was based around IP-address and/or port number. For example, we would create a rule that source IP address X can speak to destination IP address Y on port 80. We had to use IP as a security mechanism because the host did not have a direct port mapping to the firewall. In order for the firewall to depict where traffic is sourced and destined, it had to use IP address as the identifier. This is no longer the case with distributed firewalling. Security rules are completely decoupled from IP addressing. A direct port mapping from the VM to the kernel based firewall permits classification of traffic based on any arbitrary type of metadata; objects, tagging, OS type or even detection of a certain type of virus/malware.
There are many companies out offering distributed firewalling, VMware with NSX is one of them and have released a VMware NSX trail allowing you to test for yourself. NSX offers Layer 2 to Layer 4 stateful services by means of a distributed firewall running in the ESXi hypervisor kernel. The distributed firewall is installed in the kernel by deploying the kernel VIB – VMware Internetwork Service. The package is installed by NSX Manager via ESX Agency Manager (EAM). The VIB gets initiated and the vsfwd daemon is automatically started in the user space of the hypervisor.
Each vNIC is associated with the distributed firewall. As mentioned, we have a one to one port mapping between vNIC and firewalls port. Rules are directly applied to VM and the enforcement point is the VM virtual NIC – vNIC. The NSX manager sends rules to the vsfwd user world process over the Advanced Message Queuing Protocol message bus.