Just as the title says, NSX-v 6.4 has just dropped. I my opinion, they should’ve called it NSX-v 7.0 though, considering the amount of new and cool stuff that is in there. I’ll go through the most prolific new and shiny features below.
Distributed Firewall Layer 7 Functionality – App ID
Traditionally the DFW could handle layer 2 to layer 4 rules. With NSX 6.4, there is some layer 7 functionality which becomes available. This is done by pushing a new VIB to ESXi hosts which looks inside the traffic flows. This new module will recognise App ID inside network traffic. For example: AD, KMS, DNS, RDP, SSH, SMB, TLS versions, etc.
This means that even if an application is using a non-standard port for a certain protocol, you can still refer to that protocol in your ruleset and you don’t have to create exception services.
This does not mean NSX is a full blown nextgen firewall (no IDS/IPS/WAF/Anti malware, etc, etc), you need still an integration partner for that functionality. This is however, a welcome addition to the micro segmentation use-case to make sure the firewall rules you create are aligned with the applications and that they cannot sneak another application over a different port.
To use it, is as simple as selecting a service with the prefix APP_ in the Services list. Here’s an example where I wanted to make a different between TLS versions inside HTTPS:
To get a list of all available App IDs, search for APP_ in the services box.
Heads up: you need an Enterprise License for this feature.
The Application Rule Manager also includes the App IDs into its recommended firewall rules when you are using it for micro segmentation planning.
Distributed Firewall Layer 7 Functionality – User ID
NSX has been able to segment on Active Directory users & groups for quite some time. This worked pretty good in VDI environments to dynamically put security policies over a virtual desktop when someone logged into that desktop. However, it was not feasible for terminal (or other) services where multiple users made use of the server (as the security policy for the last known user to have logged in would be applied). With NSX 6.4 and the same layer 7 functionalities that make the App ID possible, NSX can now tell the difference between network traffic of users on the same server. This means you can properly segment Remote Desktop Session Hosts and XenApp hosts.
The Guest Introspection agent inside the server is required as this is the tool that will detect and map users to network flows. When creating firewall rules for RDSH, make sure you check the “Enable User Identity at source”
Heads up: you need an Advanced License for this feature.
From the viewpoint of a Security Policy:
Upgrade Coordinator
Any upgrade can be tricky. There’s a sequence of operations you need to follow, which is usually described in the release notes. In NSX-T 2.0 there was an upgrade coordinator added which simplifies the upgrade process to a wizard driven workflow. A same upgrade coordinator has been implemented in NSX 6.4 which will take care of the NSX Controller, Edge and Host upgrades. You will be able to control which clusters are upgraded at what time and what kind of order (parallel or serial) these upgrades take place.
Edge Gateway HA Improvement
Currently, the ESG can work in 2 modes: High Availability (single path failover) and ECMP (multipath failover). The HA mode has a failover time of around 15-20 seconds, which is okay, but not great. VMware has implemented the BFD protocol to speed up this failover time, which should take it down to 5-10 seconds. Hopefully this is a first step to a seamless failover experience.
Other Edge Gateway Improvements
- NAT64: Create an IPv6 address on the uplink and have it translated to an IPv4 address.
- Route Redistribution: LE/GE match support. If you configure 192.168.0.0/16 LE = 28, everything in between 192.168.0.0/16 and 192.168.0.0/28 is accepted.
- Routing over GRE tunnel: Routing via BGP is now supported over GRE tunnels (also new).
- New Load Balancer Health Checks: MSSQL, DNS and LDAP health checks are now available to check functionality of these services.
Capacity Dashboard
There’s been an operational dashboard for some time now, telling you whether everything within NSX is in working order or if something requires attention. With NSX 6.4, VMware has added a Capacity Dashboard which will tell you whether you are stretching NSX to its limits. Although NSX has some pretty impressive scaling numbers, there are some customers that can reach those limits. For example: amount of DWF rules and sections, number of DLRs and Edges, number of IP Sets, Pools, etc, number of Logical Switches, Security Groups, Policies and Tags, and more. This dashboard is an excellent way to keep an eye on those limits.
New Navigation Menu
The navigation menu inside the vSphere Web Client has had an overhaul to cope with the expanding tools that NSX provides. It also makes things a bit more intuitive:
Other Improvements
- HTML5 Support inside the vSphere Web Client. Most of the new pages (such as the dashboards and upgrade coordinator) are done in the new HTML5 format while still being inside the old vSphere Web Client. Must be preparation for the vSphere HTML5 UI Plugin and it looks sweet!
- Multiple syslog servers (up to 5, instead of just one) for NSX Manager, Controllers, Edge Gateways, Service VMs and the ESXi components.
- The API now officially supports JSON as the payload format.
- Site wide CDO activation (also for Cross-vCenter) instead of per transport zone.
- Generate a support bundle directly from the vSphere Web Client (instead of having to go to the NSX Manager interface).
- Distributed Firewall Exclusion list can now be edited from the DFW page (instead of having to go to the NSX Manager object).
For the full release notes, check here. For the bits, check here.
Leave a Reply