VMware NSX – Network and Security Virtualization

PacketPushers has some great sessions on VMware NSX. They are all pretty recent and I recommend you take a look – PQ VMware NSX in production 56, Vmware NSX 67 and Weekly show Real World SDN 161, Design & Build 264. I’d like to shoutout to Andreas Gautschi from VMware for giving me a 2-hour demonstration and braindump about NSX.

Initially, even as an immature product, SDN in its first year got a massive amount of hype. However, the ratio from slide to production deployments was minimal. It was getting a lot of publicity even though it was mostly an academic and powerpoint reality. Recently, the ratio has changed and the concepts of SDN apply to different types of networks meeting a variety of requirements. SDN enables network virtualization with many companies such as VMware NSX, Midokura, Juniper Contrail and Nuage offering network virtualization solutions. The following post discusses network virtualization in general but focusses more on the NSX functionality. Follow these links to my previous blogs on Midokura – Distributed SDN and Juniper Contrail.

 

Network Virtualization

In its simplest form, network virtualization is the provisioning of network services, independent of the physical infrastructure. Traditional network services were tied to physical boxes, lacking elasticity and flexibility. This results in many technical challenges including central choke points, hair pinning, traffic trombones and not to mention the underutilization of network devices. Network virtualization combats this and abstracts network services (firewalling, routing, etc) into software making it easier to treat the data centre fabric as a pool of network services. When a service is put into software it gains elasticity and fluidity qualities not present with physical nodes. The physical underlay provides a connectivity model, only concerned with endpoint connectivity. The software layer that sits on top of the physical world provides the abstraction for the workloads; offering excellent application continuity. Now, we can take two data centres and make them feel like one. All east and west traffic flows via the tunnels and VMware’s NSX offers local egress traffic optimization so that traffic exits the correct data centre and does not need to flow via the data centre interconnect to egress. To overcome outbound TE with traditional designs, we used hacks with HSRP localization or complicated protocols such as LISP.

The application has changed from the traditional client – server model where you know how many hosts you are running on top of. To an application that moves and scales on numerous physical nodes that may change. With network virtualization, we don’t need to know what physical host the application is on as all the compute, storage and networking move with the application. If the application X moves to location X, all its corresponding services move to location X too. The network becomes a software abstract.  Apps can have many different tiers – front end, database and storage with scale capabilities, automatically reacting to traffic volumes. It’s far more efficient to scale up docker containers with container schedules to meet traffic volumes than deploying 100 physical servers leaving them idle for half the year. If performance is not a key issue it makes sense to move everything to software.

 

Changing Endpoints

The endpoints the network must support has changed. We now have containers, VM’s, mobile and physical devices. Networking is evolving and it’s all about how we connect all these heterogeneous endpoints that are becoming very disconnected from the physical infrastructure. Traditionally, a server connected to the network with an Ethernet port. Then, virtualization came along offering the ability to architect new applications. Instead of single servers hosting single applications we have multiple VM’s hosting different applications on a single physical server. More recently, we see the introduction of docker containers, spawning in as little as 350ms. Traditional VLANs are unable to meet this type of fluidity as each endpoint type holds different requirements on the network. The network must now support traditional physical servers, VM’s and docker containers. All these stacks must cross each other and more importantly, be properly secured in a multitenant environment. Can traditional networking meet this? VMware NSX is a fairly mature product offering virtualized network and security services with the ability to secure a variety of endpoints. 

Network endpoints have different trust levels. Administrator trust hypervisors a lot more now than they did before with only two VMware hypervisor attacks in the last few years. Unfortunately, with the Linux kernel, there are numerous ways to attack it. Security depends on the attack surface and an element with a large attack surface has greater potential for exploitation. The Linux kernel has a large attack surface while hypervisors have a small attack surface. The more options an attacker can exploit, the larger the attack surface. Containers run many workloads so the attack surface is bigger and more varied. The vswitch inside the container has a different trust level than a vswitch running inside a hypervisor. You need to operate different security paradigms relating to containers than to hypervisors.  

NSX provides isolation to all these endpoint types with microsegmentation. Microsegmentation allows you to apply security policy at a VM-NIC level. This offers the ability to protect east – west traffic and move policies with the workload. This doesn’t mean that each VM NIC requires individual configuration. NSX uses a distributed firewall kernel module and the hosts obtain the policy without individual config. Everything is controlled centrally but installed locally on each vSphere host. It scales horizontally so if you add more compute capacity you get more firewalls. All the policies are implemented in a distributed fashion and the firewall is situated right in front of the VM in the hypervisor. So you can apply policy at a VM NIC level without hair pinning or trombone the traffic. Traffic doesn’t need to go across the data centre to a central policy engine anymore: offering optimum any to any traffic.

 

Even though the distributed firewall is a Kernal loadable module (KLM) of the ESXi Host the policy enforcement is at the vNIC of the VM.

 

Policy Classification

A major selling point with NSX is that you get an NSX distributed firewall. VMware operates with three styles of security. Firstly, we have traditional network focused 5 tuple matching. Secondly, we then move up a layer with infrastructure focused rule such as port groups, vCenter objects etc. Finally, we have application focused rule sets so at a very high level we can say from Web tier to App tier permit TCP port 80. Applications inherit the policies. You can even apply policies with a logical switch as the destination. This allows you to create a rule to be applied to any VM attached to this network, for example, App Logical Switch to Database Logical Switch. Security groups may also be integrated with Active Directory for identity-based rules allowing the assignment of user groups to network resources, for example, Sales users may access Web Tier A.

Traditionally, we have always used network-based rules so the shift to application based, while indeed is more efficient, will present the most barriers. People mindset needs to change. But the real benefit of NSX comes from this type of endpoint labelling and security. Sometimes a /8 is not enough addresses! What happens when you run out of /8? We start to implement kludges with NAT etc. Security labelling based on IP addresses is the past and we should start moving with tagging or other types of labelling. IP addresses are just a way to get something from point A to point B but if we can focus on other ways to class traffic, the IP address should be irrelevant to security classification. The less tied we are to IP addresses as a security mechanism the better we will be. With NSX, endpoints are managed based on high-level policy language that properly describes the security function. IP is a terrible way to do this as it imposes hard limits on mobile VMs and reduces flexibility. The policy should be independent of IP address assignment.

 

About Matt Conran

Matt Conran has created 156 entries.

Leave a Reply