VNF, or Virtualized Network Function, refers to the process of virtualizing traditional networking and security functions into services. In practical terms, this means running several vendor products on the same physical hypervisor.  This allows you to have best-of-breed products while easily swapping out and adding services as necessary.

A rising trend has been to replace traditional routers and firewalls at the network edge with generic hardware running VNF’s on top of popular hypervisors. But as many enterprises are coming to realize, there are major tradeoffs they were not prepared for.

As someone who’s worked with some of the largest Telco’s and MSP’s in the world to build virtual CPE’s – these are some of the hard lessons learned along the way. 

I’m Andy with The CISO Perspective, and today we’re going to look at five considerations in virtualizing your network perimeter.

1.      Performance

You may already know you’re sacrificing some performance by going virtual as opposed to an appliance. But how much you’re sacrificing may shock you. First of all, vendor performance numbers are all but useless unless they are configured with your exact hardware and hypervisor configuration. There are just too many variations of hardware and software configurations to trust anything that wasn’t tested in-house. Even identical setups can vary in performance depending on how the hypervisor allocates resources at a given time.

A common mistake is to think you can simply throw more resources at the problem to make up for any gaps – but the increase is never one for one. For starters, vendors will usually charge per vCPU and/or memory. So while you may save money on a virtual license – you’ll quickly realize you need more CPUs than you would have on a dedicated appliance.

CPU reservation helps by dedicating cores to the firewall VM. And while this helps with the variability of CPU resources – the reality is that the firewall VM never gets full access to all the clock cycles for a given core. That’s why smaller firewalls with Atom processors and ASICs have beaten out octa-core Xeons in resource-intense inspections like SSL DPI.

2.      ASICs

ASIC stands for “Application Specific Integrated Chips.” They’re commonly developed and used by security vendors to offload various security functions. In short, the custom chips provide particular duties like IPS inspection, IPsec encryption, fireballing, and many more, depending on the vendor. This allows vendors to rely less on CPUs from AMD and Intel – and more on their own chips to provide better performance.

In some cases, you could have as much as 40 Gbps of firewall traffic going through a firewall with the CPU’s resource at 0%. This is because a firewall with an ASIC chip built-in wants to offload as much to its ASIC as possible. In fact, in some cases – only the first packet of a session is handled by the CPU while all other packets go directly or partially to the custom chip for processing.

Of course, when you move to the virtual world, the firewall is competing with the same generic CPU that all other VM’s on that server are fighting for. And with no ASIC to utilize – simple, mundane tasks must all go to the CPU.  That not only means more CPUs on your hypervisor but also a bigger license to purchase. This also means higher latency for certain packets that now have to travel higher up the stack than they would otherwise on a custom chip.

3.    Complexity

For all the issues around performance, this point might be the most important and the most overlooked. I’ve broken this section down into two sub-sections: pre-deployment and post-deployment

Pre-deployment is about getting your virtual FW to work inside your virtual environment. This includes things like:

Configure your hypervisor, firewall sizing, orchestration templates, and service changing if you’re using multiple vendors for your network perimeter and documentation. Because once you finally get all these moving pieces working, you’ll want to make sure it’s understandable and repeatable for other teams.

 In this most basic example, we’ve touched on 4 or 5 different skillsets and vendors. Whereas in the past, you only dealt with one security team or vendor – now you have your hypervisor vendor and orchestrator, which may or may not be the same as your hypervisor. Your templates need to have your desired firewall-config, and then you have to make sure the firewall vendor can pass traffic correctly to your wan optimization or sd-wan vendor if you’re service chaining.

4.      Troubleshooting.

Most seasoned networking or security engineers have gotten very good at troubleshooting routers and firewalls. But the new virtualization world brings on new layers of complexity that you have to account for.

For example, if a packet is not traversing your virtual box – did the vSwitch pass the traffic correctly? Does the hypervisor have the NACL enabled on the virtual NIC? Did the FW block it? Did the firewall pass it correctly to SD-WAN? Did SD-WAN route it properly? Did your hypervisor see that packet on the egress port? From a troubleshooting perspective, these questions are your new norm – and you now have to make sure you have a team that understands the flow of your solution – which could change if you decide to use another white box or virtual solution.

And speaking of the hypervisor, you now have this underlying software that needs to be patched and regularly updated – which is downtime and risk you need to account for in your new perimeter. 

5.      Policy Changes

What used to be routine policy changes can now become a nightmare if not managed correctly. What you used to be a simple firewall change can now become a change in 4 different locations: the hypervisor’s Network ACL, the security group attached to the vNIC, the firewall itself, and another service running on the box like the SD-WAN or Wan Optimization instance.

   But again, even in a basic deployment – you now have three different vendor configurations that need to be managed. That’s three management solutions, potentially three different IT groups, and potentially three different mistakes that can happen for any given change.

In larger organizations with SysOps, Security, and Networking teams – that’s potentially three teams that need to be involved in a basic change. And while you could use a policy manager with multi-vendor support to ease the day-to-day management, that now becomes another cost you need to account for.

Now, as we wrap up, I don’t want you to think that I’m telling you never to virtualize your firewall. There are several occasions where virtualizing your firewall is beneficial or required. There are, however, unrealistic expectations of firewall performance in a virtualized environment, and the lessons in this article cost many telco’s and MSPs millions of dollars to find out.