Our last blog on how NSX secures physical servers provided background on why physical server security is crucial. We cover the percentage share of physical servers to all workloads in the data center and the specific roles physical servers still play. Today, physical servers by percentage are playing a decreasing role in the data center. However, it’s still a vital one, as we pointed out in our last blog on Securing Physical Servers with NSX Service-defined Firewall. In this blog, we will cover a primary way VMware NSX provides secure connectivity for physical servers using a bare metal agent. VMware NSX-T can now offer secure connectivity for Linux and Windows Server physical servers.
How NSX Distributed Firewall Protects Physical Servers
There are several ways in which NSX can provide security for physical servers. Our original article, Extending the Power of NSX to Bare Metal, outlines each of these methods.
- NSX Distributed Firewall (DFW) ingress rules for traffic from physical servers to virtual workloads
- NSX DFW egress rules for traffic from virtual workloads to physical servers
- The NSX Edge using centralized firewall rules to secure traffic between virtual and physical workloads
- Use NSX agents in Physical Servers
VMware NSX also has a newer capability not discussed in previous blogs concerning a partnering of VMware NSX and Arista CloudVision. We will review this partner solution in a later blog as part of this series. For the remainder of this article, we are going to revisit the use of the NSX agent for physical servers and the purpose of NSX DFW for policy enforcement.
The NSX Agent for Physical Servers
Preparing a physical server for NSX-T Data Center involves a modest preparation for either a Linux or Windows physical system. A Windows physical system requires the Windows Remote Management (WinRM) feature. A Linux physical system requires a handful of dependency modules. The NSX-T documentation provides a straightforward method to aid in the preparation and install of prerequisite features for either a Windows or Linux physical system using Ansible and a prepared playbook available on GitHub.
The procedures for preparing a physical system, including all necessary steps, is available in our online NSX documentation on Configuring Bare Metal Server to Use NSX-T Data Center. [i]
You have a choice of topology options whereby the physical system will either utilize a VLAN or an overlay for network connectivity. If extending an overlay transport to the physical server, during the preparation of the physical system, you will configure a Tunneling Endpoint (TEP). Single and dual PNIC topologies are supported to combine or separate virtual interfaces and the NSX Management interfaces on the physical system.
The actual “NSX agent” is installed when adding the host as a transport node. Once added, the physical server can participate in the NSX-T Data Center network utilizing a VLAN or overlay connection. The critical aspect to remember is that the physical server can now operate using NSX-T policy enforcement managed via NSX DFW for all workflows.
NSX-T Supports Windows Server Physical Systems
As previously discussed, NSX-T now supports physical servers running Windows Server operating systems, specifically Windows Server 2016. NSX-T will offer support for additional Windows Server versions. Further, to aid in determining physical servers, VMware vRealize Network Insight provides the initial help in mapping out connectivity with physical servers.
Like Linux physical systems, NSX-T Manager can add the Windows Server physical systems as transport nodes using the NSX-T Manager UI. It is a simple two-step process after prepping the physical server.
After adding all of your physical servers, NSX Distributed Firewall, NSX Manager can apply a security policy to these newly added physical systems. As a definitive feature of the NSX Service-defined Firewall, the NSX Distributed Firewall manages the security policy for virtual machines, containers, physical servers and workloads in the cloud from a single pane of glass.
Extending Security for Physical Servers with the NSX Agent
Utilizing the NSX agent for physical servers allows the same flexibility in instantiating policy for physical servers as the NSX Service-defined Firewall does for virtual workloads. The physical server is now treated as any other endpoint for security when managed by NSX.
In many cases, some of the “crown jewel” workloads coming under attack are still running as physical servers. NSX delivers a Trust boundary across virtual workloads, containers, virtual machines, and extends the boundary to physical workloads.
Summary
NSX Data Center delivers DFW for containers, virtual machines, Linux, and Windows physical systems while extending policy across public clouds. The NSX platform proves its extensibility to add requested features like bare metal agents for Windows Server. Windows physical server security will see additional enhancements for new Windows Server versions.
Unlike physical switch fabrics that rely upon the physical switch capacity feature limitations; a software first solution like NSX provides continual enhancements with minimal disruption. There is no requirement to replace an efficient physical switch network. Nor the cumbersome operation of swapping out switches due to feature requirements or hardware table limitations. Further, unlike agent-only solutions, the NSX Service-defined Firewall in an inherent and extensible set of features. Extensibility is key to securing an ever-changing application landscape.
Look for upcoming blogs on:
- NSX secures physical servers using NSX Edge Nodes
- NSX-T and Arista CloudVision: Integration between Virtual and Physical Done Right
[i] The NSX-T documentation at the time of this writing still refers to “Bare Metal Server” instead of the NSX-T Manager UI nomenclature of “Physical Server.” The terminology in the documentation will be updated later to reflect the use of “Physical Server.”
