VMware NSX Cookbook: Over 70 Recipes to Master the Network Virtualization Skills to Implement, Validate, Operate, Upgrade, and Automate VMware NSX for VSphere 1782174257, 9781782174257

Citation preview

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

VMware NSX Cookbook

Over 70 recipes to master the network virtualization skills to implement, validate, operate, upgrade, and automate VMware NSX for vSphere

Bayu Wibowo Tony Sangha

BIRMINGHAM - MUMBAI

||||||||||||||||||||

||||||||||||||||||||

VMware NSX Cookbook Copyright © 2018 Packt Publishing, All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information. Commissioning Editor: Vijin Boricha Acquisition Editor: Namrata Patil Content Development Editor: Deepti Thore Technical Editor: Sayali Thanekar Copy Editor: Safis Editing Project Coordinator: Shweta H Birwatkar Proofreader: Safis Editing Indexer: Aishwarya Gangawane Graphics: Jisha Chirayil Production Coordinator: Aparna Bhagat First published: March 2018 Production reference: 1270318 Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK. ISBN 978-1-78217-425-7

www.packtpub.com

||||||||||||||||||||

||||||||||||||||||||

mapt.io

Mapt is an online digital library that gives you full access to over 5,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website.

Why subscribe? Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals Improve your learning with Skill Plans built especially for you Get a free eBook or video every month Mapt is fully searchable Copy and paste, print, and bookmark content

PacktPub.com Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details. At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.

||||||||||||||||||||

||||||||||||||||||||

Foreword At the time of writing, I am right in the middle of nowhere in the western United States. Yet—through the magic of a communications network spanning the globe—I could pay for my breakfast without any form of cash and get a confirmation in a bit under thirty seconds from my bank over 13,000 kilometers away. Meanwhile, people in the VMware vExpert community were communicating with me, and I asked a digital personal assistant living in my cellphone for the most direct route back to the hotel. Even though we sometimes take this for granted a bit too much, it is undeniable that over the last 50 years, digital telecommunication networks have revolutionized the way we work, live, and communicate, from the humble beginnings of ARPANET all the way to the most recent revolutionary development of software-defined networking, which is where the book that you are currently holding comes in. This book will help you understand the concepts of VMware NSX for vSphere, provide you with the technical details behind the product, and give you a great overview of all the different components, including external products such as vRealize Log Insight, and the variety of API integrations available. For beginning and advanced readers equally, there's something to be found that should make this book worthwhile for you, as either a reference guide, a study book, or as a general introduction into VMware NSX for vSphere. For me personally, I like the fact that this book is interspersed with command-line snippets that will make your life easier when working with the product. It adds serious value to each individual recipe by showing you alternate ways to configure something, troubleshoot issues, or validate your configuration, and teaches you how the product works beyond the standard GUI-based configuration. By reading this book, I've actually learned that I have been wrong about a technical fact since I've started working with NSX in late 2013, so I'm more than certain that there's something left to be learned, regardless of your skill level and your technical knowledge. Sjors Robroek VCDX-NV #237 and Senior Consultant at VMware

||||||||||||||||||||

||||||||||||||||||||

Contributors About the authors Bayu Wibowo is a seasoned network virtualization consultant in the APJ arena. With over 10 years of industry experience, he has rapidly earned reputation and awards for his community involvement as Cisco Champion, VMware vExpert NSX, and VMTN Community Warrior. Working as a network virtualization consultant for Datacom, he now plays an integral part in the implementation of multiple innovative technologies, including VMware NSX, Open Networking, and numerous more. Follow him on Twitter @bayupw.

Tony Sangha is a senior consulting architect at VMware Professional Services with over 12 years of experience in networking and security roles, who has worked for a systems integrator across various industry verticals. He guides customers across Australia and New Zealand to design and implement a Software Defined Datacenter using VMware technologies and specializes in VMware NSX. He has presented at multiple VMUG and vForum events across ANZ and is an active community contributor via his blog and open source projects on GitHub. You can follow him on Twitter at @tsangha.

||||||||||||||||||||

||||||||||||||||||||

About the reviewer Dmitri Kalintsev possesses a long career working in provider networking—from system administration and operations to engineering and architecture. He then switched gears to building VMware-based public cloud infrastructure followed by transition to the vendor world. For the last few years, Dmitri has worked in solution architecture, product management, and product engineering roles concerned with a range of software networking products. He can be found on Twitter as @dkalintsev.

Packt is searching for authors like you If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.

||||||||||||||||||||

||||||||||||||||||||

Table of Contents Preface

1

Chapter 1: Getting Started with VMware NSX for vSphere Introduction Choosing the right VMware NSX for vSphere edition Getting ready How to do it... There's more...

VMware NSX editions Evaluating VMware NSX Support and Subscription (SnS) VMware vRealize Log Insight for NSX VMware NSX Monitoring Tools

See also

Selecting ESXi hosts and network adapters VXLAN Offload Receive Side Scaling

Downloading NSX for vSphere Getting ready How to do it...

Checking the Product Interoperability Matrix Downloading media via the VMware downloads website Downloading media via the VMware Software Manager

See also

Deploying the NSX Manager virtual appliance Getting ready How to do it...

Replacing the NSX Manager certificate Certificate Signing Request How to do it... PKCS#12 certificate

How to do it...

Registering vCenter server with NSX Manager Getting ready How to do it...

Registering the NSX Manager with the vCenter server Registering the NSX Manager with the PSC

How it works... There's more...

Applying the NSX license

9 9 10 10 11 12 12 13 13 14 14 14 15 15 15 16 16 16 16 17 18 19 19 20 21 23 23 23 24 25 25 26 26 26 28 29 29 29

||||||||||||||||||||

||||||||||||||||||||

Table of Contents

Getting ready How to do it...

Deploying the NSX Controller Cluster Getting ready How to do it...

Configuring an NSX IP pool NSX Controller Cluster deployment

DRS Anti-Affinity Rules Configuring DRS Anti-Affinity Rules via PowerCLI

There's more...

Separate vCenter environment Controller password parameters

Preparing a vSphere cluster for NSX Getting ready How to do it... How it works...

Enabling NSX in a brownfield environment

Validating NSX VIB installation

Distributed Firewall communication Controller communication Getting ready How to do it...

Manually checking VIB installation Checking NSX component communication

Chapter 2: Configuring VMware NSX Logical Switch Networks Introduction VMware NSX Logical Switch and VXLAN VMware NSX Transport Zone VMware NSX Replication Modes VMware NSX Controller Disconnected Operation Mode

Configuring VXLAN Networking Getting ready

IP address for VTEP VMkernel Using DHCP for an IP pool VDS teaming options for NSX

Single VTEP with LACP Multi-VTEP with Route Based on Originating Port ID

How to do it...

Configuring VXLAN Networking Validating VXLAN and VTEP configuration

How it works...

Testing VXLAN VTEP VMkernel

There's more... See also

Configuring a VXLAN Segment ID Getting ready

[ ii ]

29 30 30 31 31 32 32 33 34 35 35 35 36 36 37 38 40 40 40 41 41 41 42 45 47 47 48 50 52 53 54 54 55 55 56 56 57 57 58 61 62 65 65 66 66 66

||||||||||||||||||||

||||||||||||||||||||

Table of Contents

How to do it... How it works... There's more... See also

How it works... There's more... See also

66 67 68 69 70 70 70 72 73 74 74 75 77 79 80 80 80 82 83 84 84 84 84 86 87 88 89

Getting ready How to do it... How it works...

89 89 89 91

Creating a NSX Transport Zone Getting ready How to do it... How it works... There's more...

Creating a NSX Logical Switch Getting ready How to do it... How it works... See also

Connecting a Virtual Machine to an NSX Logical Switch Getting ready How to do it... How it works... See also

Testing an NSX Logical Switch Getting ready How to do it... Ping Broadcast

Enabling the Controller Disconnected Operation Mode on a Transport Zone

Chapter 3: Configuring VMware NSX Logical Routing Introduction Configuring the Distributed Logical Router Getting ready How to do it... How it works... There's more...

DLR CVM hardware requirements HA interface

Configuring the Distributed Logical Router for dynamic routing Getting ready How to do it...

[ iii ]

93 93 95 95 96 105 106 107 107 107 108 108

||||||||||||||||||||

||||||||||||||||||||

Table of Contents

How it works... There's more...

Route redistribution Forwarding versus protocol address Graceful restart

Deploying and configuring the NSX ESG in HA mode Getting ready How to do it... How it works... There's more...

Understanding and configuring the NSX ESG for routing Getting ready How to do it... How it works... There's more...

Chapter 4: Configuring VMware NSX Layer 2 Bridging Introduction Software-Based Gateway Layer 2 Bridging Bridging and Routing Hardware VTEP Gateway

Configuring Software-Based Gateway Layer 2 Bridging Getting ready How to do it...

Configuring bridging Verifying Bridging Configuration

How it works... There's more...

Selecting a hardware VTEP gateway Getting ready How to do it... There's more... See also

Integrating Hardware VTEP Gateway with VMware NSX Getting ready How to do it...

Configuring the Replication Cluster Connecting a Hardware VTEP Gateway to an NSX Controller Adding a Hardware VTEP Gateway to NSX

How it works... See also

Extending VMware NSX Logical Switch to Hardware VTEP Gateway Getting ready How to do it... How it works... There's more...

[ iv ]

113 113 113 114 115 115 115 116 122 122 123 124 124 128 129 130 130 132 134 135 137 138 139 139 141 144 145 146 146 146 147 147 147 148 148 149 151 151 152 153 154 154 155 156 156

||||||||||||||||||||

||||||||||||||||||||

Table of Contents

See also

156

Chapter 5: Configuring VMware NSX Edge Services Gateway Introduction Configuring a DNS relay Getting ready How to do it... There's more...

Configuring a DHCP server Getting ready How to do it... There's more...

Configuring an Edge Firewall Getting ready How to do it... There's more...

Configuring Network Address Translation Getting ready How to do it...

Configuring an SNAT rule Configure a DNAT rule

How it works... There's more...

Configuring Load Balancing Getting ready How to do it...

Deploying an NSX Edge Load Balancer Configuring an NSX Edge Load Balancer Verifying the NSX edge load balancer configuration

How it works... There's more...

Configuring IPSEC VPN Getting ready How to do it... How it works...

Configuring SSL VPN Getting ready How to do it... How it works... There's more...

Configuring High Availability Getting ready How to do it... How it works...

[v]

157 157 158 158 159 160 161 163 163 166 166 168 168 171 173 174 174 174 176 177 178 178 180 180 180 187 194 195 196 196 198 198 201 201 203 203 210 211 211 212 212 218

||||||||||||||||||||

||||||||||||||||||||

Table of Contents

Chapter 6: Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard Introduction DFW Topology and Policy See also

Verifying NSX DFW component status Getting ready How to do it...

Verifying Firewall Installation Status Verifying vShield Stateful Firewall (vsfwd) Status and Connection

How it works... See also

Configuring IP Discovery for Virtual Machines Getting ready How to do it... How it works...

Verifying the Learnt IP address

Working with SpoofGuard Getting ready How to do it... How it works... There's more...

Excluding Virtual Machines from DFW Protection Getting ready How to do it... How it works... There's more...

Configuring DFW Session Timeout Getting ready How to do it... How it works...

Creating Security Policy Rules from the Firewall Table Menu Getting ready How to do it...

Creating Firewall Sections Creating Firewall Rules

How it works...

DFW Rule ID and Logs DFW Saved Configurations

See also

Creating Security Policy Rules from the Service Composer menu Getting ready How to do it...

Creating a Security Group using Static Inclusion Creating a Security Group using Dynamic Membership

[ vi ]

219 220 224 226 226 226 227 227 227 229 230 230 230 230 231 232 232 232 233 234 235 235 236 236 237 237 238 238 238 239 240 240 240 240 242 245 246 247 247 248 248 248 248 251

||||||||||||||||||||

||||||||||||||||||||

Table of Contents Creating a Security Group using Security Tag as the Dynamic Membership Criteria Creating a Security Policy

How it works...

Verifying DFW rules Getting ready How to do it...

Using NSX Manager central CLI Using ESXi Host CLI

Leveraging the DFW Applied To field Getting ready How to do it...

Changing Firewall Default Applied To settings from the Firewall Table Menu Changing Service Composer Firewall Default Applied To Settings

There's more... See also

Deploying Network or Guest Introspection Services Getting ready How to do it...

Registering Service Definition Deploying the Service VM Installing VMware Tools for Guest Introspection

How it works...

Blocking Non-IP Layer 2 Traffic

There's more... See also

Configuring the Identity Firewall Getting ready How to do it...

Registering a Microsoft Active Directory Domain with NSX Manager Creating Security Rules using Active Directory Objects

How it works... There's more...

Chapter 7: Configuring Cross-vCenter NSX Introduction Configuring Primary and Secondary NSX Manager(s) Getting ready How to do it... How it works... There's more...

Enhanced Linked Mode NSX Manager roles Universal Synchronization Service Management and Troubleshooting

Creating a Universal Transport Zone and adding a vSphere cluster to the Universal Transport Zone [ vii ]

252 254 259 259 259 260 260 260 261 261 262 262 263 263 264 264 264 265 265 266 268 269 270 270 271 272 272 272 272 275 277 277 278 278 283 283 284 286 287 288 288 289 290

||||||||||||||||||||

||||||||||||||||||||

Table of Contents

Getting ready How to do it... How it works...

Creating a Universal Logical Switch Getting ready How to do it... How it works...

Creating a Universal Logical Router Getting ready How to do it... How it works... There's more... See also

Deployment models Local Egress

Adding a VM to a Universal Logical Switch Getting ready How to do it... How it works...

Understanding and configuring the Universal Distributed Firewall Getting ready How to do it...

Creating Universal IPSets Adding a web-tier-to-web-tier Universal Firewall Rule and Universal Section Adding a web-tier-to-app-tier Universal Firewall Rule Adding a app-tier-to-db-tier Universal Firewall Rule

How it works... There's more...

Chapter 8: Backing up and Restoring VMware NSX Components Introduction Backing up NSX Manager Getting ready How to do it... How it works... There's more... See also

Restoring NSX Manager Getting ready How to do it...

Restoring NSX Controller Nodes Getting ready How to do it... There's more... See also

[ viii ]

292 292 295 296 297 297 299 299 300 301 309 310 310 311 312 314 315 315 319 319 321 321 321 322 326 331 335 336 337 338 339 339 340 343 345 345 346 346 347 348 349 349 352 353

||||||||||||||||||||

||||||||||||||||||||

Table of Contents

Restoring a Logical Switch Backing Port Group Getting ready How to do it... How it works...

Restoring NSX Edge Getting ready How to do it... How it works... There's more...

Exporting NSX DFW Rules configuration from the Firewall Menu Getting ready How to do it... There's more...

Restoring NSX DFW Rules configuration from the Firewall Menu Getting ready How to do it... How it works...

Exporting NSX Security Policy from the Service Composer Menu Getting ready How to do it...

Restoring NSX Security Policy from the Service Composer Menu Getting ready How to do it...

Chapter 9: Managing User Accounts in VMware NSX Introduction NSX Manager virtual appliance user account

Creating a service user account for vCenter server registration Getting ready How to do it...

Creating a user account Adding an SSO user account as an SSO administrator Registering NSX Manager registration with the vCenter server

How it works... There's more...

Granting access to NSX Getting ready How to do it...

Assigning a vCenter role to a user account Assigning an NSX role to a user account

How it works...

Creating and Managing CLI user accounts in NSX manager Getting ready How to do it...

Entering configuration mode in the NSX Manager CLI

[ ix ]

354 354 354 355 356 356 356 357 359 359 359 360 361 361 361 362 366 367 368 368 371 372 372 376 376 378 379 379 379 379 382 385 386 387 388 389 389 389 391 394 395 395 395 395

||||||||||||||||||||

||||||||||||||||||||

Table of Contents Creating a CLI user account in the NSX Manager CLI Granting REST API access to a CLI user account Changing the enable password and CLI user account password Verifying and saving configuration in the NSX Manager CLI Clearing a VTY session

How it works... There's more... See also

Chapter 10: Upgrading VMware NSX Introduction Preparing for VMware NSX upgrade Getting ready How to do it...

Checking the VMware Product Interoperability Matrices Checking the VMware NSX upgrade path Checking for Third-Party Integrations Compatibility Reviewing VMware NSX for vSphere Release Notes and Upgrade Documents Reviewing deprecated and discontinued features Downloading VMware NSX upgrade bundles

There's more...

Verifying VMware NSX working state Getting ready How to do it...

Verifying NSX Manager virtual appliance working state Verifying NSX components working state Verifying vSphere components

There's more...

Upgrading VMware NSX Manager Getting ready How to do it... There's more...

Upgrading NSX controller node Getting ready How to do it... How it works...

Upgrading VMware NSX Host Clusters Getting ready How to do it... How it works... There's more...

Upgrading VMware NSX Edge Getting ready How to do it... How it works...

Upgrading Network and Security Service Deployments [x]

396 398 402 403 404 405 406 406 407 407 409 409 409 410 411 413 413 414 415 416 418 418 418 418 423 428 429 430 430 430 434 435 435 436 438 439 440 440 442 442 442 443 443 445 446

||||||||||||||||||||

||||||||||||||||||||

Table of Contents

Getting ready How to do it... There's more...

446 446 448

Chapter 11: Managing and Monitoring VMware NSX Platform Introduction NSX Logs

NSX Manager vCenter Server ESXi host NSX Edge Gateway VM

Monitoring tools

Flow Monitoring Application Rule Manager Endpoint Monitoring

vRealize Log Insight for NSX vRealize Network Insight

Monitoring NSX using NSX Dashboard Getting ready How to do it... How it works... There's more...

Configuring the NSX Components Syslog Getting ready How to do it...

Configuring the NSX Manager syslog Configuring the NSX Controller Node Syslog Configuring the NSX Edge Log

How it works... There's more...

Configuring and viewing the NSX Distributed Firewall Log Getting ready How to do it...

Configuring the NSX DFW logs Viewing the NSX DFW log from the ESXi host console

How it works...

Configuring vRealize Log Insight for NSX Getting ready How to do it...

Installing VMware NSX for the vSphere Content Pack Navigating the NSX Content Pack Dashboards Filtering DFW rules from the interactive analytics menu

How it works...

Enabling NSX Flow Monitoring Getting ready How to do it...

[ xi ]

449 449 450 451 451 452 452 452 453 453 453 454 454 454 455 455 458 458 459 460 460 460 461 463 465 467 468 468 469 469 471 471 472 472 472 473 474 475 479 479 479 479

||||||||||||||||||||

||||||||||||||||||||

Table of Contents Enabling Flow Monitoring collection Enabling and exporting Flow Monitoring collection

How it works...

Using Application Rule Manager Getting ready How to do it... How it works... There's more...

Using NSX Endpoint Monitoring Getting ready How to do it...

Verifying the prerequisites for endpoint monitoring Starting endpoint monitoring data collection

How it works...

Chapter 12: Leveraging the VMware NSX REST API for Management and Automation Introduction vCenter-Managed Object Reference ID (MoRef ID)

Using the REST API with the Postman REST client Getting ready How to do it...

Requesting the HTTP GET REST API via Postman Requesting the HTTP POST REST API via Postman

How it works...

Using the REST API with cURL Getting ready How to do it...

Requesting the HTTP GET REST API via cURL Requesting the HTTP POST REST API via cURL

How it works...

Generating a cURL script from Postman

There's more...

Using the REST API with PowerShell Getting ready How to do it...

Requesting the HTTP GET REST API via PowerShell Requesting the HTTP POST REST API via PowerShell

How it works... There's more...

Using the REST API with Python Getting ready How to do it...

Requesting the HTTP GET REST API via Python Requesting the HTTP POST REST API via Python

How it works...

[ xii ]

480 481 482 484 484 485 490 490 491 491 492 492 494 497 498 498 504 506 506 506 506 508 510 511 511 511 511 512 514 515 515 516 516 516 517 518 521 523 523 524 524 524 526 527

||||||||||||||||||||

||||||||||||||||||||

Table of Contents

There's more...

Using the vRealize Orchestrator plugin for NSX Getting ready How to do it...

Checking the VMware Product Interoperability Matrices Downloading the vRO plugin for NSX Installing the vRO plugin for NSX Running an NSX-vRO workflow

How it works... There's more... See also

529 529 530 530 530 530 531 538 540 541 542

Other Books You May Enjoy

543

Index

546

[ xiii ]

||||||||||||||||||||

||||||||||||||||||||

Preface VMware NSX is a network virtualization solution that provides network and security ™ services embedded into the VMware ESXi hypervisor. NSX for vSphere implements routing, switching, load balancing and firewalling through software constructs that scale as you scale out your compute infrastructure. NSX also provides the ability to integrate with third party vendors to deliver rich guest and network introspection services via software constructs. By decoupling from the physical hardware, NSX allows greater security, workload mobility, and automation, which form the foundational tenants of an NSX deployment. At the time of writing of this book, there are three VMware NSX offerings available, which are as follows: VMware NSX for vSphere VMware NSX-T VMware NSX Cloud (https:/​/​cloud.​vmware.​com/​nsx-​cloud) This book will cover VMware NSX for vSphere and has been written using version 6.3, but has also incorporated new features from 6.4 in the relevant sections of the book. The recipes covered throughout this book provide the foundational knowledge required to get started with NSX, but also covers the required content in depth, so that you can make informed design decisions for your VMware NSX implementation.

Who this book is for This book aims to be useful for both new and seasoned VMware NSX for vSphere administrators. It is intended to be used by those that have never deployed NSX and by those that have it deployed already but are looking to leverage new or advanced functionality. NSX-v runs on vSphere and connects to your existing network. Therefore, intermediate networking and virtualization knowledge is assumed and is essential to understand the correct deployment of NSX in your environment.

||||||||||||||||||||

||||||||||||||||||||

Preface

What this book covers Chapter 1, Getting Started with VMware NSX for vSphere, explains how to choose the right

VMware NSX for vSphere Edition, select compatible software and hardware, and deploy the foundational components of NSX.

Chapter 2, Configuring VMware NSX Logical Switch Networks, covers how to set up logical

switch networks based on Virtual Extensible LAN (VXLAN) and how to connect virtual machines to the newly created logical switches. Chapter 3, Configuring VMware NSX Logical Routing, introduces the Distributed Logical

Router for East-West routing in your datacenter and the Edge Services Gateway for NorthSouth routing to your virtual networks. Chapter 4, Configuring VMware NSX Layer 2 Bridging, covers how layer 2 bridging works

and its configuration for both software and hardware.

Chapter 5, Configuring VMware NSX Edge Services Gateway, acts as the Swiss Army knife of

NSX and provides all the rich network services. The topics covered in this chapter include DNS Relay, DHCP Server, firewall, load balancing, and virtual private networks.

Chapter 6, Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard, covers how

to configure the NSX Distributed Firewall. The topics include configuration of Security Policy, Grouping Constructs, Firewall Rules, and advanced Guest and Network Introspection services.

Chapter 7, Configuring Cross-vCenter NSX, covers how to extend your NSX deployment

across vCenter boundaries and how to deliver distributed services across geographical dispersed sites.

Chapter 8, Backing up and Restoring VMware NSX Components, covers recipes to perform

backup and restore of NSX components for disaster recovery and day-to-day operations.

Chapter 9, Managing User Accounts in VMware NSX, explains how to manage and create user accounts in NSX Manager and vSphere Web Client based on roles for accessing VMware NSX. Chapter 10, Upgrading VMware NSX, gives you an understanding of how to plan and

perform a VMware NSX for vSphere upgrade.

[2]

||||||||||||||||||||

||||||||||||||||||||

Preface Chapter 11, Managing and Monitoring VMware NSX Platform, focuses on monitoring NSX

using built-in dashboards, working with logs, and using flow monitoring tools available natively within NSX. This chapter also covers how to use Application Rule Manager and Endpoint Monitoring.

Chapter 12, Leveraging the VMware NSX REST API for Management and Automation, introduces you to working with the NSX REST API and demonstrates how to use a plethora of tools for accessing the NSX REST API, such as Postman, cURL, PowerShell, Python, and vRealize Orchestrator.

To get the most out of this book The book was written using vSphere version 6.5 and NSX-v version 6.3. vSphere 5.5 and later can be used, but you should independently validate all software components are compatible with the version of NSX you are deploying via the VMware Product Interoperability Matrices (https:/​/​www.​vmware.​com/​resources/​compatibility/​sim/ interop_​matrix.​php), and all hardware should be checked via the VMware Hardware Compatibility Guide (HCL) (http:/​/​www.​vmware.​com/​go/​hcl). To install VMware for vSphere you will need to obtain the appropriate software; unfortunately, without a valid contract you will need contact the VMware sales team (http:/​/​www.​vmware.​com/​company/​contact_​sales.​html) to obtain it. All recipes require a supported guest operating system, web browser, and Adobe Flash Player to access the vSphere Web Client. The minimum supported requirements are vSphere version-dependent; for example, the requirements for vSphere 6.5 are documented at the following URL: https:/​/​docs.​vmware.​com/​en/​VMware-​vSphere/​6.​5/​com.​vmware. vsphere.​install.​doc/​GUID-​F6D456D7-​C559-​439D-​8F34-​4FCF533B7B42.​html. Additionally, you will need an SSH client to access ESXi hosts and/or NSX components. Two of the recipes in Chapter 4, Configuring VMware NSX Layer 2 Bridging, are based on hardware VTEP bridging, which requires compatible hardware. Unless you have a compatible piece of hardware, you may not be able to test this recipe. In this case, you can visit an online interactive simulation provided by VMware Hands-on Labs to walk through configuration steps in detail: http:/​/​docs.​hol.​vmware.​com/​hol-​isim/​HOL-​2017/​hol-​1703arista.​htm.

[3]

||||||||||||||||||||

||||||||||||||||||||

Preface

The NSX Identity Firewall in Chapter 6, Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard, and Endpoint Monitoring in Chapter 11, Managing and Monitoring VMware NSX Platform, require a compatible desktop operating system. The specific list of compatible operating systems are covered in the respective chapters, and at the time of writing this book, was limited to Microsoft Windows operating systems only. Chapter 7, Configuring Cross-vCenter NSX, is a multi-vCenter setup that requires additional

compute infrastructure and virtual components for complete configuration. This includes a minimum of two vCenter servers, two NSX managers, and the relevant infrastructure components for each. Chapter 8, Backing up and Restoring VMware NSX Components, covers backup and software

of NSX components and requires deployment of either a File Transfer Protocol (FTP) or SSH File Transfer Protocol (SFTP) server.

VMware vRealize Log Insight (vRLI) is covered in Chapter 11, Managing and Monitoring VMware NSX Platform; deployment and configuration for vRLI is not within the scope of this book. However, VMware NSX customers are entitled for VMware vRealize Log Insight, see VMware KB 2145800 vRealize Log Insight for NSX FAQ https:/​/​kb.​vmware.​com/​s/ article/​2145800. Chapter 12, Leveraging the VMware NSX REST API for Management and Automation, covers

the NSX REST API and requires the following software installed on your administrative machine for testing:

Postman: https:/​/​www.​getpostman.​com/​ Windows PowerShell or PowerShell Core: https:/​/​microsoft.​com/​powershell Python 2.7 or Python 3: https:/​/​www.​python.​org/​downloads/​ vRealize Orchestrator: https:/​/​www.​vmware.​com/​products/​vrealizeorchestrator.​html

NSX-vRO plugin If you do not have an environment to work with NSX, you can still test-drive NSX on VMware Hands-on Lab (HOL): https:/​/​www.​vmware.​com/​products/​nsx/​nsx-​hol.​html.

Download the example code files You can download the example code files for this book from your account at www.packtpub.com. If you purchased this book elsewhere, you can visit www.packtpub.com/support and register to have the files emailed directly to you.

[4]

||||||||||||||||||||

||||||||||||||||||||

Preface

You can download the code files by following these steps: 1. 2. 3. 4.

Log in or register at www.packtpub.com. Select the SUPPORT tab. Click on Code Downloads & Errata. Enter the name of the book in the Search box and follow the onscreen instructions.

Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of: WinRAR/7-Zip for Windows Zipeg/iZip/UnRarX for Mac 7-Zip/PeaZip for Linux The code bundle for the book is also hosted on GitHub at https:/​/​github.​com/ PacktPublishing/​VMware-​NSX-​Cookbook. In case there's an update to the code, it will be updated on the existing GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https:/​/​github.​com/​PacktPublishing/​. Check them out!

Download the color images We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: http://www.packtpub.com/sites/default/files/downloads/VMwareNSXCookbook_ColorIm ages.pdf.

Conventions used There are a number of text conventions used throughout this book. CodeInText: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "To check whether cURL is available in the operating system, use the curl --version command."

[5]

||||||||||||||||||||

||||||||||||||||||||

Preface

A block of code is set as follows: # NSX Variables $NSXUsername = "admin" $NSXPassword = "VMware1!" $NSXManager = "https://nsxmgr-01a.corp.local" $NSXURI = "/api/2.0/services/usermgmt/user/admin"

Any command-line input or output is written as follows: curl -k -X GET -H "Accept: application/xml" -H "Content-Type: application/xml" -u admin:VMware1! 'https://nsxmgr-01a.corp.local/api/2.0/services/usermgmt/user/admin'

Bold: Indicates a new term, an important word, or words that you see onscreen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: "Select All Downloads, scroll down to the Networking & Security menu item, and click Drivers & Tools." Warnings or important notes appear like this.

Tips and tricks appear like this.

Sections In this book, you will find several headings that appear frequently (Getting ready, How to do it..., How it works..., There's more..., and See also). To give clear instructions on how to complete a recipe, use these sections as follows:

Getting ready This section tells you what to expect in the recipe and describes how to set up any software or any preliminary settings required for the recipe.

[6]

||||||||||||||||||||

||||||||||||||||||||

Preface

How to do it... This section contains the steps required to follow the recipe.

How it works... This section usually consists of a detailed explanation of what happened in the previous section.

There's more... This section consists of additional information about the recipe in order to make you more knowledgeable about the recipe.

See also This section provides helpful links to other useful information for the recipe.

Get in touch Feedback from our readers is always welcome. General feedback: Email [email protected] and mention the book title in the subject of your message. If you have questions about any aspect of this book, please email us at [email protected]. Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details. Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material. If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

[7]

||||||||||||||||||||

||||||||||||||||||||

Preface

Reviews Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you! For more information about Packt, please visit packtpub.com.

[8]

||||||||||||||||||||

||||||||||||||||||||

1 Getting Started with VMware NSX for vSphere In this chapter, we will explore how to install and configure NSX for vSphere. We will be covering the following recipes: Choosing the right VMware NSX for vSphere edition Selecting ESXi hosts and network adapters Downloading NSX for vSphere Deploying the NSX Manager virtual appliance Replacing the NSX Manager certificate Registering vCenter server with NSX Manager Applying the NSX licenses Deploying the NSX Controller Cluster Preparing a vSphere cluster for NSX Validating NSX VIB installation Checking NSX component communication

Introduction This book aims to be useful for both new and seasoned VMware NSX for vSphere administrators. It is intended to be used by those that have never deployed NSX and by those that have it deployed already but are looking to leverage newer or advanced functionality. Intermediate networking and virtualization knowledge is assumed and is essential to understanding deployment of NSX into your environment.

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

Before we begin serving the main recipes of our cookbook, we will first provide an overview of what VMware NSX for vSphere is and what functionality it provides over traditional networking models. VMware NSX for vSphere is a core component of the VMware Software-Defined Data Center (SDDC); it is the component that enables network virtualization. Network virtualization provides a layer of abstraction over the physical network using a VXLAN network overlay. With NSX, network operations are now independent of the physical hardware, and functions such as logical firewalls, load balancers, logical routers, logical switches, and virtual private networks can be provisioned, modified, or torn down as part of an automated workflow.

Choosing the right VMware NSX for vSphere edition VMware NSX has four licensing editions: standard, advanced, enterprise, and remote office/branch offices (ROBO). Each licensing tier provides distinctive functionality, available per CPU socket on a perpetual basis at the vSphere cluster level. The standard and advanced editions are also available as per 100 users in a pack basis to align with virtual desktop deployments (vSphere for desktop). The enterprise edition is also available on per-VM term basis. You can upgrade from standard to advanced/enterprise and from advanced to enterprise. Prior to NSX 6.2.2, VMware NSX for vSphere did not have multiple licensing tiers. If you purchased NSX prior to May 3, 2016, you are entitled to VMware NSX Enterprise edition as long as you have active support and subscription contracts. You can upgrade your VMware NSX license key from the My VMware portal (http://my.vmware.com).

Getting ready Like vSphere licensing, VMware NSX is licensed per CPU socket. If you have a separate Management vSphere Cluster that is used for Infrastructure VMs and are not planning to protect it with the NSX Distributed Firewall or place NSX Edge Service Gateways onto it, you are not required to license the CPUs on that Management vSphere Cluster. The Compute vSphere cluster and Edge vSphere cluster need to be licensed.

[ 10 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

VMware NSX is licensed at the vSphere Cluster level. If you need to exclude a specific ESXi host from NSX, you will need to remove the ESXi host from the cluster. For vSphere environments with VMware vCenter Site Recovery Manager, you will normally have active sites (Protected site) and passive/disaster recovery sites (Recovery site). Only the active ESXi hosts on the protected site requires a VMware NSX license. For more about licensing NSX for vSphere see VMware KB 2078615 (https://kb.vmware.com/kb/2078615).

How to do it... From your vSphere inventory you will need to do the following: 1. Determine how many CPU sockets you need 2. Determine the NSX features required 3. If you are planning to integrate third-party partner solutions with NSX (http://www.vmware.com/products/nsx/technology-partners.html), check whether a specific NSX feature is required Some security services partner solutions require NSX distributed firewalling features and physical-to-virtual data center services requires integration with a Hardware VTEP (HW VTEP). 4. Choose the NSX edition based on the features required I would like to use VMware vShield Endpoint for anti-virus/anti-malware capability only. Which NSX edition should I use? VMware vShield endpoint is included as a vSphere feature in the vSphere Essential Plus Edition or later, so you do not need to purchase VMware a NSX license. VMware NSX for vShield endpoint will appear on the vSphere download site if you have vSphere Essential Plus Edition or later. For more information, see VMware KB 2110078 (https://kb.vmware.com/kb/2110078).

[ 11 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

There's more... The following sub-sections will detail the different tiers of NSX licensing and the features available in each. From there, how to evaluate and purchase VMware NSX will also be detailed.

VMware NSX editions The four tiers of licenses are as follows: Standard edition Advanced edition Enterprise edition ROBO The features available in each edition are as follows: Product feature

Standard Advanced Enterprise ROBO

Distributed Switching

●

Distributed Routing

●

●

●

●

●

NSX Edge Firewall

●

●

●

●

Network Address Translation (NAT)

●

●

●

●

SW L2 Bridging to physical environment

●

●

●

Dynamic routing with ECMP (Active-Active) ●

●

●

●

API-driven

●

●

●

●

Integration with vRealize and OpenStack

●

●

●

●

Automation of security policies with vRealize

●

●

●

NSX Edge Load Balancing

●

●

●

Distributed Firewalling

●

●

●

Integration with Active Directory

●

●

●

Service Insertion (third-party integration)

●

●

●

Cross vCenter NSX

●

[ 12 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

Multisite NSX optimizations

●

VPN (IPSec and SSL)

●

Remote gateway

●

Integration with HW VTEPs

●

●

Distributed switching for the ROBO licensing tier is only available on VLAN-backed networks. Distributed load balancing is available in Enterprise edition as a tech preview.

Evaluating VMware NSX There are two ways to evaluate VMware products: Deploy NSX in your environment and use an evaluation license for a limited time VMware NSX license is not available publicly. Contact your VMware sales representative to get an NSX evaluation license.

Use VMware Hands-on Labs (http://labs.hol.vmware.com/) to experience VMware NSX in a virtual lab environment: VMware NSX Hands-on Lab Intro (http://www.vmware.com/go/try-nsx-en) VMware NSX Hands-on Lab Advanced (http://www.vmware.com/go/try-nsx-adv-hol)

Support and Subscription (SnS) There are support and subscription plan options that you can purchase in addition to the product: Basic support: 12 hours a day technical support during business hours Production support: 24 hours (Severity 1), seven days a week support

[ 13 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

The production support plan is recommended for production and critical environments. If you need higher-level support above production grade, additional support options such as Business Critical Support (BCS) or Mission Critical Support (MCS) can be purchased on top of production support. For more information on VMware support offerings, see https://www.vmware.com/support/services.html.

VMware vRealize Log Insight for NSX VMware vRealize Log Insight is a log management engine that collects logs from a number of different sources and provides rich dashboards and search functionality. Log Insight is available for NSX at no additional charge, you are entitled to one Log Insight CPU per NSX CPU license. The support and subscription is included with the NSX purchase. It is a fully functioning version of Log Insight but limited to vSphere and NSX data sources and content packs only. If you need more data sources and content packs, additional Log Insight licenses are required.

VMware NSX Monitoring Tools There are several tools for monitoring VMware NSX. Some of these tools are built directly into the NSX platform, and others are separate feature-rich VMware products. These tools are as follows: VMware NSX built-in tools vRealize Network Insight

See also For more information about the VMware NSX Neutron plugin license editions for VMware integrated OpenStack, see VMware KB 2145269 (https://kb.vmware.com/kb/2145269).

[ 14 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

Selecting ESXi hosts and network adapters Similar to the requirements of a VMware vSphere solution, choosing the correct hardware is still an important part of any NSX deployment; therefore, you need to follow the same process that you did for vSphere to ensure the hardware you are deploying is on the VMware Compatibility Guide (http://www.vmware.com/resources/compatibility/search.php). The compatibility guide does not only list the supported servers, but you need to also check if your network interface card (I/O devices) is supported and features such as VXLAN Offload and Receive Side Scaling are also supported.

VXLAN Offload VXLAN Offload is akin to TCP segmentation offload (TSO), but compared to TSO, which is designed for TCP packet headers, VXLAN encapsulates the original (source) packet from a virtual machine into a user datagram protocol (UDP) packet with its own unique header, known as the VXLAN header. Placing this additional header onto a packet invalidates traditional offloading mechanisms in-place and therefore increases load on the CPU as additional CPU cycles are needed to encapsulate and decapsulate every VXLAN packet. VXLAN is covered in greater detail in Chapter 2, Configuring VMware NSX Logical Switch Networks.

Receive Side Scaling Receive Side Scaling (RSS) is a technique the Network Interface Card (NIC) employs to ensure that data processing for a particular connection is balanced across multiple CPU cores. Without RSS, all connections would be handled by a single CPU core, which can adversely affect network performance. When using VMware Compatibility Guide, it is important to check the Network Interface Card supports VXLAN Offload and RSS; this will ensure that ESXi is able to leverage native hardware offloading for increased performance. This is only required if you are using VXLAN in your NSX deployment.

[ 15 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

Downloading NSX for vSphere In this recipe, we will download the installation media for NSX for vSphere. The installation media comes in the form of an open virtual application (OVA) that is distributed through the VMware downloads site (https://my.vmware.com/web/vmware/downloads).

Getting ready To download NSX for vSphere, the following prerequisites must be satisfied: Valid VMware software entitlements that enable you to download the installation media Access to the VMware downloads website Access to VMware software manager. Download and install VMware software manager first (https://www.vmware.com/go/download-software-manager-en) VMware product interoperability matrix has been consulted so you know which version is compatible with your environment Where can I download VMware NSX for vShield endpoint? vSphere Essential Plus and later editions come with vShield endpoint. VMware NSX will appear on the vSphere download site similar to vCNS (vCloud Networking and Security).

How to do it... The following sections will explain how to check that your infrastructure supports the version of NSX you are implementing and how to obtain the download media.

Checking the Product Interoperability Matrix In this section, we will check to make sure the version of NSX we are deploying is compatible with the other VMware solutions in our environment. 1. Navigate your web browser to the VMware product interoperability matrix webpage (http://www.vmware.com/go/interop) 2. Select your vSphere solution as the first solution 3. Add VMware NSX for vSphere as your second solution

[ 16 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

4. Add any other solutions that are specific to your environment 5. Ensure all solution versions are compatible with one another before proceeding to download the NSX installation media The following screenshot shows the official VMware product interoperability matrices that should be referenced before downloading NSX for vSphere:

Downloading media via the VMware downloads website In this section we will download the installation media from the VMware downloads website as follows: 1. From your web browser, navigate to the VMware downloads website (https://my.vmware.com/web/vmware/downloads). 2. Scroll down to the Networking & Security menu item and click on Download Product

[ 17 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

3. Click on go to Downloads against your licensed tier for VMware NSX for vSphere 6.3.1 or whichever version is compatible with your environment 4. Click on Download Now Once you have downloaded the NSX for vSphere OVA, it is best practice to verify the file against the checksum listed to ensure that the downloaded file is an identical copy of the source.

Downloading media via the VMware Software Manager In this section, we will download the VMware NSX installation media using the VMware Software Manager, in contrast to a manual download via the downloads website: 1. Open the VMware Download Service application:

[ 18 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

2. 3. 4. 5.

Chapter 1

Click on the VMware vSphere software suite Select VMware vSphere 6.5 Select the licensing tier of your vSphere environment On the VMware NSX for vSphere menu pane, select the download button:

See also To make sure that your vSphere and NSX version is supported by VMware, check the VMware life cycle product matrix (http:/​/​www.​vmware.​com/​go/​lifecycle). This list contains a list of unsupported products as well.

Deploying the NSX Manager virtual appliance Deploying the NSX Manager virtual appliance is the first step to enabling network virtualization in your vSphere environment. In this recipe, you will go through the steps to enable your environment for NSX.

[ 19 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

The following diagram depicts the logical process of enabling your environment for network virtualization, and the first four steps will be covered in this chapter:

Getting ready Before deploying NSX Manager, the following prerequisites need to be satisfied: Static IP address and portgroup for NSX Manager Firewall ports open between NSX Manager, vCenter server, and ESXi VMKernel 0 Interface on each host (refer to Appendix for a complete list of ports)

[ 20 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

Forward and reverse DNS entries for NSX Manager NTP server is accessible; minimum of four is recommended for accurate time Shared datastore for the appliance to be deployed onto Satisfy minimum requirements for NSX Manager Fill in the following table before deployment (removing prefilled data to reflect your environment): Component

Value

NSX appliance name

nsxmgr-01a

NSX Manager hostname

nsxmgr-01a

vSphere cluster

RegionA01

Datastore

vsanDatastore

vSphere network (Portgroup) VM Network IPv4 address

192.168.1.111

Subnet mask

255.255.255.0

Default gateway

192.168.1.254

Domain name

corp.local

DNS server(s)

192.168.1.100

NTP servers(s)

192.168.1.100 (Use four in production)

Enable SSH

yes

CLI password

VMware1!

CLI privilege password

VMware1!

How to do it... The following steps will detail how to deploy the NSX Manager appliance: 1. Log into the vSphere Web Client 2. Select Hosts and Clusters, right-click on the target cluster and select Deploy OVF Template

[ 21 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

3. Select Local File and locate the NSX Manager OVA downloaded earlier; click on Next 4. Type in the Name of the virtual appliance and click on Next 5. Select the vSphere cluster and resource where you want to deploy NSX Manager and select Next 6. Review details, Accept license agreements and click on Next 7. Select the shared datastore of where you want the virtual appliance to be deployment onto 8. Select the VLAN-backed portgroup as defined earlier and click on Next 9. Fill in the template details as highlighted in the preceding table and click on Next 10. Ensure all details are correct and click on Finish:

[ 22 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

Replacing the NSX Manager certificate When you first deploy the NSX Manager, it creates a self-signed certificate. Using a selfsigned certificate is generally not a recommended security practice. It is recommended to deploy a signed certificate from your internal certificate authority. NSX Manager supports two ways of deploying a signed certificate, which are as follows: Certificate signing request to a Certificate Authority (CA) Importing a PKCS#12 certificate archive (bundle) onto the NSX Manager, which includes the private and public key for NSX Manager and certificate chain of any subordinate CAs in your environment In the following recipes, we will explore how you can create a certificate signing request on NSX Manager and how to import a PKCS#12 certificate bundle onto the NSX Manager.

Certificate Signing Request A Certificate Signing Request (CSR) is the first part in a three-step process; this process involves the following steps: 1. The NSX Manager creating a CSR 2. The CSR is sent as a request to the certificate authority, which then signs the certificate and sends back a signed certificate 3. Importing the signed certificate into the NSX Manager

How to do it... The procedure to complete a certificate signing request is as follows: 1. Log into NSX Manager via your web browser 2. Click on Manage Appliance Settings 3. Click on SSL Certificates

[ 23 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

4. Click on Generate CSR and follow the prompts as per the following screenshot:

5. Click on OK and select Download CSR 6. Send the CSR file to your security administrator and get the certificate signed 7. With the returned certificate, click on Import so you can import the correct certificate into the NSX Manager 8. Reboot the NSX Manager to complete the process of importing a signed certificate into the NSX Manager

PKCS#12 certificate Importing PKCS#12 into the NSX Manager is used when the certificate signing was not completed using the CSR method outlined in the previous recipe. The PKCS#12 format is typically used in scripted installations of NSX Manager and other components. If a CSR was not generated by the NSX Manager itself, it is required that the PKCS#12 archive is imported into NSX Manager.

[ 24 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

The PKCS#12 archive generally consists of the following: A signed server certificate A private key for the signed certificate Root and intermediate certificate authority public keys The PKCS#12 is also password-protected, so it's important to have the password before attempting to import the PKCS#12 archive into NSX Manager. In some cases, the received signed certificate may not be in the PCKS#12 format. In this event, you must convert the certificates into the PKCS#12 format for import into the NSX Manager. This can be achieved using openSSL (https://www.openssl.org/), and the command to achieve this is as follows: openssl pkcs12 -export -out server.p12 -inkey server.key -in server.crt certfile CACert.crt

How to do it... The procedure to import the PCKS#12 archive is as follows: 1. 2. 3. 4. 5. 6.

Log into the NSX Manager via your web browser Click on Manage Appliance Settings Click on SSL Certificates Click on Upload PCKS#12 Keystore and browse to the file Enter the password for archive and click on Import Reboot the NSX Manager to complete the process of importing the signed certificate

Registering vCenter server with NSX Manager Once the NSX Manager appliance has been deployed and is accessible via

https://nsxmgr-01a.corp.local, the next step is to register the NSX Manager as a

solution against your vCenter deployment. NSX Manager and a vCenter server have a 1:1 relationship, and it's important to ensure that no other NSX Manager has previously been registered.

[ 25 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

Getting ready The following are things you need to consider before pairing the NSX Manager with the vCenter server: Solution interoperability has been verified vCenter server and vSphere environment are in a healthy state Platform Services Controller (PSC) Fully Qualified Domain Name (FQDN) can be resolved vCenter server FQDN can be resolved vCenter and PSC time settings are verified A service account with administrator role in vCenter has been created for the NSX Manager to use for registration; for further information refer to Chapter 9, Managing User Accounts in VMware NSX TCP port 443 connectivity is required from the NSX Manager to the platform services controller and the vCenter server vCenter server and platform services controller high availability options have been consulted to ensure the vCenter and PSC environment are set up as per VMware recommendations. For further information on supported vCenter high availability options, refer to the VMware KB article 1024051 (https://kb.vmware.com/kb/1024051).

How to do it... The following section describes the steps to integrate NSX Manager with the vCenter server and the platform services controller, which are the first steps in enabling your environment for NSX.

Registering the NSX Manager with the vCenter server The following are the steps to pair the NSX Manager with the vCenter server: 1. Log into the NSX Manager web administration page: https://nsxmgr-01a.corp.local 2. Navigate to Manage | NSX Management Services, and on the Lookup Service URL click on Edit

[ 26 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

3. Type the Lookup Server Host as the PSC FQDN or vCenter Server FQDN if using an embedded PSC 1. For SSO Administrator Use Name, use the service account credentials defined 2. Click on OK to complete 3. When presented with the Trust Certificate dialog box, verify the SSL certificate thumbprint and click on Yes:

Modify Plugin Script download location This should only be modified if the NSX Manager is behind a firewall or "NAT" device which is masking the original IP address of the NSX Manager; in typical deployments, it will not require modification.

[ 27 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

Registering the NSX Manager with the PSC In this section we will register the NSX Manager with the Platform Services Controller for Single Sign-On services: 1. Navigate back to the NSX management service web page on the NSX Manager web administration page: https://nsxmgr-01a.corp.local 2. On the vCenter Server menu, click on Edit: 1. Type the vCenter Server FQDN 2. Type the service account credentials for the vCenter Service account and click on OK:

3. When presented with the Trust Certificate dialog box, verify the SSL certificate thumbprint and click on Yes

[ 28 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

How it works... The NSX Manager registers the com.vmware extension. This extension is installed on the vSphere web server as a plugin. When the plugin is installed onto the vSphere web server, any users that were logged in during integration will need to log out of the vSphere Web Client before they can start to consume the Networking & Security interface. It is important to note that the account used from the NSX Manager to connect to vCenter server will be given enterprise administrator credentials. The NSX Manager uses the vSphere API to perform functions such as deploying service virtual machines, instructing the EAM service to prepare ESXi hosts, creating distributed portgroups, and other vSphere operations that it needs for NSX operations.

There's more... If the event registration fails with the platform services controller, check the following commons issues first: NTP Synchronization (time) for NSX Manager, platform services controller, and vCenter server is correct and aligned DNS resolution for all components Firewall ports are open if the NSX Manager and the PSC/vCenter server are separated in different security zones

Applying the NSX license As described in choosing the right VMware NSX for vSphere edition, this section will describe the process of applying the license you have procured to utilize the features of NSX.

Getting ready Things to verify before applying the NSX for vSphere license: Correct license procured for installation of NSX NSX has been integrated as a solution with your vSphere deployment

[ 29 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

How to do it... Perform the following steps to apply the NSX license to your installation: 1. Log into the vSphere Web Client and click on Administration 2. Click on Licenses under the Licensing section on the sidebar 3. Select the Licenses tab and click on the plus sign: 1. Enter your license key and click on Next 2. Create a descriptive name for your license and click on Finish 4. Next, select the Solutions tab and select the NSX Installation: 1. Navigate to Actions | Assign License 2. Select the license you added earlier and click on OK

Deploying the NSX Controller Cluster The NSX controller cluster is an integral part of any NSX for vSphere deployment; the NSX controller cluster is responsible for: Managing the vSphere hypervisor routing and switching modules Managing the ARP table, MAC table, and VXLAN network identifier (VNI) information of the entire vSphere for NSX deployment Distributed Logical Router: Interfaces Layer 2 Bridging Tables Routes The NSX Controller Cluster is the control plane for all networking constructs in an NSX deployment, however, the Distributed Firewall control plane is managed by the NSX Manager itself.

[ 30 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

Getting ready The following are things to consider before deploying the NSX controller cluster: The controller cluster has three controllers in total and must be deployed in a cluster of three. Each controller node should reside on a separate ESXi host; DRS anti-affinity rules should be used to enforce this rule. It is generally recommended to deploy controllers on a vSphere cluster with a minimum of four ESXi hosts. Sufficient resources (vCPU, memory, and storage) on the vSphere cluster. NSX controller nodes should be deployed onto shared storage that is highly available. Each NSX controller requires an IPv4 address; these addresses are allocated via the NSX IP pool construct. NSX controllers require connectivity to NSX Manager and vSphere management VMKernel IP addresses. NSX controller should reside on a VLAN-backed PortGroup. The NSX Controller IP Pool requires the following details prior to configuration. You can change values to suit your environment: Component

Value

Name

IP-Pool-NSX-Controllers

Gateway

192.168.1.254

Prefix Length

24

Primary DNS

192.168.1.110

Secondary DNS DNS Suffix

corp.local

Static IP Pool

192.168.1.31 - 192.168.1.33

How to do it... In the following sub-sections, we proceed to start deploying the NSX controller cluster, which is required for the logical networking components in NSX.

[ 31 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

Configuring an NSX IP pool Before deploying the NSX controller cluster, an IP pool must be configured to reserve three IPv4 addresses on the network: 1. In the vCenter Web Client, navigate to Networking & Security | NSX Managers | NSX Manager 2. Select IP Pools and click on the plus sign 3. Fill in the details as per the preceding table and click on OK The IP Pool can be configured during deployment of the NSX controller cluster as well in the event it is not configured beforehand.

NSX Controller Cluster deployment In this section, we will deploy each of three NSX Controllers on our vSphere cluster: 1. In the vCenter Web Client, navigate to Networking & Security | Installation 2. Under the NSX controller nodes menu pane, click on the plus sign 3. Fill in the NSX controller details for the first node as follows and then click on OK: Name

Value

Name

NSX_Controller_1

Datacenter

RegionA01

Cluster/Resource Pool RegionA01-MGMT01 Datastore

RegionA01-iSCSI-MGMT

Host

Optional

Folder

Optional

Connected To

VM-RegionA01-vDS-MGMT

Password

VMware1!VMware1!

4. After the first controller is deployed, repeat steps 1 to 3 for the remaining two controllers

[ 32 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

Once all the controllers have been deployed, you should see the following displayed under the Installation tab in Networking & Security, with the green boxes indicating healthy connectivity between each of the peers in the controller cluster:

DRS Anti-Affinity Rules DRS anti-affinity rules are required to ensure that the NSX controllers do not reside on the same physical host and are kept separate on dedicated ESXi hosts. This is to ensure in the event a ESXi host goes down where all three controllers are potentially running as guest VMs, the entire control plane for logical networking is not lost. If two controllers are lost, then the remaining controller goes into read-only mode until a cluster majority is restored. It's important to note that the underlying infrastructure should still be designed for HA and resiliency, which includes compute/network/storage. Configuring DRS anti-affinity rules via the vSphere web client: 1. In the vCenter Web Client, navigate to Hosts and Clusters | Management Cluster | Manage | Settings | VM/Host Rules 2. Click on Add... 3. Choose Type as Separate Virtual Machines

[ 33 ]

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

4. Add NSX controller virtual machines and click on OK:

Configuring DRS Anti-Affinity Rules via PowerCLI You can also configure DRS anti-affinity rules using PowerCLI. To configure via PowerCLI, you will need to ensure PowerCLI has been deployed and installed locally on your system. Perform the following steps to configure the DRS rules via PowerCLI: 1. Open the PowerCLI terminal up. 2. Type Connect-VIServer -Server VCENTER_SERVER, which will connect your PowerCLI session to the vCenter server you are working on.

[ 34 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

3. Next, we want to retrieve the NSX controller virtual machines and store it as a variable, $nsx_controllers, using the get-vm PowerCLI cmdlet. The following code snippet demonstrates the command: $nsx_controllers = get-vm | ? {$_.name -like "NSX_Controller*"}

4. Next, using the New-DRSRule cmdlet, we will configure the anti-affinity DRS rule on the RegionA01-MGMT01 vSphere cluster using the following command: New-DrsRule -Name nsx-controller-anti-affinity -Cluster RegionA01-MGMT01 -KeepTogether $false -VM $antiAffinityVMs

There's more... In the following sub-sections, placement of the NSX Controllers and Controller password configuration will be discussed in greater detail.

Separate vCenter environment The controller cluster is deployed in a group of three. Each controller node can only be deployed onto a vSphere cluster that is part of the vCenter inventory that the NSX Manager you are configuring is paired with. In large environments with multiple vCenters, it is not uncommon for the vCenter server and NSX Manager to be deployed onto a dedicated vSphere cluster that is managed by an independent vCenter server that is deemed as management. In this scenario, the NSX controller cluster cannot be deployed onto the dedicated management vSphere cluster.

Controller password parameters The NSX controller password must meet the following criteria: It must not contain the username as a substring A character must not be repeated consecutively more than three times It must be at least 12 characters long and must follow three of the following four rules: It must have at least one uppercase letter It must have at least one lowercase letter It must have at least one number It must have at least one special character

[ 35 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

In the event that the NSX controller password is forgotten, it can be easily changed using the following steps: 1. Log into the vSphere Web Client 2. Click on the Networking & Security tab and then navigate to Installation | Management: 1. Under the NSX Controller nodes menu, select Actions 2. Click on Change Controller Cluster Password 3. Type a new password following the preceding guidelines and click on OK:

Preparing a vSphere cluster for NSX Preparing a vSphere cluster for NSX does two things: 1. It installs NSX Kernel modules on each ESXi host, which is a member of the vSphere cluster 2. It builds the NSX control-plane and management-plane fabric NSX Kernel modules are packaged as VMware installation bundles (VIBs) and provide functionality such as distributed routing, distributed firewall, and VXLAN bridging.

Getting ready To get ready for installation, ensure that the following prerequisite tasks have been completed: DNS forward and reverse names have been created for all ESXi hosts and are resolvable

[ 36 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

Firewall Ports between all management components are open vCenter Update Manager Service, if in use, is operational Ensure that the EAM service is operational Ensure that the NTP settings are checked across all ESXi hosts and are updating time correctly ESXi stateless mode If you are using ESXi in stateless mode, you must download the NSX VIBs manually and integrate them into the host image. Refer to VMware Knowledge Base Article 2041972 (https://kb.vmware.com/kb/2041972) for more information. Download paths of NSX VIBs change with each release. To check the paths for your NSX release, use the following URL: https:///bin/vdn/nwfabric.properties.

How to do it... Perform the following steps to start the installation of the NSX VIBs onto your first vSphere cluster; we will be enabling it on vSphere Cluster RegionA01-COMP01 to begin with: 1. In the vCenter Web Client, navigate to Networking & Security | Installation | Host Preparation 2. Select the vSphere Cluster RegionA01-COMP01 3. Click on the COG wheel and select Install:

[ 37 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

Each ESXi host in the cluster will now download the VIBs from vCenter Server, where they were downloaded from NSX Manager and cached when NSX was registered as a solution. Depending on the number of hosts in the vSphere cluster, this process will take a few minutes to complete. Once the installation has completed, you will be presented with a screen like the one shown in the following screenshot:

How it works... The following figure depicts the management, control, and data plane components that make up an NSX implementation. Each has an important part to play in enabling ESXi for the Distributed Firewall and VXLAN. In this section, we will explore the interaction among the various components: vCenter server: This is the management component of the vSphere environment and is where the networking and security components of an NSX environment are all managed from. NSX Manager: This is the management plane of the NSX implementation. It integrates directly with vCenter and manages both the NSX controller cluster and the ESXi hosts. The NSX Manager is also responsible for pushing distributed firewall rules to each host that is prepared for the distributed firewall. In addition, the NSX Manager is also the API entry point for NSX operations via the REST protocol. ESXi Agency Manager (EAM): This is part of the vCenter deployment; it is responsible for installing the VIBs to each of the hosts. When you prepare a vSphere cluster for NSX, the VIBs are copied directly from NSX Manager and cached by EAM. The EAM will then track the installation of each VIB onto each host in the vSphere cluster. If the VIB is not present, it is installed without the ESXi host requiring a reboot, and if it is present, a reboot is required to complete the upgrade.

[ 38 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

Once the installation of VIBs has been completed, each ESXi host will have active TCP connections to the NSX Manager and NSX controller cluster. The connection to the NSX Manager is from the vsfwd daemon running on the ESXi host via the RabbitMQ message bus. The connection to the NSX Controller cluster is from the netcpa daemon running on the ESXi host via an SSL connection (TCP Port 1234). It is important that both channels of communication are active and can be checked via the communication channel health from each host, which is covered in a subsequent section:

[ 39 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

Enabling NSX in a brownfield environment When enabling a vSphere cluster for NSX in a brownfield environment, it is important to be cognizant that any preconfigured DFW firewall rules have the potential to impact virtual machines on the newly-configured vSphere cluster. Therefore, it is extremely important to ensure that the default Distributed Firewall rule remains as allow any any. Changing to deny before defining rules for allowing legitimate traffic from/to virtual machines will cause traffic blackholing. As a best practice, vCenter server and virtual machines that require promiscuous mode should be excluded from the DFW if you are not planning to protect them. To learn how to exclude virtual machines from the DFW, refer to Chapter 6, Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard.

Validating NSX VIB installation Installation of NSX VIBs that enable the Distributed Firewall and VXLAN are essential for a working NSX environment. This section will investigate how to manually verify that each VIB is installed correctly and whether communication to both the NSX controller cluster and NSX Manager are present.

Distributed Firewall communication The first control plane communication that we are concerned with is from the NSX Manager to each ESXi host via TCP port 5671. This port is reserved for the Rabbit MQ Message bus to the vsfwd daemon running on each host after the VMware Service Insertion Platform (VSIP) VIB installation, which is the Distributed Firewall kernel module. The NSX Manager uses the message bus to publish firewall rules down to each ESXi host. The ESXi host then applies them to vNICs of virtual machines that are running on top of its hypervisor.

[ 40 ]

||||||||||||||||||||

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

Controller communication The second control plane communication that is expected from each ESXi host is an open connection to each of the NSX controllers deployed. The NSX controller cluster is responsible for control plane information for ARP/MAC/VTEP tables. It is also used to program routes received on the Distributed Logical Router Control VM to each host (more on this in Chapter 2, Configuring VMware NSX Logical Switch Networks). From each host, we expect the netcpa daemon to have an active connection to the controller cluster on TCP port 1234.

Getting ready To manually verify control-plane communication and VIB installation, you will need the following access to the following NSX components: SSH access to NSX Manager SSH access to each NSX controller SSH access to ESXi hosts that were prepared for NSX You would not be expected to check communication of each and every host in your environment, as this can become unwieldly. However, this section is included for you to understand what the expected communication is, but in large deployments you would check the communication channel health per vSphere cluster as depicted in the earlier section.

How to do it... To check whether the NSX VIBs have been installed successfully is crucial. The upcoming section details how to do this manually on an ESXi host and how to check NSX component communication.

[ 41 ]

||||||||||||||||||||

Getting Started with VMware NSX for vSphere

Chapter 1

Manually checking VIB installation In this section we perform manual verification that the VIBs have been successfully installed. 1. SSH onto an ESXi host. 2. Check whether VXLAN VIB modules have been installed by executing the following command: esxcli software vib get --vibname esx-vxlan

3. You will receive an output similar to the following: [root@vSphere:~] esxcli software vib get --vibname esx-vxlan VMware_bootbank_esx-vxlan_6.0.0-0.0.4987429 Name: esx-vxlan Version: 6.0.0-0.0.4987429 Type: bootbank Vendor: VMware Acceptance Level: VMwareCertified Summary: Vxlan and host tool Description: This package loads module and configures firewall for vxlan networking. ReferenceURLs: Creation Date: 2017-01-27 Depends: esx-base >= 6.0, esx-base show hardware-gateway list nsx-controller> show hardware-gateway hardware-gateway

Additional information on how to attach a hardware port on NSX is covered in the next recipe.

See also The following are some relevant links that provide more information on integrating hardware VTEP gateway with VMware NSX: VMware KB 2146056 Dell Networking VXLAN Hardware Gateway with NSX: https://kb.vmware.com/s/article/2146056

[ 153 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Layer 2 Bridging

Chapter 4

VMware KB 2149268 Cumulus Linux, Integration with VMWare NSX for vSphere 6.2.4: https://kb.vmware.com/s/article/2149268 VMware KB 2147902 QFX5100 HW VTEP Support for NSX for vSphere 6.2.4: https://kb.vmware.com/s/article/2147902 VMware KB 2146500 Support for Arista CloudVision with NSX for vSphere 6.2.x: https://kb.vmware.com/s/article/2146500 VMware KB 2146125 Brocade IP & VCS Fabric Gateways for VMware NSX for vSphere 6.2.3: https://kb.vmware.com/s/article/2146125 VMware KB 2148611 Huawei CloudEngine Hardware Gateway with NSX: https://kb.vmware.com/s/article/2148611

Extending VMware NSX Logical Switch to Hardware VTEP Gateway In this recipe, we will show you how to extend VMware NSX logical switch to a hardware VTEP Gateway port. In this example, we will bridge a logical switch called DB-Tier to leaf-01a hardware VTEP gateway on the physical port Eth1/11 on VLAN 203, as shown in the following screenshot:

Getting ready To configure a hardware VTEP gateway for layer 2 bridging, the following prerequisites need to be met: NSX Manager must be deployed and configured

[ 154 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Layer 2 Bridging

Chapter 4

NSX Controllers must be deployed VXLAN must be configured NSX logical switch must be created Hardware switch controller must be added into VMware NSX Before the hardware port is attached to the relevant logical switch, VXLAN and OVSDB configuration must be completed on the hardware switch.

How to do it... The following steps will show you how to bridge an existing NSX logical switch to a hardware VTEP gateway: 1. Navigate to Networking & Security | Logical Switches. 2. In the center pane, select a logical switch name that you want to bridge to hardware VTEP gateway port. You can either: Click the Actions button in the center pane and select Manage Hardware Bindings. Right-click the logical switch name and select Manage Hardware Bindings:

3. A new Manage Hardware Bindings dialog box will appear.

[ 155 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Layer 2 Bridging

Chapter 4

4. Select your desired Switch, Port, and VLAN ID on the physical switch. In this example, we are extending the DB-Tier logical switch to the leaf-01a switch on Port Eth1/11 with VLAN 203. 5. Review your settings and click the OK button. 6. Additional configuration steps may be required in the hardware device, depending on the vendor.

How it works... Once the hardware binding is configured, the NSX controller will push the configured binding between logical switch and physical switch/port/VLAN to the hardware gateway via HSC. The NSX controller will advertise to the HSC the list of ESXi VTEPs relevant to the logical switches configured and the association between the MAC address of the VMs in the virtual network and the VTEP through which they can be reached. Depending on the hardware vendor implementation, additional configuration may be required after configuring hardware binding to the logical switch. For example, adding the bridged VLAN ID to one or more physical ports needs to be done manually for a specific vendors, but other vendors can perform these configurations automatically through their own APIs, such as NETCONF or other methods.

There's more... Inter-VNI communication using NSX requires a routing component such as DLR or ESG. This allows routing between IP subnets to be done in the logical space without using the physical router. The DLR provides distributed routing functionality using hypervisor kernel modules and is an optimal solution for routing east-west traffic. However, due to feature limitations in the current NSX release (at the time of writing this book), the logical switch that is bridged through the hardware VTEP cannot use DLR functionality for routing. As an alternative, east-west routing can be performed on NSX Edge ESG or a physical router.

See also Hardware layer 2 gateways integration with NSX: https://communities.vmware.com/docs/DOC-30976.

[ 156 ]

||||||||||||||||||||

||||||||||||||||||||

5 Configuring VMware NSX Edge Services Gateway In this chapter, you will learn how to configure VMware NSX Edge Services Gateway (ESG) application services. We will be looking at the following recipes: Configuring a DNS relay Configuring a DHCP server Configuring an Edge Firewall Configuring Network Address Translation Configuring Load Balancing Configuring IPSEC VPN Configuring SSL VPN Configuring High Availability To complete all of these recipes, you will need to use a user that has rights to configure. If in doubt, please refer to Chapter 9, Managing User Accounts in VMware NSX.

Introduction The NSX ESG comes in a virtual machine form factor that is managed solely by NSX. The ESG has many different functionalities in addition to routing, which provide the advanced functionalities of the NSX for vSphere platform. Each ESG can run one or more of these application services, but an ESG can also be deployed for a single purpose, which is very common in many enterprise deployments. This is done for many reasons, as an ESG used for load balancing in one-armed mode may be tied to the application, therefore it should be commissioned with the application and decommissioned with the application.

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

The services that can be run on the NSX ESG are as follows: DNS relay DHCP server Network Address Translation (DNAT and SNAT) Load Balancing (layer 4 and layer 7) Routing: BGP OSPF Static VPN services:

Layer 2 VPN (L2VPN) IPSEC VPN SSL VPN

We will explore these core services in this chapter. For the layer 2 VPN service, which is not covered in this chapter, please refer to the NSX Administration Guide at https://docs.vmware.com/en/VMware-NSX-for-vSphere/.

Configuring a DNS relay A DNS relay is an intermediary device that clients send DNS queries to. This intermediary device then forwards the request to upstream DNS servers. Once a response is received, the intermediary device will send the same response back to the original client and cache the response in the event of other clients requiring the same DNS resolution. In the case of the NSX Edge, it acts as the intermediary device and can resolve DNS queries for clients if the clients have IP reachability to the ESG and are configured to use it as a DNS server.

Getting ready To configure the ESG for DNS relay, the following prerequisites must be met: User with NSX Enterprise Administrator or NSX Administrator role Newly-deployed NSX Edge to configure DNS relay on; we will use a pre-created edge named Chapter5 for this recipe

[ 158 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

ESXi cluster where the the NSX Edge will be deployed to; it must be prepared for NSX Target ESXi hosts must have sufficient capacity to run the ESG virtual machine

How to do it... The following steps detail how to configure the DNS relay on the ESG: 1. 2. 3. 4.

Log in to the vSphere web client via a web browser. Navigate to Networking & Security. Select NSX Edges and select the newly-created edge: Chapter5. Under the Chapter5 configuration, navigate to Manage | Settings | Configuration. 5. Click Change in the DNS Configuration menu pane:

6. Tick Enable DNS service. 7. Enter at least one DNS server into the configuration pane; in this example, we will use Google DNS servers. 8. Leave the Cache Size as the default 16 MB.

[ 159 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

9. Tick Enable Logging and set Log level to Info:

10. Click OK to publish the changes.

There's more... For the DNS relay service to start on the NSX ESG, at least one internal interface must be configured to service DNS requests on. The DNS relay service will only service requests on internal interfaces. To check whether the service has started, SSH onto the NSX ESG and execute the following command: show service-monitor summary

[ 160 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

The bind9 service is the service we want to ensure is in the Running state. To verify the contents of the cache, the following commands can be executed on the NSX ESG for further diagnostic information: show service dns cache show service dns zones

Configuring a DHCP server A DHCP server is required in networks where client machines (physical/virtual) are not assigned a static IP address; in this case, they use the DHCP mechanism to retrieve an IP address from a server. NSX ESGs provide the ability to act as a DHCP server on your network. The NSX Edge can be configured with multiple IP pools with common DHCP attributes and can also be used to set up reservations on your network.

[ 161 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

The following diagram depicts the logical topology for the DHCP ESG, with the distributed logical router providing DHCP relay services to forward DHCP queries to the ESG. In addition, it includes the parameters we will use to configure the DHCP pool on the NSX ESG:

[ 162 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

Getting ready To configure the ESG for a DHCP server, the following prerequisites must be met: User with NSX Enterprise Administrator or NSX Administrator role Newly-deployed NSX edge to configure the DHCP server on; we will use a precreated edge named Chapter5 for this recipe ESXi cluster where the the NSX edge will be deployed to; it must be prepared for NSX Target ESXi hosts must have sufficient capacity to run the ESG virtual machine

How to do it... The following steps detail how to configure the DHCP server on the ESG: 1. 2. 3. 4. 5.

Log in to the vSphere Web Client via a web browser. Navigate to Networking & Security. Select NSX Edges and select the newly-created edge: Chapter5. Under the Chapter5 configuration, navigate to Manage | Settings | DHCP. Enable the DHCP service by clicking Enable and then Publish Changes:

[ 163 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

6. Click the Add button to configure a pool. 7. In the Add DHCP Pool configuration pane, configure the fields as follows for the client subnet 192.168.200.0/24:

8. Click OK to complete the configuration. 9. Click Publish Changes for the configuration to be pushed to the ESG.

[ 164 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

10. Next, click Bindings to configure a one-to-one static IP address binding. 11. Click the Add button to configure a binding. 12. Configure the MAC binding parameters for your chosen virtual machine as per the following screenshot:

[ 165 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

13. Click OK to complete the configuration. 14. Click Publish Changes for them to be pushed to the ESG.

There's more... When configuring a DHCP server on the NSX ESG, it is important to note the following parameters: DHCP discovery messages are only listened to on internal interfaces and not on uplink interfaces Static IP address bindings should not overlap any pools you have already created Static bindings can use either VM NIC binding for virtual machines that reside in vCenter or MAC binding The Host Name field for all static bindings should conform to the following standards: Valid local hostname (label) contains only ASCII alphabet, numbers, and hyphens, with length at most 63 Valid FQDN hostname has labels concatenated with dots, with each label length at most 63 and total FQDN length at most 253

Configuring an Edge Firewall In addition to the NSX Distributed Firewall, NSX also provides firewall functionality on the NSX ESG. The Edge can perform layer 2 to layer 4 firewalling, and is intended to complement the Distributed Firewall to restrict north/south flows from a logical networking segment.

[ 166 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

In this recipe, we will configure a single firewall rule on the NSX ESG to allow SSH access from a virtual machine. The following diagram depicts the topology for this recipe and the ESG where the firewall rule will be configured:

[ 167 ]

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

Getting ready To configure the ESG for firewall rules, the following prerequisites must be met: User with NSX Enterprise Administrator or NSX Administrator role Newly-deployed NSX edge to configure the firewall on; we will use a pre-created edge named Chapter5 for this recipe ESXi cluster where the the NSX edge will be deployed to; it must be prepared for NSX Target ESXi hosts must have sufficient capacity to run the ESG virtual machine

How to do it... The following steps detail how to configure the ESG firewall: 1. 2. 3. 4. 5. 6. 7.

Log in to the vSphere web client via a web browser. Navigate to Networking & Security. Select NSX Edges and select the newly-created edge: Chapter5. Under the Chapter5 configuration, navigate to Manage | Settings | Firewall. Click Add to create a new firewall rule. Edit the name of the firewall rule and call it Allow SSH Outbound Access. Select source as Object Type: Virtual Machine and select web-01a.corp.local:

[ 168 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

It is recommended to have VMware Tools installed on virtual machines if selecting them for a source or destination in a firewall rule or have IP detection turned on, as explained in Chapter 6, Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard.

[ 169 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

8. Click OK. 9. Leave destination as any. 10. Select Service and search for ssh:

11. 12. 13. 14.

Select SSH and click OK. Click Publish Changes for them to take effect on the ESG. Ensure Firewall Status is Enabled; if not enabled, select Enable. Review final firewall rule table:

[ 170 ]

Chapter 5

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

There's more... When configuring source or destination firewall rules, you can also choose the following attributes: VSE Internal External VSE is chosen if you want to restrict traffic generated by the ESG. Internal and External are used to restrict traffic coming from either internal or uplink interfaces, and when you configure additional interfaces of either type, the corresponding firewall rule is automatically updated. In addition to user-defined firewall rules, the ESG also provides the ability to create autogenerated rules, which are created by the ESG when you enable application services. You can control this setting using the following steps: 1. 2. 3. 4.

Log in to the vSphere web client via a web browser. Navigate to Networking & Security. Select NSX Edges and select the newly-created edge: Chapter5. Under the Chapter5 configuration, navigate to Manage | Settings | Configuration.

[ 171 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

5. Click Actions on the Details configuration pane:

6. Click Change Auto Rule Configuration:

7. Select Enable auto rule generation and check Rule Priority as High. Auto rule configuration is on by default and is generally recommended to be left on; if an administrator configures additional application services, firewall rules are automatically updated without user intervention. When adding other services to the ESG, it will create autogenerated rules for those services unless explicitly turned off.

[ 172 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

Configuring Network Address Translation An NSX ESG also provides Network Address Translation (NAT) capability to allow mapping of a public IP address to devices that are on private IP addresses space or have overlapping IP addresses. The ESG provides the ability to configure two types of NAT, which are as follows: Source NAT (SNAT): This is the most common type of NAT and is used to change the source address of the packet passing through Destination NAT (DNAT): Used to change the destination IP address of the packet passing through; it is generally used to change from a public IP address to private RFC 1918 address on the internal network In this recipe, we will configure both SNAT and DNAT for our Windows VM. The configuration of each is depicted in the following figure:

[ 173 ]

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

As you can see in the preceding figure, for the SNAT example we will be changing the source address from 192.168.200.201 to 10.0.0.170, and for the DNAT example we will be changing the destination address from 10.0.0.171 to 192.168.200.201. Each example will be of one-to-one NAT, but it can easily be adapted to include a network pool if required; the procedure would be identical.

Getting ready To configure the ESG for NAT rules, the following prerequisites must be met: User with NSX Enterprise Administrator or NSX Administrator role Newly-deployed NSX edge to configure the NAT on; we will use a pre-created edge named Chapter5 for this recipe NSX edge firewall must be enabled, as NAT services rely on this feature ESXi cluster where the NSX edge will be deployed to; it must be prepared for NSX Target ESXi hosts must have sufficient capacity to run the ESG virtual machine

How to do it... The following sections will explain how to create a DNAT and SNAT rule on the ESG.

Configuring an SNAT rule The following steps detail how to configure an SNAT rule on the ESG: 1. 2. 3. 4. 5. 6. 7.

Log in to the vSphere web client via a web browser. Navigate to Networking & Security. Select NSX Edges and select the newly-created edge: Chapter5. Under the Chapter5 configuration, navigate to Manage | Settings | NAT. Click Add to create a new NAT rule and select Add SNAT Rule. Select the Uplink interface to apply the Source NAT rule to. Configure the remaining parameters as per the following screenshot:

[ 174 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

8. Click Publish Changes to push the configuration to the ESG. 9. SSH onto the ESG and execute the command show nat to view the NAT configuration. Your output should be similar to the following screenshot:

[ 175 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

Configure a DNAT rule The following steps detail how to configure a DNAT rule on the ESG: 1. 2. 3. 4. 5. 6. 7.

Log in to the vSphere web client via a web browser. Navigate to Networking & Security. Select NSX Edges and select the newly-created edge: Chapter5. Under the Chapter5 configuration, navigate to Manage | Settings | NAT. Click Add to create a new NAT rule and select Add DNAT Rule. Select the uplink interface to apply the source NAT rule to. Configure the remaining parameters as per the following screenshot:

[ 176 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

8. Click Publish Changes to push the configuration to the ESG. 9. SSH onto the ESG and execute the command show nat to view the NAT configuration. Your output should be similar to the following screenshot:

How it works... In this recipe, we configured NAT policies for both DNAT and SNAT; each type can be configured on any edge and the two types are not mutually exclusive. However, the edge firewall is required to be enabled for NAT rules to be processed. You do not need to explicitly define firewall rules and can leave the default rule to allow any, if your security policy permits, but ensuring the firewall is enabled is critical. When a NAT rule is created of either type, the rule needs to be tied to an interface where the rules will be processed. Typically, this is done on the egress/ingress interface; in our recipe, we used the Uplink interface. After defining the interface, the remaining two mandatory parameters for each NAT type are as follows: DNAT:

SNAT:

Original destination IP/range Translated IP/range Original source IP/range Translated source IP/range

Each NAT type requires these parameters as a minimum, with more specific parameters given if specific protocols or ports need to be matched. But using these mandatory parameters ensures there is no reliance on any higher-level properties.

[ 177 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

There's more... As of NSX version 6.3, the maximum NAT rules per ESG form factor are as follows: Form factor Number of NAT rules Compact

2,048

Large

4,096

Quad Large 4,096 X-Large

8,192

Please refer to Recommended Configuration Maximums for NSX at https:/​/​docs.​vmware. com/​en/​VMware-​NSX-​for-​vSphere/​6.​3/​NSX%20for %20vSphere%20Recommended%20Configuration%20Maximums_​63.​pdf for the latest

information.

Configuring Load Balancing Load balancing is a complex network task that is typically performed by a physical network infrastructure; however, NSX can provide a software-based approach to load balancing. The load balancing features provided by the ESG are feature-rich; the edge supports both layer 4 (Accelerated Virtual Server) and layer 7 (Full Proxy Virtual Server) load balancing engines. Some of the features that the edge load balancing feature set provides are as follows: Layer 4 protocols: TCP/UDP Layer 7 protocols: HTTP/HTTPS SSL termination with AES-NI acceleration Health checks for TCP/UDP and HTTP/HTTPS Persistence URL rewrite and redirection The load balancing algorithms supported are as follows: Weighted Round Robin IP hash URI Least connection

[ 178 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

This list is not exhaustive but is included with the most commonly used features for your reference. In addition, NSX supports two deployment models, inline and one-armed mode (also known as proxy mode); for the purposes of the recipe, we will configure a one-armed NSX edge Load Balancer to support TCP load balancing (layer 4) for our application servers that are depicted in the following figure:

Based on the preceding figure, we have a One-Armed Load Balancer ESG residing on the web logical switch with an IP address of 172.16.33.2; in addition, we have our web servers with their respective IP addresses of 172.16.33.10 and 172.16.33.11. The OneArmed Load Balancer is sitting behind the distributed logical router, which is in turn its default gateway.

[ 179 ]

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

In the diagram, there are two stages to the request from the user, which are as follows: 1. The user initiates a request to the domain name of the website it is trying to resolve; the DNS record points to the virtual IP (VIP) of the One-Armed Load Balancer edge gateway. The DNS infrastructure is not depicted in this example, but it is expected that a DNS record has been created, otherwise use the IP address of the VIP to replicate a session. 2. The One-Armed Load Balancer ESG receives the request and, depending on the configuration it has, it will send the request to either of the two web servers if the health check reports them as both healthy; if one is unhealthy, the request will be sent to the remaining healthy node. In this recipe, we will explore how to configure the One-Armed Load Balancer ESG and how to configure the Load Balancer for layer 4 Load Balancing.

Getting ready To configure the ESG for load balancing, the following prerequisites must be met: User with NSX Enterprise Administrator or NSX Administrator role NSX edge firewall must be enabled, as load balancing services rely on this feature vSphere cluster where the edge will be deployed to; it must be prepared for NSX Target ESXi hosts must have sufficient capacity to run the ESG virtual machine

How to do it... In the following subsections, you will deploy, configure and verify a One-Armed Load Balancer on a Edge Services Gateway.

Deploying an NSX Edge Load Balancer The following steps detail how to configure an ESG for load balancing: 1. Log in to the vSphere Web Client via a web browser. 2. Navigate to Networking & Security.

[ 180 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

3. Select NSX Edges, and click the Add button. 4. Configure the new edge with the configuration as per the following screenshot:

5. For Username and Password, use something unique and secure. For the purposes of this recipe, we will use the following configuration: User Name: admin Password: VMware1!VMware1!

[ 181 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Enable SSH access Enable auto rule generation:

[ 182 ]

Chapter 5

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

6. Select the Cluster/Resource Pool and Datastore as per the following screenshot:

[ 183 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

7. Select the Datacenter and form factor for the new edge. We will select X-Large for load balancing. Click Next:

[ 184 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

8. Configure the Uplink Interface with the logical switch as LS-WEB and IP Address of 172.16.33.2 and prefix of 24. Ensure connectivity status is Connected and click OK and then click Next:

[ 185 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

9. For Default gateway settings, select the vNIC as LS-WEB. Gateway IP should be of the distributed logical router LS-WEB interface, which is 172.16.33.1. Leave the remaining fields as default and click Next:

10. In the Firewall and HA configuration pane, ensure the Configure Firewall default policy checkbox is checked and the Default Traffic Policy is set to Accept. Click Next:

[ 186 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

11. Review the configuration as per the following screenshot and click Finish:

Configuring an NSX Edge Load Balancer The following steps detail how to configure the Load Balancer on an ESG: 1. Log in to the vSphere web client via a web browser 2. Navigate to Networking & Security 3. Select NSX Edges and select the edge named One-Armed-LB

[ 187 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

4. Go into the Load Balancer configuration tab as per the following screenshot:

5. Under the Global Configuration submenu, click Edit and Check Enable Load Balancer and Enable Acceleration. Click OK:

6. Change the Name and Description fields as per the following screenshot:

[ 188 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

7. Click Add under the Members sub-menu in the New Pool dialog box:

8. Create a new member for VM web-01a using the IP address and not the VM object in the IP Address/VC Container field. Next, ensure port 80 is configured for the Monitor Port. Click OK:

[ 189 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

9. Repeat step 7 for virtual machine web-02a. 10. Ensure the Monitors selection is default_http_monitor and click OK:

[ 190 ]

Chapter 5

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

11. Click Show Pool Statistics to check whether both members are reported as Up:

12. Next, click the Application Profiles submenu and click Add:

[ 191 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

13. Change the Name of the profile to WEB_APP_PROFILE, select Type as TCP, and choose Persistence as Source IP. Click OK once complete:

[ 192 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

14. Next, choose the Virtual Servers sub-menu and click Add:

[ 193 ]

Chapter 5

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

15. In the New Virtual Server dialog box, ensure the parameters are set as per the following screenshot. Click OK to complete the Load Balancer configuration:

Verifying the NSX edge load balancer configuration The following steps detail how to verify the operation of the configured Load Balancing profile from the previous section: 1. SSH onto the One-Armed Load Balancer ESG with the IP address 172.16.33.2. 2. Log in with the admin credentials used during creation.

[ 194 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

3. Run the command show service loadbalancer virtual to verify the Load Balancer is up and is correctly using the L4 load balancing engine, as highlighted in the following screenshot:

How it works... For one-armed topologies, when a packet (request) is received by the ESG, two actions are taken, which are as follows: 1. Perform a DNAT translation to replace the VIP of the Load Balancer with a server in the pool 2. Perform an SNAT translation to replace the client IP address with that of the Load Balancers Because NAT is required the firewall must also be enabled on the Edge Load Balancer.

[ 195 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

In this recipe, we also configured a layer 4 Load Balancer and not layer 7; layer 4 is preferred if you require higher performance. To configure an L4 Load Balancer as seen in this recipe, it is imperative no layer 7 parameters are chosen, otherwise the load balancing engine will default to layer 7. You can verify which load balancing engine is being used on the ESG with the command show service loadbalancer. It is also important to note that when a packet is received by the ESG, once it has manipulated the packet (DNAT/SNAT), it will forward the request to the destination pool member without buffering the entire request as is done.

There's more... To understand the different configuration menus, the following points will detail each one and why it is required: Service Monitor: Defines the probes that will be used to check whether a Pool Member is healthy or not. Server Pool: Pool of servers that will be used in the load balancing configuration. Server Pool Member: The individual member that belongs to a server pool. Virtual Server: An abstract of the application service that is being load balanced. It is where you configure which pool and application will be load balanced. Application Profile: Configuration parameters for certificate, protocol/port, and persistence of the connections.

Configuring IPSEC VPN IPSEC VPN is a technology that provides a mechanism to establish encrypted network tunnels over non-secure infrastructure such as the internet. Security and data confidentiality are the primary requirements for IPSEC VPN, and the IPSEC VPN implementation on the ESG meets this requirement. The edge supports IKEv1 and the following parameters for IPSEC VPN: Authentication

• Certificate • Pre-Shared Key

Encryption algorithms AES

• AES256 • Triple DES • AES-GCM

[ 196 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

• DH5 • DH14 Diffie Hellman groups DH2 • DH15 • DH16

In addition, each edge form factor supports a specific number of IPSEC VPN tunnels, which are follows: Edge form factor Number of IPSEC tunnels Compact

512

Large

1,600

Quad Large

4,096

X-Large

6,000

The ESG also supports IPSEC tunnel NAT traversal, so even if your edge is located behind a perimeter firewall which is performing NAT, as long as the appropriate DNAT rules have been configured on the perimeter firewall, you can establish an IPSEC tunnel with a remote endpoint. In this recipe, we will configure an ESG to establish a VPN tunnel to a business partner over the internet. We will set up the edge and expect the remote site will be preconfigured to establish the IPSEC VPN tunnel. The following figure provides an overview of the edge that will establish a VPN connection to the remote peer. For the purposes of this example, the connection will be using RFC1918 addresses for the public interfaces on either side, but the methodology can be applied to devices using public addresses as well. We will also use pre-shared authentication between the two peers for this example:

[ 197 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

Getting ready To configure the ESG for IPSEC VPN, the following prerequisites must be met: User with NSX Enterprise Administrator or NSX Administrator role Remote VPN peer must be preconfigured to establish a connection with the ESG Newly-deployed Edge to configure the VPN on; we will use a pre-created edge named Chapter5 for this recipe vSphere cluster where the edge will be deployed to; it must be prepared for NSX Target ESXi hosts must have sufficient capacity to run the ESG virtual machine

How to do it... The following steps detail how to configure IPSEC VPN on the ESG: 1. 2. 3. 4. 5.

Log in to the vSphere web client via a web browser. Navigate to Networking & Security. Select NSX Edges and select the newly-created edge: Chapter5. Navigate to Settings | Interfaces. Ensure that the public interface is of type Uplink:

6. Navigate to VPN | IPSEC VPN and click Add. 7. Configure the IPSEC tunnel with the configuration as per the following screenshot and click OK to complete:

[ 198 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

[ 199 ]

Chapter 5

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

8. Click Publish Changes. 9. Click Enable on the IPSEC VPN Service Status submenu:

10. Under the tunnel configuration, select Show IPSEC statistics to confirm the tunnel is up and healthy as per the following screenshot:

[ 200 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

How it works... For the IPSEC VPN tunnel to be established, you and the peer must agree on a few parameters; these are the following: Endpoint IP addresses of one another Encryption algorithm to use Peer subnets and local subnets that will be secured over the VPN Authentication type and parameter—in this case, a Pre-Shared Key Diffie-Hellman group Once these parameters are agreed upon by both ends, each endpoint will go through phase 1 and 2 of establishing the VPN tunnel. If one of these parameters does not match on either side of the tunnel, then the tunnel will fail to be established. It is commonly overlooked, but IPSEC VPN tunnels can only be created on the IP address associated to an Uplink interface and do not support internal interface types.

Configuring SSL VPN SSL VPN is a solution to allow remote users to connect to networks located behind an ESG, which could be networks created in NSX or traditional networks on your physical infrastructure. This solution is analogous to other remote VPN connections in the industry, and is another powerful function of the ESG. SSL VPN is configured on the ESG as another service and supports multiple authentication options, such as the following: Active Directory LDAP Local Radius RSA In addition to supporting multiple authentication sources, the VPN client also supports the following operating systems: Windows XP and above macOS Tiger, Leopard, Snow Leopard, Mountain Lion, Maverick, and Yosemite Linux—the TCL-TK package is required for the user interface

[ 201 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

Support for operating systems may change between major and minor updates to NSX; therefore, it is recommended to check the release notes for the latest information. In this recipe, we will configure an ESG for SSL VPN to allow access to the web servers located on the web logical switch. The configuration will be for a split-tunnel VPN connection, and users will be authenticated locally on the ESG. The following figure provides an overview of the logical topology for the VPN server on the edge:

[ 202 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

Getting ready To configure the ESG for SSL VPN, the following prerequisites must be met: User with NSX Enterprise Administrator or NSX Administrator role Newly-deployed Edge to configure the SSL VPN on; we will use a pre-created edge named Chapter5 for this recipe vSphere cluster where the edge will be deployed to; it must be prepared for NSX Target ESXi hosts must have sufficient capacity to run the ESG virtual machine The edge must have connectivity to the internet, and teleworkers must have access from the internet to the edge

How to do it... The following steps detail how to configure SSL VPN on the ESG: 1. 2. 3. 4.

Log in to the vSphere Web Client via a web browser. Navigate to Networking & Security. Select NSX Edges and select the newly-created edge: Chapter5. Under the Chapter5 configuration, navigate to SSL VPN-Plus | Server Settings:

[ 203 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

5. Click Change on Server Settings and select the Uplink IP address of the ESG. Leave all other parameters at their default values and click OK:

[ 204 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

6. Next, navigate to IP Pools and click Add. 7. Configure the IP pool for VPN clients as per the following screenshot and the recipe topology diagram. Click OK to complete the configuration:

[ 205 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

8. Next, navigate to Private Networks and click Add. 9. Configure the network 172.16.33.0/24 for tunneling, select Send Traffic Over Tunnel, and Enable TCP Optimization. Ensure Status is Enabled, and click OK to complete the configuration:

10. Navigate to Authentication and click Add. 11. Select Authentication Server Type as Local, ensure Status is Enabled and leave all other parameters as their default values and click OK to complete the configuration:

[ 206 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

[ 207 ]

Chapter 5

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

12. Navigate to Installation Package and click Add. 13. Change Profile Name to a friendly name; in this example, we will use PROFILE_1. Add the Gateway of the edge as 10.0.0.170 and Port as 443. Finally, check the operating systems supported for this package, such as Windows or Mac, ensure Status is Enabled, then click OK to continue:

[ 208 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

14. Next, navigate to Users and click Add. 15. Create a new user and ensure Status is Enabled. Click OK to continue:

[ 209 ]

Chapter 5

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

16. Navigate to the Dashboard:

17. Select Enable under the Status submenu.

How it works... When configuring SSL VPN-Plus, there are essentially five things that you need to configure: 1. SSL VPN-Plus server settings and encryption ciphers 2. IP pool for remote users

[ 210 ]

Chapter 5

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

3. Private networks that should be tunneled over the VPN connection 4. Authentication source and user account 5. Package for operating system support These items are the essential configuration parameters required to enable SSL VPN-Plus, and should be configured in the order defined above. Once a user is authenticated, they establish a SSL VPN tunnel from their device to the ESG, they receive an IP address from the configured IP pool, and any private networks defined are then tunneled to the edge to their target destination. The configuration depicted in this recipe was for a split-tunnel VPN design, but a full-tunnel design can also be implemented if required. SSL VPN-Plus tunneling mode: Tunneling mode can be changed under the Client Configuration submenu and is a global configuration parameter.

There's more... In addition to the configuration above, you can also configure the following for your SSL VPN-Plus service: Portal customization VPN client icon customization Logon/logoff scripts Installation package specifics Defining each of these gives you complete flexibility over the installation of SSL VPN-Plus for your organization.

Configuring High Availability High Availability is required to ensure that application services supported by the edge such as firewall, NAT, and load balancing are available in the event of a hardware of a ESXi host where the Edge VM is running or software failure to a single ESG appliance. Edge HA minimizes the service disruption but does not provide a zero-downtime solution.

[ 211 ]

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

HA provided by the ESG is stateful and comes in the form of active and standby edge virtual machine appliances. As there are two virtual machines that effectively take the role of active/standby, it is good practice to ensure each appliance is located on separate resource pools and datastores to ensure that a hardware failure doesn't render both the active and standby appliances unserviceable. The mechanism that one active ESG appliance uses to communicate with another is via a heartbeat, which by default is sending a hello every 15 seconds to signal that it is alive and healthy. In the event the standby appliance does not receive the hello within the specified period, it will declare the active as dead and assume its configuration by starting services and taking ownership of the interface configuration. In this recipe, we will explore how to configure HA on an ESG that has already been deployed into our environment and the steps for verification.

Getting ready To enable the ESG for HA, the following prerequisites must be met: User with NSX Enterprise Administrator or NSX Administrator role Newly-deployed Edge to enable HA on; we will use a pre-created edge named Chapter5 for this recipe vSphere cluster where the edge will be deployed to; it must be prepared for NSX Target ESXi hosts must have sufficient capacity to run the ESG virtual machine

How to do it... The following steps detail how to configure HA on the ESG: 1. Log in to vSphere web client via a web browser. 2. Navigate to Networking & Security | Logical Switches.

[ 212 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

3. Click the Add button and configure a new logical switch with the configuration as per the following screenshot:

4. Navigate to NSX Edges and select the Chapter5 ESG. 5. Click Settings and then Interfaces.

[ 213 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

6. Add a new interface with the configuration as per the following screenshot, leaving the IP configuration blank:

[ 214 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

7. Navigate to Settings | Configuration and click Change under the HA Configuration submenu:

[ 215 ]

Chapter 5

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

8. Ensure HA Status is enabled and use the newly-created logical switch, EDGE_HA_CHAPTER_5, for the vNIC and leave all other parameters as default. Click OK to complete:

9. Check to see whether the secondary ESG is deployed under the NSX Edge Appliances submenu. It will display Undeployed until the virtual machine is up, at which time the Status will change to Deployed:

[ 216 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

10. Console or SSH onto the edge and execute the command show service highavailability for status information:

[ 217 ]

Chapter 5

||||||||||||||||||||

Configuring VMware NSX Edge Services Gateway

Chapter 5

How it works... The reason a dedicated logical switch is created in this recipe is to ensure heartbeat traffic is separated from normal data traffic. It is considered best practice to keep heartbeat traffic separated from other network traffic, and the simplest way to achieve this is via a new logical switch, as opposed to a VLAN backed Portgroup. Also, local link IP addresses are used so that the two appliances can communicate with one another; however, this can be overridden if required. Once the logical switch is created and HA enabled on the edge, NSX Manager will deploy a second edge onto the same datastore and resource pool in the same form factor of the primary appliance. If another resource pool or datastore is desired, this can be changed after the deployment. For a standby edge to become active, it would require that the heartbeat is not received within the HA timer; by default, this is set at 15 seconds. If, after 15 seconds, the heartbeat has been missed, the standby edge will declare the primary as dead and move to assume the roles and responsibilities as the primary. Deployment failure of standby edge In the event of a deployment failure, check that the target vSphere cluster has enough resources to accommodate the additional edge. From NSX 6.2.3 onward, resource reservations are set for each ESG appliance.

[ 218 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

6 Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard In this chapter, you will learn how to configure the VMware NSX Distributed Firewall (DFW) and SpoofGuard. We will be looking at the following recipes: Verifying NSX DFW component status Configuring IP discovery for Virtual Machines Working with SpoofGuard Excluding Virtual Machines from DFW protection Configuring DFW session timeout Creating Security Policy Rules from the Firewall Table Menu Creating Security Policy Rules from the Service Composer menu Verifying DFW rules Leveraging the DFW Applied To field Deploying Network or Guest Introspection services Configuring the Identity Firewall

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

Introduction VMware NSX has two types of firewall, namely the NSX Edge Firewall and the NSX Distributed Firewall(DFW). The Edge Firewall is optimized for north-south (client to server) traffic whereas the DFW is optimized for east-west (server-to-server) traffic:

In this chapter, we will be focusing on the NSX DFW. NSX DFW enables the creation of small segments (microsegments) in virtualized environments through VMware NSX DFW native technology as well as integration (service-chaining) with third-party vendors. The NSX DFW is implemented in the vSphere hypervisor, and rules are enforced on each virtual machine's network adapter or virtual Network Interface Card (vNIC) regardless of how the virtual machine is connected (VLAN or VXLAN) or where it resides. DFW functionality is independent of the network type whether it is on a VXLAN-backed PortGroup (logical switch) or a VLAN-backed PortGroup. Virtual machines must be connected to the vDS to use NSX services and features. The NSX DFW functionality is independent of the controller cluster; therefore, in a DFW-only deployment, an NSX controller is not required for policy creation or enforcement. The DFW feature is activated as soon as the host preparation is completed and all traffic is allowed through by default. The DFW creates one Ethernet (L2) default with any any allow rules in the Ethernet section and three general (L3/L4) any any allow rules in the General section.

[ 220 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

While this ensures any existing application's communication does not break in a brownfield deployment, in most cases, this is not the desired end goal, and once the relevant security policies have been created, the default rule is typically changed to deny any any. In greenfield deployments where there are no virtual machines in the environment, the default policy can be changed to block, and virtual machines that are on-boarded to DFW should have the corresponding allow rule created specifically for them. To avoid getting locked out of vCenter server access, make sure the vCenter server virtual machine is excluded from DFW. This is covered later in this chapter in the Excluding Virtual Machines from the DFW recipe. NSX DFW is a layer 2 to layer 4 firewall, which means the firewall rule is based on the common 5-tuple constructs listed here: Source (MAC/IP address) Source port Destination (MAC/IP address) Protocol Destination port The layer 7 context-awareness feature is available from NSX release 6.4.

NSX allows for the creation of firewall rules based on vCenter or NSX objects without the need to specify the actual IP address of the source or destination such as a vSphere data centre, vSphere cluster, virtual machine, vNIC, PortGroup, security group, and so on. The traditional way of creating firewall rules based on IP addresses can still be achieved by creating an object called IP sets in NSX; IP sets are also used if the source or destination object is not managed by the vCenter server that NSX Manager is paired with. The Distributed Firewall only protects flows to and from a virtual machine's vNIC; therefore, physical-to-virtual, virtual-to-physical, and virtual-to-virtual flows can be inspected and a security policy enforced. ESXi VMkernel is not considered virtual; use ESXi firewall to limit access to ESXi management.

[ 221 ]

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

When using vCenter objects in DFW rules, NSX still needs to retrieve the actual IP address (MAC address for the layer 2 firewall) of the virtual machine associated with the vCenter objects through an IP discovery mechanism. By default, NSX uses VMware Tools for IP discovery, and VMware Tools was mandatory for NSX DFW to work prior to NSX 6.2. The IP address of a virtual machine's vNIC is learned via VMware Tools is stored in the vCenter server database and reported to NSX Manager. When VMware Tools is not installed or not running (disabled) on the guest virtual machine, DFW loses track of the virtual machine's IP address and therefore the default rule will be enforced for that particular virtual machine. Prior to NSX 6.3.2, Open VM Tools (OVT) was not validated against NSX DFW. In this case, there may have been potential issues where the DFW was not be able to retrieve the virtual machine's IP address and would enforce the default deny rule for flows to and from that particular virtual machine. ESXi uses IOChains to process packets at the kernel level, and there are 16 slots of IOChains, slot 0 to slot 16. Slots 0 to 3 and 13 to 15 are reserved by VMware, while slots 4 to 12 (filtering module) are for partner services integration through the NetX API, which allows NSX to apply the inserted services to specific traffic flows depending on the source, destination, or port dynamically. The NSX DFW operates in slot 2 and the partner services integration uses the filtering module to redirect traffic to the third-party partner virtual machine (also referred to as the service VM) as shown in the diagram:

[ 222 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

In partner services integration (also referred to as service insertion or service chaining), the role of the NSX DFW will be to direct traffic, and it is up to the third-party partner vendor to accept or drop the redirected traffic. The partner services integration is available on two insertion points, on the guest level and, the network level. Network introspection, also often referred to as network traffic redirection, network traffic steering, or service chaining, allows NSX to redirect specific network traffic flows to thirdparty partner services for advanced security services such as a layer 7 next-gen firewall, intrusion detection, intrusion prevention, or anti-virus/anti-malware scanning to the NSX DFW.

[ 223 ]

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

Guest Introspection services, which is also known as vShield endpoint security, allows the third-party partner service to gain a view of what is happening inside the guest VM, and if a particular behavior is observed, to take appropriate action or redirect to service VM. Use cases include Agent-less Anti-Virus, Anti-Malware, Data Loss Prevention (DLP), or vulnerability management use cases. As of NSX 6.2.3, any NSX installation comes with NSX for a vShield endpoint license which enables the use of NSX for Anti-Virus offload capability only. The NSX for vShield endpoint license restricts the usage of VXLAN, DFW, and Edge Services by blocking host preparation and the creation of NSX edges on the vSphere cluster. The Guest Introspection Virtual Machine is also required for other NSX features such as NSX Identity Firewall (IdFW) and endpoint monitoring. The NSX activity monitoring feature was deprecated as of as of NSX 6.3.0, and NSX data security was deprecated as of NSX 6.2.3. NSX 6.3.0 introduced NSX Endpoint Monitoring, which supersedes NSX activity monitoring. For a complete list of NSX third-party security partners, see this link: https:/​/​www.​vmware. com/​resources/​compatibility/​search.​php?​deviceCategory=​security.

DFW Topology and Policy In this section, we will implement a distributed firewall policy for a three-tier application (Application A) as depicted in the following figure:

[ 224 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

There are three approaches to create security policy rules in NSX DFW; they are: Network-based policies Infrastructure-based policies Application-based policies The network-based policies are similar to traditional firewall constructs where you would use layer 2 (MAC address) or layer 3 (IP address) constructs to create security policy rules. The infrastructure-based policies approach uses vCenter infrastructure objects such as vSphere cluster, VM, dvPortGroup, or other vCenter objects to create the security policy. Lastly, the application-based policies approach uses a group-based on application type, such as group-based on a specific VM name pattern, a certain computer name, or maybe based on a VM with a specific security tag. There are two ways to configure DFW, which are: Firewall Rule Table menu Service Composer menu

[ 225 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

The network-based and infrastructure-based policies are normally for static environments; these two types of security policies can be created using the firewall rule table. The application-based policies, on the other hand, are more suitable for dynamic environments and application-centric policies, which require the Service Composer menu to create the security policy. Each method is suited for different use cases; in many cases, a combination of both may be used to create the security policy required for your environment.

See also For additional documents on DFW and Micro-Segmentation with NSX, see these references: VMware NSX DFW policy rules configuration technical white paper (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whi tepaper/nsx/whitepaper-dfw-policy-rules-configuration-guide.pdf) NSX Distributed Firewalling Policy Rules Configuration Guide Version 2 (https://communities.vmware.com/docs/DOC-36138) VMware NSX Micro-Segmentation: Day 1 guide (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/pro ducts/nsx/vmware-nsx-microsegmentation.pdf) VMware NSX Micro-Segmentation: Day 2 guide (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/pro ducts/nsx/vmware-micro-segmentation-day-2.pdf)

Verifying NSX DFW component status Before working with the distributed firewall, it is important to make sure the DFW module is installed and running properly. In this recipe, we will verify NSX DFW status through the command-line interface from an ESXi host.

Getting ready Make sure you have SSH access to ESXi hosts that are prepared for NSX, and at least auditor access to NSX.

[ 226 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

How to do it... As explained in Chapter 1, Getting Started with Vmware NSX for vSphere, the installation of NSX VIBs is essential for the DFW to operate. If the DFW VIBs are present, we will then verify if the process managing the DFW is running on the ESXi host.

Verifying Firewall Installation Status The first obvious thing to check is that the vSphere cluster is prepared for NSX and that the firewall is enabled: 1. From the vSphere web client, navigate to Home | Networking & Security | Installation | Host Preparation. 2. In the center pane, expand the selected vSphere cluster and verify that Firewall is Enabled:

Verifying vShield Stateful Firewall (vsfwd) Status and Connection To make sure that DFW is running and communicating properly, verify the vsfwd process via the ESXi host console: 1. To verify that the DFW is running on the ESXi hosts, SSH onto an ESXi host.

[ 227 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

2. Verify the vsfwd process is in a running state using the following command: /etc/init.d/vShield-Stateful-Firewall status

There are four usages of the vShield-Stateful-Firewall command: { start | stop | status | restart }

3. Verify that vsfwd is running using the following command: ps | grep vsfwd

4. Verify that vsfwd has RabbitMQ messaging bus connectivity configured to the NSX Manager IP address, using the following command. In our example, the NSX Manager IP address is 192.168.110.15: esxcfg-advcfg -g /UserVars/RmqIpAddress

[ 228 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

5. Verify that vsfwd has active messaging bus connectivity established to the NSX manager over RabbitMQ TCP port 5671 using the following command: esxcli network ip connection list | grep 5671

How it works... The DFW feature comes as a kernel module called VMware Internetworking Service Insertion Platform (VSIP) in the form of a vSphere installation bundle (VIB). The VSIP kernel module is controlled by VSIP I/O Control (VSIPIOCTL). The VSIP module retrieves firewall rules from NSX Manager through the vShield Firewall Daemon (vsfwd) which is automatically started in the ESXi host's user space upon host preparation. The DFW VIB is installed as part of NSX host preparation. Check out Chapter 1, Getting Started with VMware NSX for vSphere, to understand how ESXi host preparation works for NSX. It is also important to note that VSFWD is part of the message bus user world agent (UWA), a component that allows the NSX Manager message bus service to retrieve control plane information. If VSFWD is not running, it is not just DFW that will be impacted; changes to logical switching and logical routing will also be impacted and fail. As explained in Chapter 1, Getting Started with Vmware NSX for vSphere, starting from NSX 6.2.x you can check the DFW agent status from the vSphere web client UI Communication Channel Health. If the firewall publish status is failed in the NSX Dashboard or the Firewall Table Menu, typically it is because the vsfwd service is not running or cannot reach NSX Manager for whatever reason.

[ 229 ]

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

See also VMware KB 2125901 DFW rules fail to process traffic even after successfully publishing the rules in VMware NSX for vSphere 6.x (https://kb.vmware.com/kb/2125901) VMware KB 2125437 Troubleshooting NSX for vSphere 6.x distributed firewall (DFW) (https://kb.vmware.com/kb/2125437)

Configuring IP Discovery for Virtual Machines As explained in the introduction, NSX DFW uses VMware Tools to retrieve a virtual machine IP address and enforces firewall rules on the virtual machine. However, in some cases virtual machines may not have VMware Tools installed and running. To avoid the DFW dependency on VMware Tools, NSX 6.2.0 introduced two new mechanisms to discover a virtual machine's IP address that can be configured on a vSphere cluster-level basis: DHCP snooping: Tracks IPv4 and IPv6 DHCP protocol messages ARP snooping: Tracks ARP messages from the guest virtual machines The NSX Manager can use either of these mechanisms to discover the IP address and apply firewall rules to a virtual machine. In this recipe, we will enable ARP snooping for virtual machine IP discovery.

Getting ready Make sure you have Security Administrator or Enterprise Administrator access to NSX.

How to do it... Follow these steps to change IP detection type settings on a vSphere cluster: 1. From the vSphere Web Client, navigate to Home | Networking & Security | Installation | Host Preparation. 2. In the center pane, select a cluster, click the Actions button, and select Change IP Detection Type.

[ 230 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

3. A new dialog box will be opened and in this example we will add ARP Snooping as an additional IP Detection Type:

How it works... In contrast to the VMware Tools report, DHCP and/or ARP snooping is performed under the kernel space as opposed to the user space. In ARP snooping, NSX keeps two ARP IP addresses: Trust on First Use (TOFU) ARP IP and LAST SEEN IP. ARP snooping tracks the ARP request so if there is no traffic or no ARP request, the IP address will not be learnt. There will be only one IPv4 and IPv6 entry per vNIC that is maintained, and ARP entries are not timed out. DHCP snooping tracks DHCP protocol messages, particularly DHCP client requests. If the guest virtual machine receives an IP address from the DHCP server prior to enabling DHCP snooping, NSX Manager will still not be aware of the IP address as no DHCP client request would have been detected. A DHCP client request would need to be re-run, for example, by disconnecting and reconnecting the vNIC, renewing the IP configuration, or rebooting the virtual machine. In DHCP snooping, the DHCP lease expiry is tracked and entries are cleaned up on expiry. Both DHCPv6 and ND snooping are supported for IPv6.

[ 231 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

Verifying the Learnt IP address There are multiple ways to verify the IP address that is learnt by NSX: Via NSX Manager by logging in to the NSX Manager console. Use the show vm to get the virtual NIC filter name and use show dfw host filter < filter name> addrsets to show the discovered VM IP as well as

the IP detection. Via ESXi host console. Do a summarize-dvfilter to get the filter name and use vsipioctl getdiscovered -f . Via SpoofGuard. Log in to the vSphere web client and navigate to Networking & Security | SpoofGuard. Select the Default Policy and in the bottom pane, the Detected IP column should show the learned IP Address and Source of IP learning such as VMTOOLS or ARP.

Working with SpoofGuard SpoofGuard is a feature that can be used to prevent virtual machine IP address spoofing. SpoofGuard comes with a default policy, and it is disabled by default. In this recipe, we will learn how to enable SpoofGuard on a logical switch.

Getting ready Make sure you have Security Administrator or Enterprise Administrator access to NSX. The SpoofGuard default policy will include all networks, but a newly-created SpoofGuard policy can be created for specific networks (PortGroup or logical switch). A newly-added network is automatically added to the default policy. A SpoofGuard policy has the following operating modes: Automatically trust IP assignments on their first use: This mode allows all traffic from the virtual machine to pass while building a table of vNIC-to-IP address assignments. The administrator can review this table at their convenience and make IP address changes. This mode automatically approves all IPv4 and IPv6 addresses on a vNIC. Manually inspect and approve all IP assignments before use: This mode blocks all traffic until the administrator approves each vNIC-to-IP address assignment. Traffic to and from unapproved IP addresses is blocked.

[ 232 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

How to do it... Follow these steps to enable SpoofGuard: 1. From the vSphere web client, navigate to Home | Networking & Security | SpoofGuard. The default IP Detection Type is none and there should be a Default Policy that is Disabled in the center pane. To change the IP Detection Type, click the Change button and select DHCP Snooping or ARP Snooping 2. Edit the existing Default Policy, or create a new policy by clicking the green plus icon. A new dialog box will open. 3. For a new policy, input the Policy Name, select Enabled for SpoofGuard, select the desired Operation Mode, and click Next:

5. For a non-default policy, choose the network objects that will be included, click OK, and click Finish.

[ 233 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

6. In manual inspect operation mode, the Approved IP will be blank as it requires manual approval. Select the desired policy, change to Virtual NICs IP Required Approval inactive virtual NICs for the View in the bottom center pane. Click Approve under the Detected IP - Action column beside the IP Address:

7. Once approved, the IP address will be listed under Approved IP. Review and then click Publish Changes.

How it works... NSX DFW integrates with SpoofGuard which protects against IP spoofing in a virtual environment. If a virtual machine has been compromised, the IP address can be spoofed and malicious traffic can bypass the firewall using the spoofed IP address. SpoofGuard will protect against this as every time the virtual machine's IP addresses changes, the SpoofGuard database must be updated or approved with the new detected IP. If an IP address of a VM has changed, an NSX administrator must acknowledge the new IP so that the virtual machine can send and receive traffic with the new IP.

[ 234 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

The IP detection mechanism can be used via VMware Tools, DHCP snooping, and/or ARP snooping. Only vNIC to IP association of the virtual machine is tracked by SpoofGuard; the MAC address of the virtual machine is not tracked. When enabled, traffic to and from unapproved IP addresses is blocked until an IP address is manually approved. SpoofGuard accepts a unique IP address from virtual machines across NSX and can only assign an approved IP address once. Additional consideration is required when using SpoofGuard in multitenant environments where overlapping addresses exist. Duplicate approved IP addresses are not allowed in SpoofGuard.

There's more... Regardless of the mode (automatic trust IP or manual inspect), SpoofGuard allows DHCP requests. However, in manual inspection mode, traffic does not pass until the DHCPassigned IP address has been approved. A DHCP-configured virtual machine will be assigned the private link-local address (169.254.0.0/16 for IPv4 and fe80::/64 for IPv6) when it fails to get an IP address. This link-local address is considered valid if the option of Allow local address as valid address in this namespace is set, otherwise the link-local address will be ignored.

Excluding Virtual Machines from DFW Protection As explained in the introduction, the DFW feature is activated as soon as the host preparation is completed and all virtual machines that are part of the cluster are enforced by the DFW. This is also important when you are planning to change the any any allow default rule to any any deny, as this may inadvertently block access to the vCenter server. In this recipe, we will learn how to exclude virtual machines from distributed firewall protection, so that no policy enforcement will be applied to any of the vNICs on those virtual machines.

[ 235 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

Getting ready Make sure you have Security Administrator or Enterprise Administrator access to NSX.

How to do it... Follow these steps to exclude a VM from the DFW: 1. From the vSphere web client, navigate to Home | Networking & Security | Networking & Security Inventory | NSX Managers. 2. Select the NSX manager's IP address and in the center pane, choose the Manage | Exclusion List tab. Then click the plus sign and a new dialog box will open as shown below. Choose the virtual machine that you would like to exclude and click OK.

3. Verify that the virtual machine is listed in the center pane.

[ 236 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

How it works... The DFW exclusion list provides the ability to exclude virtual machines from DFW enforcement. NSX components such as NSX Manager, NSX controller nodes, NSX DLR control VMs, and NSX edge VMs are automatically excluded from the DFW. If the management cluster is prepared for NSX, such as in shared management/edge clusters, it is recommended to exclude the following virtual machines from the DFW: vCenter Server. Platform Services Controller. vCenter server's database server (if available). Virtual machines in promiscuous mode. Performance of virtual machines requiring promiscuous mode may be adversely affected behind NSX DFW. An NSX partner service virtual machine (SVM), such as a third-party layer 7 firewall or agentless anti-virus/malware virtual machine. A hyper-converged service virtual machine (SVM) such as Nutanix Controller VM (CVM). If the vCenter server is blocked by DFW due to rule misconfiguration, the workaround is to restore the DFW rule to the default policy, which will set the default rule to allow and restore access to the vCenter server. The procedure to restore the DFW rule from the REST API is covered in VMware KB 2079620: vCenter server access is blocked after creating a deny all rule in DFW (https://kb.vmware.com/kb/2079620).

There's more... It is not possible to exclude a particular virtual machine network adapter (vNIC) from the DFW. The exclusion list will disable the DFW on the virtual machine. If a virtual machine has multiple vNICs and is added to the exclusion list, all the vNICs will be excluded from DFW. The current behavior of the DFW exclusion list will not exclude a new adapter that is added after the VM is added to the exclusion list. To exclude the newly-added network adapter, the virtual machine must be removed from the exclusion list and added back. The other alternative is to power off the virtual machine and power it on.

[ 237 ]

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

Configuring DFW Session Timeout Most firewalls have default session timeouts (often called idle timeouts). This timeout is normally tweaked when an application is having a problem with connections being reset due to premature timeouts. NSX 6.3.1 and later allows for configuring session timers for TCP, UDP, and ICMP sessions to be applied to VMs or vNICs.

Getting ready Make sure you have Security Administrator or Enterprise Administrator access to NSX and log in to the vSphere web client.

How to do it... Follow the steps below to configure DFW session timers: 1. From the vSphere web client, navigate to Home | Networking & Security | Firewall. In the center pane, select Settings. DFW comes with system-generated Default Session Timers which apply to all objects. 2. To edit the default timers, select the Default Session Timers and click the edit pencil icon; this will change the global default session timers. To create a new timer setting that can be applied to a specific object, click the plus sign, and a new dialog box will open. The default timeout values are populated in the field. For example, the default TCP timeout for a connection once it become fully established is 86,400 seconds (12 hours). For custom timeout settings, the settings can be configured for specific virtual machines or specific vNICs of a virtual machine. Choose the desired value and click OK:

[ 238 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

3. The custom timers will be created on top of the Default Session Timers and will have the number of applied objects under the Applied To column.

How it works... The session timers setting defines how long a session is going to be kept open by the DFW after the connection is idle. After the session timeout for the protocol expires, the session will be closed or removed. Setting a value too low could cause frequent timeouts, while setting it too high could delay failure detection.

[ 239 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

Creating Security Policy Rules from the Firewall Table Menu In this recipe, we will configure DFW rules using the NSX firewall table menu. The firewall table menu is a similar method to creating firewall rules as you would use in a traditional firewall, therefore is most commonly where users configure most of their firewall policy.

Getting ready To configure the distributed firewall, the following prerequisites must be met: Log in as a user with the security administrator or enterprise administrator role Virtual machines that will be applied with the DFW rule must have the ESXi hosts prepared for NSX DFW and VSFWD are enabled and running on ESXi hosts. This is covered in the Verifying NSX DFW components status recipe

How to do it... In this recipe, we will cover how to create a firewall section and how to create a DFW rule.

Creating Firewall Sections To organize DFW rules, you can create firewall sections, and in this example, we will create a firewall section for Application A: 1. From the vSphere web client, navigate to Home | Networking & Security | Firewall. In the center pane, select the Configuration | General tab:

[ 240 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

2. To add a section, click the folder with the plus Add section, or right-click on Default Section Layer 3 (Rule 1-3) and click Add section. 3. This will open up the New Section dialog box; input the Name of the section and click Save. Since there is only one existing section (default section), you can only choose Add above for the Position. In this example, we will create the Application A section:

4. Click Publish Changes to commit the changes. The Save Changes button is to save the created rule but not to publish it until a later time. This can be used, for example, if you want to implement the rule outside of business hours during a designated maintenance window. The Save Changes feature can have adverse consequences, with multiple administrators saving changes for later publication, which can potentially override changes made by another administrator. Therefore, it is recommended that you use it in collaboration with all security administrators so that the original policy is not overwritten. The Recent Changes button is to return to the previous configuration before the new rules were created.

[ 241 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

Create multiple sections to allow multiple people to edit DFW rules at the same time. A section can be submitted without affecting the work of other people in different sections.

Creating Firewall Rules Section creation is optional, and more for rule organization. Next, we will configure the required rules under the newly-created section Application A. 1. Make sure you are in the General tab. In the center pane, click the green plus Add rule icon or right-click the newly-created Application A section and click Add rule. 2. A new row inside the Application A section will be created with no Name, no Rule ID, from Source any, to Destination any, for Service any, Action Allow, and Applied To Distributed Firewall:

3. To edit the firewall rule, navigate to each of the column boxes (Name, Source, Destination, Service, Action, and Applied To) until the edit pencil icon is showing, and click the icon. 4. For the Rule Name, we will use Allow Any to Web Tier and click Save. 5. Leave the Source as any, and for Destination, use Virtual Machine as the Object Type. Select web-01a and web02a using the arrow in the center, or by doubleclicking the objects and click OK:

[ 242 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

6. For the service, use Service as the Object Type; select HTTP:

[ 243 ]

Chapter 6

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

7. For the edit action, set the Action to Allow, with In/Out as the Direction and Any as the Packet Type. To log the session matching the DFW rule, set Log to Log:

DFW logging will be shown in dfwpktlogs.log as part of the ESXi host log. See Chapter 11, Managing and Monitoring VMware NSX Platform, for information on how to locate and access the DFW logs: 1. The following is the completed firewall rule. After completing the rule editing, click Publish Changes. 2. To add more rules into the section, select an existing rule and click the green plus Add rule icon above the No. column. This will add the rule below the selected rule. Another option to add more rules is to select an existing rule and click the green plus Add rule icon below the Applied To column, which will add the rule above the selected rule. Adding a rule can also be done by clicking the pencil icon and choosing Add Above or Add Below. Create the remaining DFW rules; the following are the completed rules for our scenario:

[ 244 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

3. For Services that are not listed,such as Tomcat, for the second rule Allow Web Tier to App Tier. In this example, we will create the Tomcat service by clicking New Service...A new Add Service dialog will open. For our example, use Tomcat as the Name, TCP for the Protocol, and 8443 for the Destination ports. Optionally, put a Description in and click OK.

4. The newly-created port will be automatically selected; click OK. 5. We will leave the Applied To set to Distributed Firewall for now. We will cover this in a separate recipe. Click Publish Changes once completed.

How it works... When an administrator configures and publishes DFW rules, the rules are transmitted to the NSX Manager via the NSX plugin for vCenter, and NSX manager pushes the rules down to ESXi hosts (user world agent) using the message bus (AMQP). In this example, we created three DFW rules for the three-tier app, used the virtual machine as the destination object type, and applied to the distributed firewall, which means applying to all clusters that are enabled for the DFW. We will cover how to use and configure the applied to field in a separate recipe.

[ 245 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

DFW rules are enforced in top-to-bottom ordering. The first rule in the table that matches the rule criteria is enforced; if a match is not seen, the next rule is evaluated, and so on. DFW rules can be moved within and across sections. Sections can be merged to consolidate rules within those sections. Sections do not impact the overall DFW rules or security policies, as these are purely for organizing rules and readability. Use sections to allow multiple admins to make changes simultaneously. A section can be submitted without affecting the work of other people on different sections.

DFW Rule ID and Logs Whenever a new DFW rule is created, a unique system-generated ID called rule ID will be created. The rule ID column is not visible by default; to display the rule ID as an additional column, scroll to the end of the firewall configuration menu (minimize the Navigator menu if required). Click the table icon on top of the last column header and tick the Rule ID checkbox:

[ 246 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

The rule ID is unique and therefore can be referenced in DFW logs for analysis, and is not reused if a rule is deleted. Rule ID is very useful to figure out which rule is allowed or blocked in DFW logs. All DFW rules that are set to the log will be logged and stored in /var/log/dfwpktlogs.log on each ESXi host; this means the logs are distributed to each ESXi host and it will be hard to identify if there is no centralized syslog server configured. It is recommended to configure a centralized syslog server, such as vRealize Log Insight, for easier analysis and log correlation. To understand more about DFW logging, see Chapter 11, Managing and Monitoring VMware NSX Platform.

DFW Saved Configurations Whenever a DFW rule is created, deleted or modified, and the change is published, NSX Manager will generate an autosaved configuration, and this can be viewed under the Saved Configurations tab. At the time of writing, the maximum that NSX Manager will save is up to 100 configurations, as per the NSX 6.3 for vSphere recommended configuration maximums (https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.3/NSX%20for%20vSphere%20Re commended%20Configuration%20Maximums_63.pdf). In NSX 6.2.3 and later, this autosave feature (also called the auto drafts feature) can be disabled via a REST API call. Disabling the auto drafts feature might improve performance especially when making large numbers of changes to the DFW rules. Disabling the feature will also prevent previously-saved drafts from being overwritten.

See also For details on how to configure syslog for distributed firewall, see Chapter 11, Managing and Monitoring VMware NSX Platform, Configuring and viewing the NSX Distributed Firewall Log.

[ 247 ]

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

Creating Security Policy Rules from the Service Composer menu In the previous recipe, we created DFW rules using the Firewall Table menu, which is more suitable for static environments. In this recipe, we will create security policy rules from Service Composer, which is more suitable for the application-based policies approach.

Getting ready In the Service Composer, a security group of what we want to protect must be created first, then a security policy can be created and applied to that security group. In our example, we need to create three security groups and three security policies: one for the Web tier, one for the App tier, and one for the DB tier.

How to do it... In this recipe, we will create the security group from Service Composer using various methods, and then create a security policy utilizing the newly-created security groups.

Creating a Security Group using Static Inclusion In this section, we will create a security group, SG-DB-Tier, for the database VM and use static membership to include the db-01a VM as the member: 1. From the vSphere web client, navigate to Home | Networking & Security | Installation | Service Composer. 2. In the center pane, click the Security Groups tab and click the New Security Group icon:

[ 248 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

3. Input the Name of the security group, in this case SG-DB-Tier, optionally input a Description, and click Next, or click the desired way to do security group membership (2 Define dynamic membership | 3 Select objects to include | 4 Select objects to exclude):

[ 249 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

We will use static membership in this example, so we can skip the Define dynamic membership menu and click Next. 1. In the Select objects to include menu, select the desired Object Type, in this case Virtual Machine, and select the desired VM. We can skip the Select objects to exclude as we don't need to exclude anything at the moment we can skip number 4. We can click Next until we get to menu number 5 Ready to complete if we want to review all the settings first, or go straight to Finish.

[ 250 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

Creating a Security Group using Dynamic Membership In this section, we will create a security group, SG-App-Tier, for the App VM and use dynamic membership to include the app-01a VM as the member: 1. Similar to the steps covered previously, create a new security group, in this example SG-App-Tier, optionally input the Description, and click Next or click the desired way to do security group membership. 2. We will use dynamic membership and include a VM that has VM Name, Contains, app. For example, we can add additional criteria under one Membership criteria; in this example we are only interested in Entity Belongs to a specific cluster RegionA01-COMP01. We can match Any or All of the criteria we defined; we are interested in using All in this case. Click the Next button once you are satisfied with the Criteria Details:

[ 251 ]

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

3. We will not use static membership, so we can skip Select objects to include. On Select objects to exclude, in this example we will exclude any other VMs that have app in the VM name, as we are only interested in the app-01a VM. We can click Next to go to Ready to complete if we want to review all the settings first, or go straight to Finish:

Creating a Security Group using Security Tag as the Dynamic Membership Criteria In this section, we will create a security group, SG-Web-Tier, for the web VM, use dynamic membership to include Security Tag ST.Web, and tag web-01a and web-02a VMs with ST.Web: 1. Similar to the steps covered previously, create a new security group, in this case SG-Web-Tier, optionally input the Description, and click Next. 2. We will use dynamic membership and include a VM that has Security Tag, Contains, ST.Web. Click Next until we get to Ready to complete if we want to review all the settings first, or go straight to Finish:

[ 252 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

3. To create and assign a Security Tag to the VMs, navigate to Networking & Security Inventory | NSX Managers | NSX manager's IP Address. 4. Select Manage | Security Tags and click the New Security Tag:

5. In the New Security Tag dialog box, input the Name of the security tag, in this example ST.Web, optionally input the Description, and click OK. 6. To tag a VM with security tag, select the ST.Web security tag and click the Assign Security Tag icon.

[ 253 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

7. In the new dialog box, select the desired VM objects, in this case web-01a.corp.local and web-02a.corp.local, and click OK:

Security Tags can also be assigned from VM Summary | Security Tags | Manage.

Creating a Security Policy In this section, we will create a security policy, SP-Web-Tier, and apply it to SG-WebTier: 1. From the vSphere web client, navigate to Home | Networking & Security | Installation | Service Composer. 2. In the center pane, click the Security Policies tab and click the Create Security Policy icon:

[ 254 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

3. Input the Name of the security policy, in this case SP-Web-Tier, and optionally input the Description:

[ 255 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

4. We will use static membership in this case, so we can skip the Define dynamic membership menu and click Next:

5. Once the security policy is created, it needs to be applied to the appropriate security group; you will see that the Applied to column is still showing 0. Select the SP-Web-Tier security policy and click the apply security policy icon, or click Actions and select Apply Policy:

[ 256 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

6. In the Apply to Security Groups dialog box, select the desired security group, which is SG-Web-Tier in this case, and click OK:

7. Repeat the previous steps to create the remaining SP-App-Tier and SP-DB-Tier security policies. Every time a new security policy is created, it will have its weight set to 1,000 more than the highest existing security policy; this will make the latest created security policy on the Rank 1. To arrange the security policy ordering, select a security policy and click the Manage Priority icon. Put the SPWeb-Tier to be in the first order followed by SP-App-Tier and SP-DB-Tier:

[ 257 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

8. Apply each security policy to the appropriate security group and verify that the Status column has changed to Published:

9. Once applied, the Service Composer will automatically create a new section on the Firewall menu, one section per security policy. The security policies will be Applied To Distributed Firewall by default:

[ 258 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

Sections and rules that are managed by NSX Service Composer cannot be manually modified through the firewall menu.

How it works... In this recipe, we have covered multiple ways to construct a security group using static and/or dynamic inclusion. The result of a dynamic security group definition is =dynamic inclusion + static inclusion - static exclusion. Any object in the Service Composer's security policy needs to be a security group, and the policy will also need be applied to one or more security groups; therefore, the security group objects must be created first before creating the security policy. When defining security policy rules, either the source or the destination (or both) must be the policy's security group. Currently there is no menu or link in the security policy that can define a new security group on the fly. The security group is not restricted to being used in the Service Composer; the security group object can also be used in the firewall menu to create the network-based or infrastructure-based approach.

Verifying DFW rules To verify the rules are deployed on a host and applied to the virtual machine's vNIC, we will need to use the command-line interface. This recipe will show you how to validate DFW rules from both the ESXi host that is prepared for NSX and the NSX manager.

Getting ready To use the command line for validating DFW rules, make sure you have the following: Access to the NSX manager shell through the VM console or SSH; the default user is admin Access to the ESXi host shell through the ESXi console, DCUI, or SSH; the default user is root

[ 259 ]

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

We are interested in the vNIC filter name that the VM uses or attached and we will verify the rules that are applied to that filter name. The filter naming should be nic-#####eth#-vmware-sfw.2.

How to do it... This recipe shows how to validate DFW rules from the NSX Manager central CLI and from an ESXi host.

Using NSX Manager central CLI Follow the steps below and commands on how to verify DFW rules that get pushed into the ESXi host from NSX Manager: 1. Log in to the NSX Manager console. 2. To locate the vNIC filter name, use the following commands: show show show show

dfw dfw dfw dfw

cluster all cluster host vm

3. To show the applied rules, use the command show dfw host filter rules. 4. The output will use NSX internal objects addrset such as dst###, ip-ipset-#, and ip-vm-### as the source or destination. To view the actual mapping between internal objects and the associated IP or MAC address, use the command show dfw host host-31 filter nic69373-eth0-vmware-sfw.2 addrsets.

Using ESXi Host CLI Follow the steps below and commands on how to verify DFW rules to the ESXi from the ESXi console: 1. Locate the VM that you want to validate and SSH into the ESXi host; in this example, we will validate the DFW rule for the VM web-01a.

[ 260 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

2. Type summarize-dvfilter, look at the VM name, and look for name under vNIC slot 2. If there are too many lines of information, you can filter using grep. For example, filter by web-01a or sfw.2 with the command summarizedvfilter | grep 'web-01a|sfw.2'. The other method to obtain the filter name is using vsipioctl getfwfilters. However, this command will show the VM UUID instead of VM name 3. To show the applied rules, use the command vsipioctl getfwrules -f nic-76730-eth0-vmware-sfw.2 The output will use NSX internal objects addrset such as dst###, ip-ipset-#, and ipvm-### as the source or destination. To view the actual mapping between internal objects and the associated IP or MAC address, use the command vsipioctl getaddrsets -f nic69373-eth0-vmware-sfw.2.

Leveraging the DFW Applied To field In the previous Creating DFW rules from the firewall menu recipe, we left the Applied To settings as the default settings (distributed firewall), which applied the DFW rules to all VM's vNICs regardless of VM's location. You may want to change the Applied To settings if you are in one of the following situations: In an environment where you have overlapping IP addresses; normally in multitenant or developer environments When using app isolation in NSX with vRealize Automation (vRA) In a brownfield environment where you want to onboard a specific workload or application In an environment where you want to reduce the scope of DFW rules; this will improve DFW efficiency, as the DFW will have fewer rules to evaluate

Getting ready Make sure you have an existing DFW rule for which you want to have the Applied To field changed.

[ 261 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

How to do it... This recipe will show you how to change and use the Applied To settings, both from the Firewall Table Menu and from the Service Composer menu.

Changing Firewall Default Applied To settings from the Firewall Table Menu Follow these steps to change the Applied To settings from the firewall table menu: 1. From the vSphere web client, navigate to Home | Networking & Security | Firewall, select a DFW rule, and edit the distributed firewall value under the Applied To column:

2. Select whether you want to apply the rule to all clusters with DFW, to all edges, or to specific objects. In this example, we will apply to a specific cluster, RegionA01-COMP01:

3. Click the Publish Changes button once completed.

[ 262 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

Changing Service Composer Firewall Default Applied To Settings Although the Service Composer will apply a policy against the security group, the default behavior of the Service Composer is applied to the distributed firewall which will be applied to all vSphere clusters that have DFW installed and enabled. Follow the steps below to change the default behavior in Service Composer: 1. Navigate to Service Composer | Security Policies. 2. Select any security policy (or create one if none exists). Click Action | Edit Policy Firewall Settings. In newer NSX (6.3.3 onwards), the Policy Firewall Settings is part of Global Settings:

3. Change the Default Applied To value to Policy's Security Group and click OK.

There's more... When overlapping IP addresses are used, such as in a multitenant environment, it is important to not use the default DFW behavior applied to all distributed firewall and only apply to specific VMs or groups of VMs.

[ 263 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

See also NSX and vRealize Automation Micro-Segmentation tech guide (https:/​/ communities.​vmware.​com/​docs/​DOC-​32774)

Deploying Network or Guest Introspection Services As explained in the introduction, the NSX DFW offers service insertion with third-party partner network and security services, which can be network introspection services or Guest Introspection services. In this recipe, we will deploy third-party network and security services for NSX. Once services are deployed, the network or guest introspection rules can be created through the Service Composer covered in earlier recipes.

Getting ready Make sure you have Security Administrator or Enterprise Administrator access to NSX. To deploy partner services, the following prerequisites need to be satisfied: A third-party management component must be deployed. Check the vendor's documentation. Third-party service VM OVA must be downloaded or prepared. vSphere cluster must be prepared for NSX. Network or Guest Introspection services are deployed on a vSphere cluster basis. Data stores, PortGroups, and IP addresses should be allocated for the partner service VM. Partner service VMs will be deployed in each host and will use a shared data store and dvPortGroup. To deploy them in non-shared data store and standard vSwitch network, use the agent VM settings as described in the There's more... section.

[ 264 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

How to do it... There are two high-level steps for deploying partner services in NSX; the first is registering the service definition, and the second is deploying the partner service VMs. For Guest Introspection services, there is an additional step, which is to install the thin agent that comes with VMware Tools on the Guest VM.

Registering Service Definition The first step before we deploy a network introspection service is to register the service to the NSX Manager. This is normally done through third-party management components by registering it to the NSX Manager and vCenter server. Refer to the hardware vendor documentation for information on how to perform the service definitions registration, as the procedure may vary from vendor to vendor. Following are the high-level steps of the service definition registration procedure: 1. 2. 3. 4.

Log in to the third-party management component. Register or connect to the vCenter server if required. Register or connect to the NSX Manager. Supply the OVF/OVA/image URL of the vendor's service VM. A separate web server might be required to host the OVF/OVA/image file.

After the third-party service has been registered, the service and vendor name, along with the functions, will be displayed in the list of services available for installation under the NSX Manager | Networking & Security | Service Definitions tab or the Service Managers tab.

[ 265 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

Deploying the Service VM Once the third-party service is registered and listed under NSX service definitions, we can start deploying the services by following these steps: 1. In vSphere web client, navigate to Home | Networking & Security | Installation | Service Deployments. Click the green plus symbol:

2. In the new dialog box, Deploy Network & Security Services, tick the desired services from the list (in our example, the service is Palo Alto Networks NGFW). Leave the Specify schedule default to Deploy now to deploy immediately, or select Schedule the deployment if you want to deploy it later. Click Next to continue:

[ 266 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

3. Select the desired vSphere Cluster and click Next. 4. Select the desired Datastore, Network and IP assignment, and click Next:

5. The default IP assignment is DHCP; to use static IP, click Change. In the new Select IP Assignment mode dialog box, select an existing or create a new IP Pool. After selecting the desired IP Pool, click OK:

5. Once the desired settings are selected, click Finish. Review the settings and click Finish. 6. Once the Network & Security services VMs are deployed, you can create the traffic redirection rules using the security policy from the Service Composer menu.

[ 267 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

Installing VMware Tools for Guest Introspection 1. Guest Introspection uses a thin agent to intercept file events on the guest. The thin agent is required for Guest Introspection services but not required for Network Introspection Services. The thin agent is installed as part of the Full VMware Tools setup type or under VMCI Driver on the Custom VMware Tools Setup:

In the older ESXi versions, the thin agent driver is called vShield endpoint thin agent or Guest Introspection thin agent. In newer ESXi versions, the name of the driver is NSX File Introspection Driver.

[ 268 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

How it works... The third-party vendors' service definition registration process uses the NetX management plane API to enable bidirectional communication between the service VM management and the NSX manager. The service definition includes the URL for accessing the OVA/OVF/image URL and other supporting information, which NSX manager uses to perform the auto deployment of the service VM to a vSphere cluster. After the service VM gets deployed and powered on, it will be connected to the ESXi and vSwitch via the NetX data plane API over Virtual Machine Communication Interface (VMCI) sockets. This can be seen from the Networking & Security | Service Definitions | Service Instances | Manage | Settings menu; the Transport should be VMCI:

VMCI (https://www.vmware.com/support/developer/vmci-sdk/) is a virtual device/virtual socket that provides fast and efficient communication between virtual machines or between virtual machines and ESXi without using the virtual switch network layer. This enables the deployment of the Service VM with no changes to the network topology. The service VMs will be deployed onto a vSphere resource pool called ESX Agents; this resource pool is created by the EAM system to place the network introspection service VMs.

[ 269 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

Workloads other than the service VM should not be deployed onto this ESX agent's resource pool.

The service VM's details and IP address information can be seen in the Virtual Machine | vApp Options settings. Once the Service VMs are deployed, create the network or introspection rules through Service Composer.

Blocking Non-IP Layer 2 Traffic Non-IP layer 2 traffic cannot be steered to the third-party service VM. To ensure that all traffic is correctly filtered, a layer 2 rule only allows ARP, IPv4, and IPv6, and blocks everything else. This rule can be created under the Ethernet menu; the ARP, IPv4, and IPv6 services do not exist by default and need to be manually created:

There's more... When deploying service VMs under the Deploy Network & Security Services menu, only the shared datastore and dvPortGroup can be selected from the menu. To deploy the service VMs on a non-shared data store and standard vSwitch PortGroup, we can select Specified On-host settings for the deployment:

[ 270 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

For the specified On-host settings to work, each ESXi host in the cluster needs to have Agent VM Settings configured. The Agent VM Settings can be found in Home | Host and Clusters | ESXi host | Configure | Agent VM Settings:

See also Troubleshooting vShield Endpoint/NSX Guest Introspection (2094261) (https://kb.vmware.com/kb/2094261) How to collect logs in NSX for vSphere 6.x Guest Introspection (2144624) (https://kb.vmware.com/kb/2144624)

[ 271 ]

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

Configuring the Identity Firewall NSX DFW offers an Identity Firewall (IdFW) feature, where security policy rules can be created based on a user or a group of users, which works for both virtual and physical desktop systems. In this recipe, we will register NSX Manager to a Microsoft Active Directory and configure a DFW rule based on an AD user/group object.

Getting ready Before configuring NSX IdFW, make sure you have AD user credentials with read permission for all objects in the domain tree and with read permissions for security logs when using a physical desktop. NSX IdFW also uses the Guest Introspection VM to do user-to-IP mapping on the virtual desktop; make sure the Guest Introspection services VM's are deployed before or after configuring the security policy.

How to do it... For IdFW to work, NSX will need to be synchronized to Directory Services first and, in this example, we will use Active Directory. Once NSX Manager is able to query Active Directory and is synchronized, a Security Group based on the domain user group can be used to construct DFW rules for IdFW.

Registering a Microsoft Active Directory Domain with NSX Manager Follow these steps to add an AD for NSX Manager to query: 1. In the vSphere web client, navigate to Home | Networking & Security | NSX Managers. 2. Select the desired NSX Manager's IP Name in the left-hand pane. In the center pane, click the Manage tab and select Domains. Click the green plus icon to add a new domain:

[ 272 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

3. In the Add Domain dialog box, enter the Fully Qualified Domain Name (FQDN) and NetBIOSName:

How to get the NetBIOS name To display the NetBIOS name table of a local Windows computer that is part of a domain, type nbtstat -n or nbtstat /n from a Windows command prompt. The NetBIOS name will be a Name entry with a suffix and group as the type listed under NetBIOS local name table. 4. To filter out users with no active accounts, tick Ignore disabled users. To add child domains, tick Auto merge. Click Next to continue. Older VMware NSX versions do not have ignore disabled users and auto merge options.

[ 273 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

5. In the LDAP Options, specify the desired active directory domain controller Server to be synchronized, Protocol, Port, User Name, and Password, and click Next to continue:

6. The default ConnectionMethod and Port to access Security Event logs are CIFS on port 445; change these settings if required. 7. To use alternate user credentials, untick the Use Domain Credentials and input the User Name and Password. Otherwise, tick UseDomainCredentials to use the LDAP options user credentials. Click Next to review the settings and click Finish: The event log access account must have read permissions to the Windows security log.

8. The new setting will be listed in the table; make sure the Last Synchronization Status is SUCCESS so that NSX can use the AD objects in security policies. To manually update the local state AD objects delta since the last synchronization, click the single gear icon or use the double gears icon to update all AD objects:

[ 274 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

Creating Security Rules using Active Directory Objects Follow the steps below to configure a Security Group based on AD objects and use it to construct DFW rules: 1. In the vSphere web client, navigate to Home | Networking & Security. 2. Create a security group based on an AD user or group as the source, using the directory group as the object type. In this example, we will create a security group called administrators to include AD object group administrators. The security group construct can be based on dynamic membership:

[ 275 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

Or based on static membership using Select objects to include:

3. Create a security policy from the firewall menu or Service Composer menu, using the created AD-based security group as the Source. In this example, we will allow the Administrators AD Group to SSH into VMs on the cluster RegionA01COMP01:

The destination can also be an IPSet which resides outside of vSphere or a vSphere cluster that does not have NSX DFW protection.

[ 276 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard

Chapter 6

How it works... The preceding steps show that we can create a security policy rule that will permit or deny traffic based on a Active Directory group object using the security group. The source can be a virtual desktop virtual machine or a physical desktop. For a virtual desktop, NSX will use the Guest Introspection VM to do the IP-to-user mapping, while for a physical desktop, NSX will query the Active Directory server and check the AD security logs to do the IP-to-user mapping. The NSX Manager stores the IP-touser mapping result in the user cache database in NSX Manager and sends this information to the NSX DFW component in the ESXi Host for NSX DFW to apply to the appropriate destination VM's vNIC. Being IP-based, this architecture cannot enforce guest-level attributes such as user sessions or processes and simultaneous login for multiple users such as terminal services or a remote desktop session host (RDSH).

There's more... One of the new feature in NSX 6.4 is the context-aware architecture, which allows for applying DFW rules to user sessions, sharing an IP address such as on terminal services or RDSH.

[ 277 ]

||||||||||||||||||||

||||||||||||||||||||

7 Configuring Cross-vCenter NSX In this chapter, you will learn how to configure Cross-vCenter NSX. We will be looking at the following recipes: Configuring Primary and Secondary NSX Manager(s) Creating a Universal Transport Zone and adding a vSphere cluster to the Universal Transport Zone Creating a Universal Logical Switch Creating a Universal Logical Router Adding a VM to a Universal Logical Switch Understanding and configuring the Universal Distributed Firewall

Introduction Cross-vCenter NSX is a feature that was introduced in VMware NSX for vSphere 6.2. CrossvCenter NSX allows for NSX networking and security support across multiple vCenter servers, which allows you to span NSX services across vCenter boundaries that may be tied to geographic boundaries. Logical switches, distributed logical routers, and the distributed firewall can all now be deployed across multiple vCenter domains. Cross-vCenter functionality provides the following key benefits: Provides a comprehensive solution covering layer 2 and layer 3 Logical Networking and Distributed Firewall across vCenter boundaries Decouples these constructs from the underlying network infrastructure Fully integrated software solution and is not dependent on hardware Overcomes scaling limitations of a single vCenter deployment and allows up to eight vCenter servers to be configured in a Cross-vCenter topology

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

Increases the span of NSX logical networks, which allows for: Capacity pooling across multiple vCenter servers Non-disruptive migration Provides extensibility of layer 2 components across physical layer 3 transport networks Enhanced NSX multi-site and disaster recovery capabilities Provides a centralized security policy management framework. Firewall rules can be managed from the vSphere web client, and security policy can be applied to VMs regardless of their physical location within one of the managed vCenter environments Local egress route optimization. In Cross-vCenter NSX, you could select which outbound path traffic traverses, depending on which data center the VM resides Cross-vCenter NSX can span up to eight vCenter environments, with one Primary NSX Manager and the remainder assigned as Secondary NSX Managers. The role of the Primary NSX Manager is to be the master site that performs synchronization across all secondary NSX Managers and is the configuration point for all universal objects. All secondary NSX Managers can only manage local objects specific to their local site. A universal object can be defined as a logical switch that spans across one or more vCenter environments, which is now known as a Universal Logical Switch. The following is a list of other universal objects: Universal Distributed Logical Router (UDLR) Universal Distributed Firewall (UDFW) Universal Security Groups Universal Security Tags Universal IP sets Universal MAC sets Universal Services Universal Service Groups All universal objects are created and managed by the Primary NSX Manager; it is the Primary NSX Managers responsibility to replicate these objects to all secondary NSX Managers and to update the Universal Controller Cluster. All universal objects can be viewed on the Secondary NSX Manager(s), but they are read-only; all configuration for these objects must be performed on the Primary NSX Manager.

[ 279 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

In a Cross-vCenter deployment, a single NSX Manager or site must be deemed as primary; at this point, you need to promote the NSX Manager to the Primary role. Once promotion is initiated, the Primary NSX Manager starts the universal synchronization service, and this service is used to synchronize all universal objects and universal firewall rules across the different NSX vCenter domains. This ensures that synchronization is done in real time to safeguard the integrity of the databases across sites. In addition, a periodic sync is performed to confirm all NSX Manager universal configuration is consistent with the primary site; this is required to ensure whether a Secondary NSX Manager was not reachable during an earlier synchronization operation, the delta is synced across. The following diagram provides an overview of what a Cross-vCenter NSX topology consists of:

The Primary NSX Manager vCenter domain/site also contains the Universal Controller Cluster (UCC) that provides the control plane for all Cross-vCenter objects, also known as universal objects. The UCC is deployed by the primary NSX Manager onto a vSphere cluster that is managed by the vCenter server that is paired with the Primary NSX Manager. Therefore, all Secondary NSX domains/sites do not have a local controller cluster as they previously did in a standalone deployment. Consequently, the UCC is the control plane for all ESXi hosts that are located at the Secondary site as well as the Primary site.

[ 280 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

Each NSX Manager, including the Primary NSX Manager, can create objects that are local to their specific vCenter NSX environment, such as logical switches and distributed logical routers. They will exist only within the vCenter NSX environment in which they were created. This provides the flexibility to selectively create NSX configurations which are universal or local. Workloads which could potentially exist across data centers would be associated with universal objects and workloads that should not transmit across data centers would typically be associated with local objects. NSX Edge gateways are considered local objects even though they can be connected to universal logical switches; their creation and management is performed by the local NSX Manager of the vCenter environment in which you want to create them. The Universal Controller Cluster is the control plane for all universal objects and all local objects created. For example, using the following figure, NSX Manager C creates a new logical switch with a VNI of 5001; the logical switch configuration will be pushed to the UCC, and the UCC will maintain the configuration and push it out of all ESXi hosts in Site C only. Therefore, the Universal Controller maintains information about both local and universal logical routers/switches. It maintains this information by using separate object IDs for the different objects in its database:

It's also important to understand that not all NSX configurations and services are supported in a Cross-vCenter deployment; however, these services can still be used in a local context. The following table details which services are or are not available in Cross-vCenter NSX: NSX service Logical switch

Configuration construct

Cross-vCenter support

Transport zone

Yes

Logical switch

Yes

Layer 2 bridging

No

[ 281 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Routing

Logical Firewall

Chapter 7

Distributed router

Yes

Distributed router control virtual machine

Must be created locally via the NSX Manager unless more complex configurations are required for local egress network topologies

Edge services gateway

No

Distributed Firewall

Yes

Exclusion list

No

SpoofGuard

No

Flow monitoring for aggregate flows No Network Service Insertion

No

Edge Firewall

No

VPN

No

Logical load balancer

No

Other Edge services

No

Service Composer

No

Network extensibility

No

Network and security objects

IP sets

Yes

MAC sets

Yes

IP pools

No

Security groups - limited support for Yes vCenter constructs Services

Yes

Service groups

Yes

Security tags

Yes

Hardware VTEP

No

In the remainder of this chapter, we will explore the concepts outlined above in more detail.

[ 282 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

Configuring Primary and Secondary NSX Manager(s) In this recipe, we will go through the steps to promote a standalone NSX Manager to primary and another to secondary. The rationale as to which site should be primary and which should be secondary typically aligns to the primary and disaster recovery data center designation. However, this rule does not mandate how to determine which side is primary and your reasoning may differ. It is important to choose which side is going to be primary with careful planning as this is where the local controller cluster will take the role of the UCC and therefore be a critical component of your Cross-vCenter NSX network topology. In the following diagram, we have outlined our two vCenter environments and their corresponding NSX Managers. It is expected both have been deployed as per the steps highlighted in Chapter 1, Getting Started with VMware NSX for vSphere, and assume the role of standalone to begin with:

Getting ready To configure NSX Primary and Secondary roles, the following prerequisites must be satisfied: User with NSX Enterprise Administrator or NSX Administrator role NSX Managers in both vCenter domains must be deployed

[ 283 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

Each NSX Manager should be registered against its corresponding vCenter server Each NSX Manager should be registered against the platform services controller for single sign-on services Each NSX Manager must have both forward and reverse DNS records Each NSX Manager should have DNS and NTP configured and resolvable Connectivity between each NSX Manager's be open and accessible VXLAN UDP port numbers of the Primary and secondary NSX Manager match

How to do it... The following steps detail how to assign roles to the NSX Managers: 1. Log into the vSphere web client. 2. Navigate to Networking & Security | Installation | Management. Select NSX Manager 192.168.110.42 , click Actions, and select Assign Primary Role:

3. Click Yes to assign the role.

[ 284 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

4. Select NSX Manager 192.168.110.42, click Actions, and select Add Secondary NSX Manager:

5. Type the following information (please use the configuration from your own environment) into the Add Secondary NSX Manager dialog and click OK: NSX Manager:

192.168.210.42

User Name:

admin

Password:

VMware1!

Confirm password: VMware1!

[ 285 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

6. Click Yes to trust the certificate after verifying the thumbprint. 7. Ensure each NSX Manager has the role Primary or Secondary in the Management pane as shown in the following screenshot:

How it works... When each NSX Manager has the role of a standalone, there is no synchronization or communication between the two appliances. Therefore, you first need to promote a single NSX Manager to the primary role and then add the secondary NSX Managers (up to seven) to the primary NSX Manager. Each addition requires the local credentials of the NSX Manager and the certificate present on each NSX Manager is used to secure communication. If the certificate is self-signed, you will need to accept the certificate thumbprint upon connection.

[ 286 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

Once the primary NSX Manager role is assigned, it will start the universal synchronization service, which is used to keep all universal constructs in sync between all secondary managers. This service is only started on the primary NSX Manager and remains in the stopped position on all secondary NSX Managers:

Adding secondary NSX Managers may fail due one of the following reasons: NSX Manager node ID is empty. Duplicate NSX Manager node ID as either primary or one of the existing secondaries. This can happen if an NSX Manager is cloned. NSX Manager has installed NSX controller nodes. NSX Manager has overlapping segment ID pools with either the primary or one of the existing secondaries. Controller import or universal object creation fails. Connectivity on TCP port 443 between the Primary and secondary NSX Managers is not open. VXLAN UDP port does not match with primary NSX Manager.

There's more... The following subsections detail the role of Enhanced Linked Mode (ELM), the different roles that can be assigned to NSX Manager, and the universal synchronization service.

[ 287 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

Enhanced Linked Mode In vSphere 6.0, a feature called ELM was introduced, which allows you to link multiple vCenter servers using a common set of Platform Services Controllers (PSCs). This feature provides the capability to view and search the inventories of all the linked vCenter server systems from the vSphere web client. For NSX, in a Cross-vCenter NSX environment, ELM provides you the ability to manage all your NSX deployments from a single management interface. It should be noted that ELM is not a prerequisite or requirement for CrossvCenter NSX. You are not required to have ELM configured to create universal constructs in NSX but it does ease the operational overhead of accessing multiple management interfaces.

NSX Manager roles When you place NSX Managers into a Cross-vCenter topology, a new concept of roles is introduced. Depending on the state of the NSX Manager, a different role may be applied. The roles are as follows: Standalone: Default option for all new installations. All objects are created in the globalroot-0 scope by default and are classified as local. Primary: In a Cross-vCenter topology, a single NSX Manager is assigned the primary role. This NSX Manager deploys and manages the UCC. Secondary: The secondary role designation is given to NSX Managers that move from the standalone role to secondary, so they can participate in the CrossvCenter NSX topology. Transit: This is a temporary state, objects that were assigned to an NSX Manager that has the primary or secondary role removed and universal objects are still present. All universal objects need to be deleted from the NSX Manager before it can move to a standalone role.

[ 288 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

Universal Synchronization Service Management and Troubleshooting There is no further user configuration required to perform automatic synchronization, but synchronization can be initiated by a user through the Management menu under Networking & Security in the vSphere web client. The following screenshot depicts the menu option:

The script to manage the universal synchronization service is located in /etc/rc.d/init.d/nsxreplicator-mgmt {start|stop|restart|status} on the NSX Manager virtual machine. The logs for the universal synchronization service are not forwarded to a syslog destination but are included in the tech support log bundle and located in the directory /home/secureall/secureall/logs/replicator.log. A special replicator user is created when the secondary NSX Manager is registered and used to execute REST APIs for the synchronization. The password for the replicator user is randomly generated and stored on the filesystem encrypted. The replicator user has limited privileges on NSX Manager, where it can create/update/delete only universal objects.

[ 289 ]

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

Creating a Universal Transport Zone and adding a vSphere cluster to the Universal Transport Zone Only a single Universal Transport Zone can exist in a Cross-vCenter topology. As we reviewed in Chapter 2, Configuring VMware NSX Logical Switch Networks, a transport zone is used to define the scope of a logical switch. In the case of a Cross-vCenter NSX environment, the Universal Transport Zone is used to define the scope of universal logical switches and universal logical routers. As discussed in the explanation in Chapter 2, Configuring VMware NSX Logical Switch Networks, a transport zone defines the scope of where Logical Switches and Distributed Logical Routers can span. In the case of Universal Transport Zone, we define this scope across vCenter boundaries and it usually spans data centers. A vSphere cluster can be connected to a local transport zone as well as a Universal Transport Zone; they are not mutually exclusive. At the time of writing, only a single Universal Transport Zone could be created for use in a Cross-vCenter deployment.

The requirement of a 1600-byte MTU for VXLAN traffic still exists and should be enabled across the physical network infrastructure, prior to implementing universal logical switches. Replication mode, as detailed in Chapter 2, Configuring VMware NSX Logical Switch Networks, still applies for the Universal Transport Zone and should be planned carefully. If your physical infrastructure does not support multicast, set the replication mode to unicast; unicast mode is typically used in most deployments.

[ 290 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

In this recipe, we will create a transport zone called Universal-Transport-Zone and will span both sites and vSphere clusters, as shown in the following diagram:

In addition to creating a Universal Transport Zone, unique segment IDs must also be created. It is best practice for segment IDs not to overlap and each transport zone should have a uniquely identifiable segment. The following table details the segment IDs for each site and for the Universal Transport Zone: Site name Transport zone

Segment ID

Site A

Local - global

5000 - 5999

Site B

Local - global

6000 - 6999

Both

Universal-transport-zone 10000 - 10999

[ 291 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

Getting ready To configure the Universal Transport Zone and add a vSphere cluster, the following prerequisites must be satisfied: User with NSX Enterprise Administrator or NSX Administrator role NSX Managers in both vCenter domains must be deployed and configured for Cross-vCenter NSX Controller cluster in primary site is deployed and accessible Unicast control plane replication will be used ESXi hosts in either site can communicate with one another from their VTEP interfaces and the 1600-byte MTU has been set on the physical infrastructure

How to do it... The following steps detail how to assign a segment ID for universal objects and how to create a universal transport zone: 1. Log into the vSphere web client. 2. Navigate to Networking & Security | Installation | Logical Network Preparation. 3. Ensure the NSX Manager selected is Primary:

[ 292 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

4. Select Segment ID and click Edit:

5. For the Universal Segment ID pool, enter the unique range of 10000-10999 and click OK:

6. Change to the Secondary NSX Manager from the drop-down menu:

[ 293 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

7. Ensure the Universal Segment ID pool has been replicated to the secondary NSX Manager and the local Segment ID pool does not overlap with the primary NSX Manager. 8. Navigate to Transport Zones and click Add. 9. Select Mark this object for Universal Synchronization. 10. Type the name as Universal-Transport-Zone, select Unicast as the Replication mode, select both the compute and management clusters to be added to the transport zone, and click OK:

[ 294 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

11. Change to the Secondary NSX Manager from the drop-down menu. 12. Select the newly created Universal-Transport-Zone, click Actions, and then Connect Clusters:

13. Select the clusters in Site B and click OK.

How it works... When creating a logical switch, you must specify which transport zone to create it against; whichever transport zone you select will define the scope of the logical switch across ESXi hosts. In the case of universal, there can only be a single universal transport zone; therefore, when selecting this transport zone in a logical switch definition, it is created for all vSphere cluster hosts that are participating in the Universal Transport Zone. See Chapter 2, Configuring VMware NSX Logical Switch Networks, to understand how a transport zone works. In addition, which vSphere clusters to add to the Universal Transport Zone to, depends on where you want universal logical switches and universal distributed routers to exist. It is typically best practice to assign the vSphere clusters which have been assigned to a local transport zone already or to align the Universal Transport Zone to a specific vDS configuration per vCenter environment. See Chapter 2, Configuring VMware NSX Logical Switch Networks, for further information on transport zone alignment.

[ 295 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

Creating a Universal Logical Switch A universal logical switch allows layer 2 segments to span across multiple sites and multiple layer 3 boundaries. Like creating a logical switch in a standalone deployment, a universal logical switch when created is tied to a Universal Transport Zone, which defines the span of the universal logical switch. In this recipe, we will configure three universal logical switches for a three-tier app, as depicted in the following diagram:

[ 296 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

Getting ready To configure a universal logical switch, the following prerequisites must be satisfied: User with NSX Enterprise Administrator or NSX Administrator role NSX Managers in both vCenter domains must be deployed and configured for Cross-vCenter NSX Controller cluster in primary site is deployed and accessible Unicast control plane replication will be used ESXi hosts in either site can communicate with one another from their VTEP interfaces and the 1600-byte MTU has been set on the physical infrastructure Universal Transport Zone and corresponding segment ID is configured and available

How to do it... The following steps detail how to create a universal logical switch: 1. 2. 3. 4. 5. 6. 7.

Log into the vSphere web client, Navigate to Networking & Security | Logical Switches. Ensure the NSX Manager selected is Primary. Click Add. Type the Name as Universal-Web-Logical-Switch. Click Change on Transport Zone. Select Universal-Transport-Zone and click OK.

[ 297 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

8. Ensure Replication mode is set to Unicast to match the replication mode of the previously created Universal-Transport-Zone and click OK:

10. Repeat for the following universal logical switches: Universal-App-Logical-Switch Universal-DB-Logical-Switch 11. Select the Secondary NSX Manager from the drop-down menu. 12. Ensure the newly created universal logical switches have been replicated to the secondary site and are using the same segment IDs:

[ 298 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

How it works... When creating a logical switch, you are required to select a transport zone for the scope of the logical switch. By selecting the Universal Transport Zone, you are creating a universal logical switch as opposed to a local logical switch if you were to select a local transport zone. Once the creation of the logical switch has been executed, you will see a dvPortGroup created on all virtual distributed switches that are associated to the vSphere clusters that are participating in the Universal Transport Zone. This concept is the same as that explained in Chapter 2, Configuring VMware NSX Logical Switch Networks, for local transport zones.

Creating a Universal Logical Router In this recipe, we will configure the universal distributed logical router. The operation is not dissimilar to what was explained in Chapter 3, Configuring VMware NSX Logical Routing, for a local logical network segment. The universal distributed logical router is deployed in the Primary NSX Manager vCenter domain and can be deployed in High Availability (HA) mode; to achieve a HA design, you require an interface for the UDLR control VM to use to exchange heartbeats across. The HA interface can use a VLAN-backed portgroup, a local logical switch, or a universal logical switch and it is recommended to use a universal logical switch. The reason for creating a universal logical switch, for the HA interface is also helpful during DR events in the event the UDLR Control VM needs to be restored in another vCenter domain. The following diagram shows the HA logical switch topology when connecting to the UDLR control VM:

[ 299 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

In this recipe, we will continue with the topology that was outlined in the earlier recipe, Creating a Universal Logical Switch, but with the important difference being the introduction of the UDLR control VM. The following figure depicts the logical topology for the UDLR and control VM with its associated universal logical switches. You will also notice the UDLR has been given a gateway address on each logical switch, which will form the interface IP address for each universal logical switch connected to the UDLR:

Getting ready To configure the universal logical router, the following prerequisites must be satisfied: User with NSX Enterprise Administrator or NSX Administrator role NSX Managers in both vCenter domains must be deployed and configured for Cross-vCenter NSX Controller cluster in primary site is deployed and accessible ESXi hosts in either site can communicate with one another from their VTEP interfaces and the 1600-byte MTU has been set on the physical infrastructure Universal transport zone and corresponding segment ID is configured and available Universal Logical Switches present for UDLR HA interface and transit network

[ 300 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

How to do it... The following steps detail how to configure a universal logical router: 1. 2. 3. 4. 5.

Log into the vSphere web client. Navigate to Networking & Security | NSX Edges. Ensure the NSX Manager selected is Primary | 192.168.110.42. Click Add. Select Universal Logical (Distributed) Router, configure the names, and select Deploy Edge Appliance, as shown in the following screenshot, and then click Next:

[ 301 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

6. Configure the Settings options as follows and click Next: User Name: admin Password: VMware1!VMware1! Select Enable SSH access 7. Click Add on NSX Edge Appliances. 8. Select Cluster/Resource Pool and Datastore, as shown in the following screenshot and click OK:

[ 302 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

9. Review the deployment parameters and click Next:

10. In the Configure interfaces of this NSX Edge pane, click Add. 11. For the Name field, type Web-Logical-Switch, select Internal for Interface Type, and click Change on the Connected To row.

[ 303 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

12. Select Universal-Web-Logical-Switch and click OK:

[ 304 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

13. Type the Primary IP Address as 172.16.10.1 and Subnet Prefix Length as 24 and click OK:

14. Repeat steps 10 through 13 for the Universal-App-Logical-Switch and the Universal-DB-Logical-Switch with the following options: Logical switch name

Primary IP address

Subnet prefix length

Universal-app-logical-switch

172.16.10.1

24

Internal

Universal-DB-logical-switch

172.16.20.1

24

Internal

Universal-web-logical-switch

172.16.30.1

24

Internal

29

Uplink

Universal-transit-logical-switch 192.168.250.2

[ 305 ]

Interface type

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

15. Select HA Interface Configuration, select the Universal-UDLR-HA, and click OK: 16. Review the configuration and click Next:

[ 306 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

17. Configure Default gateway settings, select vNIC Transit-Logical-Switch with the Gateway IP of 192.168.250.2, and leave all other settings to their default values. Click Next:

[ 307 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

18. Review the configuration and click Finish to start the deployment:

[ 308 ]

||||||||||||||||||||

||||||||||||||||||||

Configuring Cross-vCenter NSX

Chapter 7

How it works... The universal logical router operation is like that of the local distributed logical router, which has two main components. The first is the DLR kernel module which runs on all hosts that have been configured for the universal transport zone and the second is the control plane component, which is the DLR control VM. To verify that the UDLR has been deployed correctly to hosts at either site, you will need to SSH on to the site's local NSX Manager, and execute the command show logical-router host

[ 447 ]

||||||||||||||||||||

||||||||||||||||||||

Upgrading VMware NSX

Chapter 10

There's more... If you are upgrading an ESXi host, you will also need to check the Service Deployments menu to see if the Guest Introspection Services need to be redeployed. If the Installation Status column displays Succeeded, then no redeployment is required; however, if the Installation Status displays Failed, the Guest Introspection Service VMs need to be redeployed by clicking the Failed status and clicking the Resolve button:

[ 448 ]

||||||||||||||||||||

||||||||||||||||||||

11 Managing and Monitoring VMware NSX Platform In this chapter, we will be covering the following recipes: Monitoring NSX using NSX Dashboard Configuring the NSX Components Syslog Configuring and viewing the NSX Distributed Firewall Log Configuring vRealize Log Insight for NSX Enabling NSX Flow Monitoring Using Application Rule Manager Using NSX Endpoint Monitoring

Introduction In this chapter, we will explore the mechanisms to manage and monitor your VMware NSX for vSphere implementation to maintain a healthy and optimally performing network virtualization platform. In a distributed environment, it is important to have the proper monitoring tools in place, and it is critical to know their usage based on the circumstances. The four areas we will explore in this chapter are as follows: NSX component logs: We will look at which logs to inspect when you need to troubleshoot issues vRealize Log Insight (vRLI): We will look at how to leverage VMware vRealize Log Insight to provide additional context to your log data Monitoring tools: We will look at how to decide which in-built tools you can leverage to monitor your environment

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

NSX Logs VMware NSX for vSphere is a distributed platform that can be made up of many entities at any given time. This platform consists of ESXi hosts for distributed network services to Edge Service Gateways for centralized routing and application-orientated services, such as Load Balancing. In addition the entities that make up a NSX deployment, there are several features for which logging exists and for which logging can be configured. These are as follows: vCenter Server NSX Manager ESXi hosts NSX Edge VMs (including DLR Control VMs) The following figure describes each of the log files and their locations:

[ 450 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

Each device and log file is used as described in the upcoming sections.

NSX Manager The NSX Manager virtual machine appliance retains log data locally on the appliance itself. This log data contains logs from the following: Logical switches Logical routers Distributed Firewalls Edge Service Gateways The log file as described in the previous figure is called vsm.log ,and is located in the /home/secureall/secureall/logs. NSX Manager rotates logs once they reach a size of

200 MB, and then the file is compressed and stored. A maximum of 10 compressed files are kept. For long-term storage of log data, it is recommended to send log files to a syslog repository. In addition to normal logs, NSX Manager also has the ability to generate a tech support log bundle, which can be downloaded from the NSX Manager web UI and is essential for troubleshooting with VMware tech support.

vCenter Server The vCenter logs may also be needed for monitoring and troubleshooting. For example, NSX relies on EAM to do host preparation, and, EAM log is accessible in vCenter Server. It is recommended that you use the same syslog server for vCenter Server and NSX Manager to get a complete picture of the overall environment logs. The eam.log in vCenter Server can be located in ProgramData/VMware/VMware VirtualCenter/Logs/ for Windowsbased vCenter or /storage/log/vmware/vpx/eam.log for appliance-based vCenter Server. The other location for vCenter log files is listed in VMware KB's Location of vCenter Server log files (1021804) at https:/​/​kb.​vmware.​com/​s/​article/​1021804.

[ 451 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

ESXi host Each ESXi host in your environment that is prepared for NSX also holds four log files, which provide details of the various components of your NSX deployment. These log files and their uses are as follows: Log file location and name

Description

/var/log/dfwpktlogs.log This is the log file pertaining to the distributed firewall /var/log/vsfwd.log

This is the log for the distributed firewall user agent (process)

/var/log/netcpa.log

This is the log file containing the NSX controller to host communication details

/var/log/vmkernel.log

The DLR, DVS, VSIP, and VXLAN logs are all located in this single log. Each log entry is tagged so that its source is distinguishable. These tags are as follows: • vxlan: This is the logical switch • vdrb: This is the distributed logical router • vsip: This is the VMware Internetwork Service Insertion Platform (VSIP)

For long-term storage and easy viewing of these logs, it is recommended that you send all ESXi logs to a syslog server as well.

NSX Edge Gateway VM The NSX Edge Gateway VM is a multifaceted device that provides a number of different application services. Each application service (such as a firewall, load balancer, VPN, or DHCP) has its own log configuration, which can be enabled or disabled, and the logging level can also be adjusted as required. Again, a central syslog server should be configured to retain log data, on the NSX Manager. Up to two syslog servers can be specified globally, and if configured, the application service will log to the central syslog server as well.

Monitoring tools NSX also has in-built monitoring tools, which provide troubleshooting tools natively.

[ 452 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

Flow Monitoring NSX Manager provides a feature called Flow Monitoring that provides traffic analysis of flows from protected virtual machines. Once you enable Flow Monitoring, it will provide an output, which shows the data that the virtual machines exchange and the corresponding protocol/port information. The data produced will show ARP, ICMP, TCP, and UDP protocol information, with TCP and UDP flow information viewable from the live monitor. The live monitor allows you to select a vNIC from a virtual machine in real time and specify files to exclude flows from; you can view the resulting flow information in the flow-monitoring dashboard in vSphere Web Client. This tool is extremely useful in understanding communication between machines in your NSX environment.

Application Rule Manager Application Rule Manager (ARM) can be leveraged on demand to help secure an application by creating security groups and distributed firewall rules for applications with unknown communication parameters. ARM allows the NSX administrator to select virtual machines that need to be monitored, and while monitoring, ARM will collect the flow information. Once the monitor has been stopped, ARM will generate the recommended security groups and firewall rules for the selected virtual machines that can then be published to the distributed firewall.

Endpoint Monitoring Like ARM, endpoint monitoring enables you to see what virtual machines are sending over your network. Whereas ARM only looks at flow data, endpoint monitoring goes one step further and maps application or system processes that are running on the guest OS to network connections that the processes are consuming. Endpoint monitoring relies on VMware tools to be installed and running on the target virtual machines, and at the time of writing this book, this feature is only available on select Microsoft Windows virtual machines.

[ 453 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

vRealize Log Insight for NSX VMware vRealize Log Insight is a log-aggregation and indexing product that provides near real-time search and rich analytics on your logs. Log insight can collect log data from an array of endpoints via the syslog protocol (RFC 5424). To obtain a proper introduction to VMware vRealize Log Insight, you can watch a helpful YouTube video at https:/​/​www.​youtube.​com/​watch?​v=​KSCXPW_​pX-​E. Log Insight also has a construct called content packs. Content packs are predefined dashboards, log-extract fields, log queries, and alerting specifications for a specific product. There are a number of content packs available for more than just VMware products, and these can be found at https:/​/​marketplace.​vmware.​com/​vsx/​. NSX also ships all logs via syslog. The preferred log destination is vRealize Log Insight, as there is a feature-rich content pack available, which provides prebuilt NSX dashboards and enables you to look at important events in detail. Since NSX 6.2.3, NSX customers are entitled to vRealize Log Insight for NSX at no additional charge. For more information on this, see VMware KB's vRealize Log Insight for NSX FAQ (2145800) at https:/​/​kb.​vmware.​com/​s/​article/​2145800.

vRealize Network Insight vRealize Network Insight is a separate product provided by VMware that provides support for day-to-day operations for your NSX environment. It has rich reporting capabilities and can ingest data from multiple NetFlow sources to provide visibility into your data center environment. vRealize Network Insight is not covered in this book, but for more information you can refer to https:/​/​www.​vmware.​com/​au/​products/​vrealize-​networkinsight.​html.

Monitoring NSX using NSX Dashboard In this recipe we will explore how to use the built-in NSX dashboard to monitor your NSX environment. The dashboard provides an overall health overview of your NSX environment. Each release of NSX will provide additional reporting in the dashboard. The preceding list was accurate at the time of writing this book.

[ 454 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

Getting ready You should have the following completed at a minimum before proceeding with the remainder of this recipe: NSX Manager deployed NSX Manager registered with vCenter Server and the Platform Services Controller Access to NSX via the vSphere Web Client

How to do it... The following steps show how to utilize the NSX Dashboard for monitoring: 1. From the vSphere Web Client, navigate to Home | Networking & Security| Dashboard:

[ 455 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

2. The System Overview section has the subsections NSX Manager and Controller Nodes. You can click on the icon beside NSX Manager to see the component status and disk usage of NSX Manager:

3. The icon next to Controller Nodes will show each of the controller node statuses (running/disconnected/powered off), the peer connectivity to other controller nodes, and the connectivity to NSX Manager:

[ 456 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

4. The Backup Status section provides information on the NSX Manager backup schedule and the last backup. A warning will be displayed in case the backup is not scheduled or the last backup attempt failed. It will also show when the latest successful backup was:

5. The remaining sections, such as Edge notifications, Firewall Publish Status, Logical Switch Status, and Service Deployment Status, will only provide information if there are any notifications of errors or warnings :

[ 457 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

How it works... The NSX dashboard is very useful for quickly seeing the overall health and status of NSX components and to check whether the components are deployed, running, and have no errors or warnings. It also provides information as to whether NSX Manager backup is configured and when the last successful backup occurred so that we can check against the organization recovery point objective (RPO) policy.

There's more... In NSX 6.4, the NSX dashboard is available both in vSphere Web Client and the HTML5based vSphere Client. The NSX 6.4 dashboard introduces additional widgets and customizable custom widgets that can be created through REST APIs:

There is also a new tab in the dashboard that provides visibility into the current system's scale capacity and configuration maximums for various NSX object types. This provides visibility on the current system's capacity relative to recommended NSX configuration maximums. By default, the usage warning threshold is 80%, and is configurable through the REST API:

[ 458 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

Configuring the NSX Components Syslog In this recipe, we will configure NSX components logs to be sent to a syslog collector, view the logs via the console, and figure out how to download the tech support log. NSX Manager logs are extremely important during troubleshooting, and knowing where to get the appropriate log is crucial.

[ 459 ]

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

Getting ready You will need to have the following access and configurations present before proceeding with this recipe: NSX Manager deployed Access to the NSX Manager appliance via a web client and CLI using either the console or SSH Syslog collector available for log shipment

How to do it... This recipe is made up of three different parts, which are as follows: Configuring the NSX Manager Syslog Configuring the NSX controller node Syslog Configuring the NSX Edge Syslog

Configuring the NSX Manager syslog You can configure NSX Manager to forward logs to an external syslog server from the NSX Manager web interface UI. Perform the following steps to forward NSX Manager logs to an external syslog server: 1. Log in to the NSX Manager web interface UI via your web browser. On the NSX Manager Virtual Management homepage, click on the Manage Appliance Settings button. 2. From the General settings, locate the Syslog Server section on the center pane and click on the Edit button:

[ 460 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

3. Input the Syslog Server FQDN or IP address, the target syslog Port number, and Protocol, and click on OK once you are finished:

The NSX Manager log files are rotated after 200 MB with a maximum of 10 file retentions. If, for some reason, the NSX Manager disk is full because of the logs, they can be purged from NSX Manager CLI using the purge log manager command from privilege mode.

[ 461 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

Configuring the NSX Controller Node Syslog We will configure each of the NSX controller nodes to forward the logs to the syslog server log-01a.corp.local using UDP port 514 with the logging set to INFO. In this example, we will use the Postman REST API client to perform the task: 1. Before configuring the syslog parameters, you need to locate the NSX controller ID first. Log in to the vSphere Web Client UI and navigate to Home | Networking & Security | Installation | Management. In the center pane, under the NSX Controller nodes table, locate the Controller Node column and take note of all the controller nodes' IDs. In this example, the IDs are controller-1, controller-2, and controller-3:

2. From a REST API client, perform an HTTP POST method to URI https:///api/2.0/vdn/controller//syslog and replace the with the actual controller ID retrieved from the previous step-for example controller-1. For the body content, use the following XML payload format:

log-01a.corp.local 514 UDP INFO

[ 462 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

3. Configure the remaining required settings, such as authorization and headers; for information on how to leverage the NSX REST API using the REST API client or other tools, refer to Chapter 12, Leveraging the VMware NSX REST API for Management and Automation. 4. Upon successful configuration, you should receive a response code of 200. Repeat the steps for the remaining controller nodes.

Configuring the NSX Edge Log Follow these steps to configure the NSX Edge syslog: 1. Log in to the vSphere Web Client UI and navigate to Home | Networking & Security | NSX Edges. Select the desired NSX Edge and double-click on it:

[ 463 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

2. On the center pane, navigate to Manage | Settings | Configuration. Under the Details section, locate the Syslog servers row and click on Change to edit the syslog server details:

3. NSX Edge supports up to two syslog servers using port 514 by default. Enter the desired syslog server's IP address on the Syslog Server 1, Syslog Server 2 (if you have multiple syslog servers), and the desired Protocol (TCP or UDP), and click on OK once you are finished:

[ 464 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

4. To enable DHCP logging, navigate to the DHCP menu, and check the box Enable logging, and then click on Publish:

How it works... NSX Manager audit and system logs can be forwarded to a syslog server by configuring the syslog settings from the NSX Manager UI. NSX Manager supports TCP, UDP, TCP6, and UDP6. Multiple syslog servers for the NSX Manager are supported from NSX version 6.4 onward.

[ 465 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

The NSX Manager CLI can view three types of logs, which are also available as part of the tech support log bundle: Manager log: /logs/management_service/vsm.log System log: /logs/system/messages Appmgmt log: /logs/appliance_mgmt/vsmvam.log The audit log can also be viewed by navigating to vSphere Web Client | Networking & Security Plugin. For NSX controller node syslog server settings, it can only be configured through REST APIs, and need to be configured one by one. The logs can also be accessed from the NSX controller CLI and as part of the tech support logs. NSX controller logs are normally used when troubleshooting with VMware Global Support Services or VMware Engineering. NSX Edge's syslog configuration is performed by navigating to vSphere Web Client | Networking & Security Plugin. Each NSX Edge that is deployed must be configured individually, as the syslog settings are retained on the NSX Edge virtual machine, and only two syslog destinations can be set up globally per NSX Edge. Each Edge must also have network connectivity to the destination syslog server via a connected interface so that it can ship log data. If connectivity is not available, log data is not shipped and cannot be analyzed from a central point. Some deployments have leveraged a single shared VXLAN logical switch to connect all Edge Gateways to a common syslog server. Your topology may differ. In addition to configuring two syslog servers per edge, what you want to log must also be configured for all enabled services, which is done from the service menus themselves.

[ 466 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

There's more... One of the new features in NSX 6.4 is called the One Click Support Bundle Tool, which allows you to collect the support bundle data from multiple NSX components, such as NSX Manager, Hosts, Controllers, and Edges from one central menu:

[ 467 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

Once the bundle collection is started, the support bundle tool will perform data collection, and you can view the status from the same menu:

Configuring and viewing the NSX Distributed Firewall Log In this recipe, we will work through the process of configuring an ESXi host to ship log data to a centralized syslog server, configure a distributed firewall rule to log all flows that match its five tuple rule, and view the DFW log on the ESXi host via the console.

Getting ready You will need to have the following access and configurations present before proceeding with this recipe: NSX Manager deployed Access to vCenter Server via the vSphere Web Client

[ 468 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

Syslog collector available for the log shipment Access to the ESXi host via the SSH protocol

How to do it... This recipe is made up of two different parts-configuring NSX DFW log and viewing NSX DFW logs.

Configuring the NSX DFW logs NSX DFW logs are part of the ESXi host log and need to be configured on each ESXi host that has NSX DFW installed: 1. Log in to the vSphere Web Client UI, navigate to Home | Host & Clusters, and select an ESXi host. In the center pane of the selected ESXi host, select the Configure tab, expand the System section, and select Advanced System Settings. The syslog server settings are specified under the Syslog.global.logHost attribute. For a faster search, use the filter in the upper-right menu. 2. To specify an external syslog server, use the Edit button and input the external syslog server with the format ://:-for example, udp://log-01a.corp.local:514. Repeat the steps for all hosts with NSX DFW installed.

[ 469 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

To configure ESXi hosts to log to multiple syslog servers, use the vSphere host profile, PowerCLI, or other automation tools. Some syslog servers integrate with vSphere and can automate the ESXi host syslog server configuration. For example, vRealize Log Insight can connect to the vCenter Server system and configure the syslog log destination automatically. 3. A flow hitting a DFW rule will only appear in the log if the rule is set to Log. Verify that your desired DFW rules have their Log flag set to Log:

3. The Log flag can be changed by editing the action of the DFW rule, as shown in the following screenshot:

[ 470 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

Viewing the NSX DFW log from the ESXi host console As mentioned earlier, DFW logs are logged in a dedicated file located on the ESXi host. The DFW log filename is dfwpktlogs.log , and is located under the /var/log directory. Log in to an ESXi host console through SSH. To view the log, use a Linux command such as more, cat, or tail against dfwpktlogs.log in the /var/log directory:

If you don't see any DFW packet logs, verify that the log settings on the DFW rule are set to Log. Otherwise, there might be no virtual machines hitting the particular DFW rule in that ESXi host.

How it works... For the DFW syslog to be active, the Log settings need to be set to Log on a per-rule basis. Starting from NSX 6.1, NSX DFW packet log messages are logged in a dedicated file in /var/log/dfwpktlogs.log on each ESXi host. The VSFWD userworld logs and VSIP kernel module logs are logged in separate files- /var/log/vsfwd.log and /var/log/vmkernel.log respectively. Sessions are logged at the beginning and at termination for both layer- 2 and layer-3 flows. The following is a sample of the DFW packet log format:

[ 471 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

For more information on log file entries and the possible values, refer to the NSX 6.3 logging and system events section and the firewall logs section at https:/​/​docs.​vmware.​com/​en/ VMware-​NSX-​for-​vSphere/​6.​3/​nsx_​63_​logging_​and_​system_​events.​pdf.

Configuring vRealize Log Insight for NSX In this recipe, we will configure vRealize Log Insight to ingest and provide meaningful analysis of NSX log data. This will be in the form of predefined Log Insight dashboards and via structured query data for troubleshooting purposes.

Getting ready You will need to have the following access and configurations present before proceeding with this recipe: vRealize Log Insight has been deployed. For step-by-step instructions on how to deploy vRealize Log Insight, watch the YouTube video at https:/​/​www.​youtube. com/​watch?​v=​Lg03i_​pGtdo. If your vRealize Log Insight is not connected to the internet, you will need to manually download the VMware NSX for vSphere .vlcp content pack file and import it to the vRealize. The VMware NSX for the vSphere .vlcp content pack file can be downloaded from the VMware Solution Exchange Marketplace (https:/​/ marketplace.​vmware.​com/​vsx/​solutions/​nsx-​for-​vsphere-​contentpack-​v3).

You should also have login credentials to the vRealize Log Insight UI to configure the NSX integration.

How to do it... This recipe covers the following topics: Installing VMware NSX for the vSphere content pack Navigating the NSX content pack dashboards

[ 472 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

Filtering DFW rules from the interactive analysis menu Adding a custom chart to the dashboard

Installing VMware NSX for the vSphere Content Pack vRealize Log Insight does not come preinstalled with the NSX content pack. You will need to download and import the NSX content pack or install it from the content pack marketplace if your vRealize Log Insight appliance has access to the internet. Perform the following steps to install the NSX content pack on vRealize Log Insight: 1. Open up a browser and log in to the FQDN or IP address of your vRealize Log Insight appliance at https://. On the top right, click on the drop-down menu icon and select Content Packs. 2. If vRealize Log Insight is connected to the internet, click on Marketplace under Content Pack Marketplace in the left pane. Locate and click on the VMware NSX-vSphere content pack. Accept the License Agreement popup and click on Install:

[ 473 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

3. If the vRealize Log Insight appliance is not connected to the internet, import the content pack file manually using the +IMPORT CONTENT PACK link on the bottom left. Browse and locate the appropriate content pack file-in this example, this is VMware - NSX-vSphere v3.7.vlcp and click on IMPORT. 4. Review the setup instructions and make sure that you forward all logs from ESXi hosts, NSX Manager, NSX controllers, and NSX Edges to the vRealize Log Insight server, and then click on OK. The steps on how to configure each NSX component's syslog are covered in the previous recipes. 5. After installation, the VMware - NSX-vSphere content pack will be listed under Installed Content Packs and will show the available dashboards or widgets.

Navigating the NSX Content Pack Dashboards Once the NSX content pack is installed, a set of pre-created dashboards and widgets will be listed under the VMware - NSX-vSphere dashboard. Make sure that all the NSX components have their logs forwarded to the vRealize Log Insight appliance so that the charts in the dashboard can display meaningful data: 1. To see what reports or dashboards are provided by the VMware - NSX-vSphere content pack, click on the Dashboards menu on the top bar. Expand the VMware - NSX-vSphere link under Content Pack Dashboards and select one of the available dashboards- for example, select the NSX-vSphere - Overview to view the main dashboard of the NSX overview:

[ 474 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

2. To see other available dashboards, select any dashboard under the VMware NSX-vSphere link- for example, Distributed Firewall - Overview.

Filtering DFW rules from the interactive analytics menu The vRealize Log Insight interactive analytics feature is useful to analyze and filter DFW rules. In this example, we will create a DFW rule, set it to log, and view it on the vRealize Log Insight interactive analytics: 1. Log in to the vSphere Web Client, create a DFW rule, and enable logging on that rule. In this example, we created a DFW rule to block ICMP from the finweb-01a VM to the hr-web-01a VM:

[ 475 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

2. On the DFW Rule action, we will also put a ICMP_BLOCK_TAG tag, so check whether this tag can be viewed in the interactive analysis menu:

3. Generate traffic that matches against the newly created rule; in this example, ping from fin-web-01a to hr-web-01a.

[ 476 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

4. Log in to vRealize Log Insight and select the Distributed Firewall - Overview dashboard. Change the time to a custom value or to the last 5 minutes of data, in this example. Optionally, you can input additional filters such as the hostname, a firewall action, or ruleid, if required. In this example, we will use interactive analytics to filter based on a value from the firewall actions graph. Right-click on the graph and select Interactive Analytics:

[ 477 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

5. You will be redirected to the Interactive Analytics menu with all the filters prepopulated:

Charts from interactive analysis can also be added to the custom dashboard.

[ 478 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

How it works... The vRealize Log Insight content pack for VMware NSX provides powerful operational reporting, and creates alerts for all sources of log data within NSX. The content pack has been designed to provide out-of-the-box capabilities to help NSX administrators understand configuration changes and events in their NSX environment. Once the content pack is deployed onto vRealize Log Insight, and when it receives events from one of the many NSX components, it will automatically categorize that information and provide it in dashboard form for easy consumption.

Enabling NSX Flow Monitoring This recipe will cover how to enable Flow Monitoring and export the flow to an external IPFIX collector.

Getting ready You will need to have the following access and configurations present before proceeding with this recipe: NSX Manager deployed vSphere hosts prepared for NSX Access to the vSphere Web Client An IPFIX collector, such as Plixer Scrutinizer, should be available

How to do it... To use Flow Monitoring, we need to first enable it and optionally export the flows to an external IPFIX collector.

[ 479 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

Enabling Flow Monitoring collection Flow Monitoring collection is disabled by default. The following steps will show you how to enable and filter the Flow Monitoring collection: 1. Log in to the vSphere Web Client UI and navigate to Home | Networking & Security | Flow Monitoring. In the center pane, select Configuration and click on the Enable button next to Global Flow Collection Status. 2. Once the Global Flow Collection Status is Enabled, the Flow Exclusion settings will appear at the bottom; select it if you would like to exclude specific flows from the Flow Monitoring collection. In this example, we will exclude layer 2 flows by selecting Collect Layer2 Flows, then selecting No under the Detail Collection Policy, and finally clicking Save once we are finished:

[ 480 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

Enabling and exporting Flow Monitoring collection NSX Flow Monitoring supports IPFIX, and flow collection can be forwarded to an external IPFIX collector for longer data retention and centralized flow collection. 1. From the Flow Monitoring configuration menu, select the IPFix menu. IPFIX is disabled by default-click on the Edit button to enable IPFIX. In the new dialog box, tick the Enable IPFix Configuration checkbox, input the Observation DomainID, input the Active Flow Export Timeout, and click on OK once you are finished:

2. At least one collector IP must be configured for IPFIX to work. To add the collector's IP, click on the plus icon under the Collector IPs section. In the new dialog box, input the Collector IP and the UDP Port. You can add more collectors if required, as multiple IPv4 and IPv6 collectors are supported. Click on OK once you are finished:

[ 481 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

How it works... The NSX Manager database is designed to store up to 20,00,000 flow records over a period of 15 days. In a large-scale environment, to avoid hitting the flow records limit, you can exclude specific flows from the exclusion settings, such as layer-2 flows, specific sources, specific destinations, or specific ports. To retain flow data records for longer than 15 days, you would need the flow to be exported to an external IPFIX collector. From NSX 6.2, Flow Monitoring and IPFIX features are decoupled, so you can enable IPFIX independently of Flow Monitoring on NSX.

IPFIX or Internet Protocol Flow Information eXport is an IETF protocol that was created based on the need for a universal standard of export for internet protocol flow information from routers, probes, and other devices. The IPFIX standard defines how IP flow information is to be formatted and transferred from an exporter to a collector, which is documented in RFC 7011 through RFC 7015 and RFC 5103. IPFIX flows that are tracked by the DFW include flow creation, flow denial, flow update, and flow teardown. The IPFIX flow collection is performed by the vsfwd process. We can see from the following vsfwd.log that IPFIX is configured and stored in /etc/vmware/vsfwd/vsip_ipfix_config.dat:

[ 482 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

To check the IPFIX configuration of an ESXi host, run the vsipioctl loadipfixconfig command from the ESXi console:

The DomainID observation uniquely identifies the NSX DFW exporter to the IPFIX collector. The Active Flow Export Timeout determines the time after which active flows will be exported to the collector in minutes- the default is five minutes. The ESXi internal firewall should also allow outgoing UDP connections used for IPFIX after IPFIX is enabled. This can be verified from ESXi CLI using the esxcli network firewall ruleset rule list command:

Alternatively, you can view it by navigating to vSphere Web Client | ESXi host | Configure | System | Security Profile.

[ 483 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

Once we have Flow Monitoring enabled, we can use View Traffic Flows from the Flow Monitoring features, even in a live flow:

Using Application Rule Manager In this recipe, we will use ARM (Application Rule Manager) in NSX 6.3 to collect flows from multiple virtual machines, analyze them, and create a firewall rules based on the collected flows.

Getting ready You will need to have the following access and configurations present before proceeding with this recipe: Access to the vSphere Web Client NSX administrator or enterprise administrator access

[ 484 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

How to do it... Let's start a monitoring session from ARM to collect traffic flows from a three-tier application virtual machine: 1. Log in to the vSphere Web Client UI and navigate to Home | Networking & Security | Flow Monitoring. In the center pane, select the Application Rule Manager tab and click on the Start New Session button on the right. Type the session name and select the object type that you want to monitor with ARM. This can be a virtual machine:

[ 485 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

2. Wait for few minutes. If there are traffic flows on the monitored objects, ARM will detect how many sources and flows are collected. You can click on the Flows link to see when the flow collection started and how long the collection has been running. Review the tables under the View Flows tab and click on the Stop link once you are happy with the flow data:

[ 486 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

3. After stopping the flow collection, click on the Analyze link. Wait until the analysis is completed. ARM will remove any duplicate flows and attempt to match IP addresses and services with vSphere and NSX grouping. If required, edit the identified flow's source or destination and replace it with an NSX grouping objects such as security group, IPSet, or even replace it with any object you like:

[ 487 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

4. Once you are happy with the analyzed flows, you can create a firewall rule based on the approved flows. Select a flow, click on Actions, and then select Create Firewall Rule:

5. In the New Firewall Rule dialog box, review the details, edit the rule, and then click on OK:

[ 488 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

6. Repeat the firewall rule creation and navigate to the Firewall rules tab. Review the rules, adjust the priority or edit if required, and click on the Published link once you are finished. 7. ARM will ask for a Section name for the new rule to be published, and will insert this name before the selected section. Click on OK to continue to publish the firewall rules.

[ 489 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

8. Navigate to the Networking & Security | Firewall table menu and review the new ARM-generated rules that are published:

How it works... The application rule manager collects information from selected virtual machines for a given period. The resultant set of flows is then analyzed by the NSX Manager, which provides you with a list of recommended firewall rules for insertion in the distributed firewall based on the flow information it gathered. The following configuration parameters should be noted when working with the application rule manager: Multiple ARM sessions can be configured up to a maximum of five ARM can monitor up to 30 virtual machines in one session A session can last a maximum of seven days

There's more... In NSX 6.4, ARM can create automatically recommend DFW rules and security groups based on flow data. For further information on NSX 6.4 ARM enhancements, see the demo video on YouTube, at https:/​/​www.​youtube.​com/​watch?​v=​r3IKNkt5mi8.

[ 490 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

Using NSX Endpoint Monitoring In this recipe, we will configure NSX endpoint monitoring for our selected and supported virtual machines.

Getting ready You will need to have the following access and configurations present before proceeding with this recipe: Access to the vSphere Web Client. NSX administrator or enterprise administrator access. Flow Monitoring should be enabled - see the previous recipe on how to enable Flow Monitoring in NSX. The NSX enterprise license must be applied. The guest VM should be using one of the supported guest operating systems—Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows 10, Windows 2012, or Windows 2016. Endpoint monitoring currently does not support Linux OS.

VMware tools must be installed in the guest VM. A guest introspection service VM must be deployed in the cluster where the guest VM resides. A security group must be created as the endpoint monitoring will monitor a particular security group. A guest VM must be added to the security group that will be monitored by endpoint monitoring. The security group must have 20 or fewer VMs.

[ 491 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

How to do it... This recipe is divided into two parts. The first part looks at how to verify all the prerequisites to run endpoint monitoring and the second part looks at how to use the endpoint monitoring feature.

Verifying the prerequisites for endpoint monitoring Before we can start endpoint monitoring data collection, we need to make sure all the prerequisites listed in the Getting ready section have been satisfied: 1. Verify that the Guest Introspection Services is installed, up, and running by navigating to vSphere Web Client | Home | Networking & Security | Installation | Service Deployments. Refer to Chapter 6, Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard, for information on how to deploy Guest Introspection Services:

2. Verify that VMware Tools is installed in the guest VM and that the guest VM is part of a security group membership. In this example, our VM is a Windows 10 desktop with the VM name win-10-01a, which is a member of the security group called SG-Desktop:

[ 492 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

3. Ensure that the VMCI NSX File Introspection driver is installed as part of VMware tools. The full options of the VMware Tools installation will include the NSX VMCI driver. 4. Ensure that the security group that you would like to monitor is part of the firewall rule object. In this example, we have a dedicated rule to allow the Security Group SG-Desktop to any:

[ 493 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

Starting endpoint monitoring data collection We will now start endpoint monitoring data collection for an existing security group called SG-Desktop: 1. Log in to the vSphere Web Client and navigate to Home | Networking & Security | Endpoint Monitoring. In the center pane, click on the Start Collecting Data link on the right or in the center:

2. In the new dialog box, select your desired security group, set the Data collection to ON, and click on OK.

[ 494 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

3. The endpoint monitoring section is not automatically refreshed. Refresh the vSphere Web Client to see the data collection progress. Once the endpoint monitoring collection discovers any flows, the Summary page should show the discovered VMs and processes with a summary of the flows at the bottom:

[ 495 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

4. Click on the VM Flows menu tab to see detailed flow information or on the Process Flows tab to see all the processes that are captured on the endpoints:

[ 496 ]

||||||||||||||||||||

||||||||||||||||||||

Managing and Monitoring VMware NSX Platform

Chapter 11

How it works... Endpoint Monitoring can discover traffic flows that are generated by a guest VM and map it to the processes that the Guest VM is using based on Security Group Membership. After the flow data is collected, the Endpoint Monitoring will provide a list of the following: Processes running on each VM VM-to- VM communication Process-to-process communication Visual representation of intra-and-inter VM and security group communication There can be a maximum of 20 VMs in a monitored security group. The endpoint monitoring database can store a maximum of 5 million rows of flow records, after which it starts pruning and deleting completed sessions, starting from the oldest session. If a session is still running, it might be subject to partial flow data loss. The space to store the data collection flow is shared with the Flow Monitoring data.

[ 497 ]

||||||||||||||||||||

||||||||||||||||||||

12 Leveraging the VMware NSX REST API for Management and Automation In this chapter, you will learn how to leverage the VMware NSX REST API, and we will look at the following recipes: Using the REST API with the Postman REST client Using the REST API with cURL Using the REST API with PowerShell Using the REST API with Python Using the vRealize Orchestrator plugin for NSX

Introduction VMware NSX has a northbound REST API that is publicly accessible and documented. The NSX REST API runs on top of NSX Manager and is based on REST concepts. The other NSX APIs are EPSec, API, and NetX for high-touch partners that are accessible via the VMware developer program. There are a few NSX operations that cannot be performed through GUI and are only accessible via the REST API. This NSX REST API can be consumed directly or indirectly from: Cloud Management Tools, such as VMware, vRealize Automation, VMware vCloud Director, and OpenStack DevOps, configuration management, and orchestration tools, such as VMware vRealize Orchestrator, Ansible, Puppet, and Chef

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

Programming languages, such as Python, Ruby, and Powershell, or a CLI tool, such as cURL:

NSX only accepts HTTPS over TCP/443 and does not accept HTTP due to it not being an encrypted protocol; both FQDN and the IP address of the NSX Manager virtual appliance can be used to make REST API requests. The following is the typical URI structure of the NSX REST API format:

The structure and the URI parameters are similar to the vShield/vCNS REST API structure, as some of the URIs are backward-compatible.

The /api/2.0/ is the base API path, or version, depending on which function, features, or object you want to access. The last part, from vdn to virtualwires, is the path to the resource; for example, vdn/scopes is for the transport zone, and the vdnscope-1 is a Managed Object Reference (MoRef) URI parameter, which represents a transport zone.

[ 499 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

The NSX REST API can return a long list of XML response content, and it may be hard to read or even truncate. To view a specific number of objects, for example, the first 10 logical switches, use startindex and pagesize parameters, for example: https://nsxmgr-01a.corp.local/api/2.0/vdn/scopes/vdnscope -1/virtualwires?startindex=0&pagesize=10. To send a REST API request, NSX enforces authentication and, at the time of writing this book, only Basic Authentication is supported. To pass data for an HTTPS POST or HTTP PUT request, NSX accepts XML payload. Therefore, a Content-Type key with the application/xml value and the basic authentication details must be added to the request header before making the request. Certain requests require additional headers; for example, firewall configuration changes require the If-Match header.

The following table shows some HTTP Verbs that are accepted by the NSX REST API: HTTP Verbs Usage

CRUD

POST

Create an NSX object (for example, logical switch)

Create

GET

Retrieve data about a single NSX object or multiple objects Read

PUT

Modify the properties of an already existing NSX object

Update

DELETE

Remove an NSX object

Delete

In addition to the available REST methods, it is also important to understand the common REST API status codes that may be returned. The following list is not exhaustive: Status code

HTTP Verb

Description

200 - OK

GET

The request was successful and the response body contains the requested information.

201 - OK

POST/PUT

The request was successful and the requested resource was created or updated.

[ 500 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

202 - Accepted

The request has been accepted for further processing and will be completed later. You DELETE/POST/PUT should receive a task ID that you can use to check on the status of the request.

204 - Accepted

DELETE

The requested resource has been deleted.

400 - Bad Request

All

The request was invalid or cannot be served.

401 - Unauthorized All

The authentication credentials are either missing or incorrect.

404 - Not Found

The URI of the request is invalid or the requested resource does not exist.

All

For further information on all REST Status codes, visit https:/​/​www.​w3.​org/​Protocols/ rfc2616/​rfc2616-​sec10.​html. The recipes covered in this chapter will show you how to perform a REST API request using various methods from REST Client, cURL, PowerShell, Python, and vRealize Orchestrator. Each of the methods will have two examples: In the first example, we will use the HTTP GET REST API to get information about the default built-in admin user. The URI to get user information is /api/2.0/services/usermgmt/user/, just replace the with admin. This REST API call can be used on a freshly deployed NSX Manager virtual appliance to test a simple REST API call against NSX. In the second example, we will create a logical switch on an existing transport zone. The URI parameters for this will be /api/2.0/vdn/scopes//virtualwires. This REST API call will create a logical switch based on input from the XML payload in the body request. The will be a MoRef of a transport zone (or transport zone ID), for example, vdnscope-1. For this example, you would need to prepare the vSphere cluster for VXLAN, create a transport zone, and at vSphere cluster(s) to the transport zone.

[ 501 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

When requesting certain REST API calls, such as POST or PUT, it typically asks for data or a payload to be included as part of the body request:

NSX-v accepts the JSON payload starting with NSX 6.4. Using JSON prior to NSX 6.4 is not officially supported.

The complete list of the NSX REST API URI parameters and payload formats is available in the NSX PDF documentation on the NSX for vSphere API Guide: https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.3/nsx_63_api.pdf. Postman Collections allow you to group, export, and import APIs. Most of the NSX REST API call specifications are available in the VMware GitHub (https:/​/​github.​com/​vmware/​nsxraml), which can be imported into Postman.

[ 502 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

For example, the URI parameters and details to create a logical switch can be found in the NSX for vSphere API Guide under the Working With Logical Switches in a Specific Transport Zone section:

For the POST method, the REST API documentation describes how the payload format should look, as well as the required and optional parameters in the bottom section of a certain task:

[ 503 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

vCenter-Managed Object Reference ID (MoRef ID) The REST API, and other API methods in VMware, use the vCenter MoRef ID in the parameters, such as in URI or query parameters. MoRef ID is a unique ID inside vCenter for every object. The MoRef ID naming starts with a prefix stating the object type followed by a hyphen and a number, for example, vm-197, host-29, domain-c26. Every object has its own MoRef address: https:///mob/?moid=.

[ 504 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

There are various ways to get the MoRef ID, such as through the Managed Object browser, PowerCLI, or NSX Central CLI, as shown here:

For more information on MoRef and how to retrieve the MoRef ID, check out the following links: Finding MoRef IDs for NSX API Calls: https://vswitchzero.com/2017/08/16/finding-moref-ids-for-nsx-api-calls

How to (quickly) match a MoRef ID to a name in VMware vSphere: http://www.danilochiavari.com/2014/03/28/how-to-quickly-match-a-morefid-to-a-name-in-vmware-vsphere/

vSphere MoRef ID Finder Script: https://www.virtuallyghetto.com/2011/11/vsphere-moref-managed-object-r eference.html

[ 505 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

ManagedObjectReference versus ManagedObject: http://www.doublecloud.org/2011/06/managedobjectreference-vs-managedob ject/

VMware KB 1017126—Looking up MoRef in vCenter Server: https://kb.vmware.com/kb/1017126

Using the REST API with the Postman REST client In this recipe, we will use the Postman REST client to perform a REST API call to NSX. The Postman REST client can be downloaded here: https://www.getpostman.com/. Other alternative REST clients include the RESTClient Firefox add-on: https://addons.mozilla.org/en-US/firefox/addon/restclient/.

Getting ready To use the NSX REST API, you must understand the general RESTful workflow, and then install and configure a REST client. The NSX Manager uses TCP port 443 for REST API requests, so you must verify that the ports are opened between the REST client and the NSX Manager. In addition to this, you must either use a trusted certificate or accept the selfsigned certificate when making a REST API call to the NSX Manager.

How to do it... This recipe is divided into two parts of REST API requests using the Postman REST API client: retrieving a configuration or information using HTTP GET, and creating a logical switch using HTTP POST.

Requesting the HTTP GET REST API via Postman The following steps will show you how to retrieve the NSX built-in admin API using REST API via Postman REST API client: 1. The REST API call will be based on HTTPS; if you need to ignore client SSL certificates verification or allow insecure server connections, set the SSL certificate verification to OFF in the Postman General SETTINGS menu.

[ 506 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

2. To configure the authorization parameters, select the Authorization tab, select Basic Auth from the TYPE drop-down menu, and input the Username and Password:

3. The authorization will be part of the HTTP header; to see the actual authorization header, click the Preview Request button and select the Headers tab. 4. To configure the content-type type header, type Content-Type in the Key column and application/xml in the Value on a new row. You should now have two header keys, Authorization (a temporary header if you click the Preview Request button) and Content-Type:

5. Select the HTTP Method/Verb from the drop-down menu. In this example, we will use HTTP GET and for the URL, which gives us https://nsxmgr-01a.corp.local/api/2.0/services/usermgmt/user/ admin. Review the settings and click the blue Send button:

[ 507 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

6. The results will appear under the Body section in XML format and the HTTP response status code will appear on the right side. In this example, the HTTP response status code is 200 OK:

Requesting the HTTP POST REST API via Postman The following steps will show you how to create a logical switch using the HTTP POST REST API via the Postman REST API client: 1. To perform an HTTP POST request, the HTTP Verb type need to be changed to GET and the URL is https://nsxmgr-01a.corp.local/api/2.0/vdn/scopes/vdnscope-1/v irtualwires, where the vdnscope-1 is the MoRef ID of a transport zone:

[ 508 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

2. Include the following XML payload data as part of the HTTP POST body:

Postman-Logical-Switch Logical Switch created from Postman Postman Tenant UNICAST_MODE false

3. To include the XML payload, go to the Body tab and copy the XML payload under the raw form. Click the blue Send button to send the HTTP POST request:

4. Upon successful request, the Status code will return 201 created and the Body content will return the created Virtual ID in this virtualwire-4 example:

5. Verify in the vSphere Web Client that the logical switch with the Virtual Wire ID matching the output from the Postman virtualwire-4 output is created. In our example, the logical switch name is Postman-Logical-Switch:

[ 509 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

How it works... In this recipe, we show you how to perform an HTTP GET and HTTP POST REST API call using the Postman REST Client. The API response consists of Body, Headers, and Status codes. In Postman, the Body and Headers are in different sub-menu tabs while the Status code is displayed next to these tabs:

[ 510 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

The response content is displayed in the bottom pane in the Pretty view by default. The pretty mode displays XML or JSON content in a cleaner format without the need of tools, such as formatter or beautifier. The formatter and beautifier tools offer code reformatting, making it easier to read by creating proper indentation and often validating the code.

Using the REST API with cURL The NSX REST API can also be consumed via command-line tools, such as cURL (c for Client). cURL is a free and open source software that can be downloaded from https://curl.haxx.se/. Most Linux- or Unix-based operating systems come pre-installed with cuRL, such as the vCenter Server Appliance, however Microsoft Windows typically requires it to be manually installed.

Getting ready You should be logged in to a guest operating system with cURL installed. In this example, we will use cURL from the Git command prompt in a Windows workstation.

How to do it... This recipe is divided into two parts of REST API requests using cURL: retrieving a configuration or information, and creating a logical switch.

Requesting the HTTP GET REST API via cURL In this example, we will perform an HTTP GET REST API request via cURL script: 1. To check whether cURL is available in the operating system, use the curl --version command.

[ 511 ]

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

2. Run the following cURL script: curl -k -X GET -H "Accept: application/xml" -H "Content-Type: application/xml" -u admin:VMware1! 'https://nsxmgr-01a.corp.local/api/2.0/services/usermgmt/user/a dmin'

Here is an example output of the preceding command:

The credentials can also be input as a header, similar to Postman, with the following command: curl -k -X GET -H "Accept: application/xml" -H "Content-Type: application/xml" -H "Authorization: Basic YWRtaW46Vk13YXJlMSE=" 'https://nsxmgr-01a.corp.local/api/2.0/services/usermgmt/user/admin'

Requesting the HTTP POST REST API via cURL In this example, we will create a logical switch using the HTTP POST REST API request via cURL script: 1. Run the following cURL script from a command prompt: curl -k -X POST https://nsxmgr-01a.corp.local/api/2.0/vdn/scopes/vdnscope-1/vir tualwires -H "Accept: application/xml" -H "Content-Type: application/xml" -u admin:VMware1! -d

[ 512 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

"cURL-LogicalSwitchLogical Switch created from cURLcURL TenantUNICAST_MODEfalse"

2. The cURL script will return a Virtual Wire ID in this virtualwire-8 example:

3. Verify in the vSphere Web Client that the logical switch with Virtual Wire ID matching the output from the virtualwire-8 cURL script is created. In our example, the logical switch Name is cURL-Logical-Switch:

[ 513 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

How it works... In this example, we used cURL to perform HTTP GET and HTTP POST requests. cURL is available in most operating systems. cURL is executed from a command-line prompt, and the curl -V or curl --version command can be used to check which version of cURL is running in the operating system. The simplest command syntax to use with cURL is basically curl , for example, curl https://nsxmgr-01a.corp.local/. Since we need to use specific HTTP methods, such as adding custom headers and credentials to the request, we need to add cURLspecific options before the URL, as the following command snippet shows: curl -k -X GET -H "Accept: application/xml" -H "Content-Type: application/xml" -u admin:VMware1! 'https://nsxmgr-01a.corp.local/api/2.0/services/usermgmt/user/admin'

The -k option is used to ignore client SSL certificates verification or allow insecure server connections when using HTTPS. The -X is to specify the HTTP request method, such as -X GET for an HTTP GET request or -X POST for an HTTP POST request. To add a custom header, we used the -H "" option, such as -H "Accept: application/xml" and -H "Content-Type: application/xml". To specify credentials, use the -u option or the header option. We also put the URL as the last parameters. To include an XML payload as part of an HTTP POST request, use the -d switch options, as per the following example: curl -k -X POST https://nsxmgr-01a.corp.local/api/2.0/vdn/scopes/vdnscope-1/vir tualwires -H "Accept: application/xml" -H "Content-Type: application/xml" -u admin:VMware1! -d "cURL-LogicalSwitchLogical Switch created from cURLcURL TenantUNICAST_MODEfalse

[ 514 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

For more information on how to use cURL, see the following links: Everything cURL free book: https://www.gitbook.com/book/bagder/everything-curl/details cURL tutorial (manual): https:/​/​curl.​haxx.​se/​docs/​manual.​html cURL man page: https://curl.haxx.se/docs/manpage.html

Generating a cURL script from Postman Postman has a feature to generate snippets of code in various languages, including cURL. To generate a cURL code snippet, click the Code link under the blue Send button:

This will open up the GENERATE CODE SNIPPETS dialog box. Select cURL from the drop-down menu on the left and Postman will generate the cURL code:

There's more... By default, Python will print XML format in one line; this is also called minification. To reformat the XML to a prettier format, you can write a code to beautify the XML format, either by importing a library that can beautify the XML format or using an online XML beautifier. The following example shows an XML beautifier from https://codebeautify.org/xmlviewer:

[ 515 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

Using the REST API with PowerShell PowerShell has a built-in Invoke-WebRequest cmdlet that can be used to send HTTP and HTTPS requests to a web service. In this recipe, we will demonstrate how to leverage the NSX REST API through PowerShell using the Invoke-WebRequest cmdlet.

Getting ready You should have a workstation with Windows PowerShell or PowerShell Core installed.

How to do it... This recipe is divided into two parts of REST API requests using PowerShell: retrieving a configuration or information using HTTP GET, and creating a logical switch using HTTP POST.

[ 516 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

Requesting the HTTP GET REST API via PowerShell In this example, we will perform an HTTP GET REST API request via PowerShell: 1. Open a text editor, input the following code, and save it into a .ps1 extension, for example NSX-PowerShellGET.ps1: # NSX Variables $NSXUsername = "admin" $NSXPassword = "VMware1!" $NSXManager = "https://nsxmgr-01a.corp.local" $NSXURI = "/api/2.0/services/usermgmt/user/admin" # NSX Authorization Header $NSXAuth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.G etBytes($NSXUsername + ":" + $NSXPassword)) $NSXAuthHeader = @{"Authorization"="Basic $NSXAuth"} # Add code to allow untrusted SSL certs - taken from https://d-fens.ch/2013/12/20/nobrainer-ssl-connection-error-whe n-using-powershell/ Add-Type @" using System; using System.Net; using System.Net.Security; using System.Security.Cryptography.X509Certificates; public class ServerCertificateValidationCallback { public static void Ignore() { ServicePointManager.ServerCertificateValidationCallback += delegate ( Object obj, X509Certificate certificate, X509Chain chain, SslPolicyErrors errors ) { return true; }; } } "@ [ServerCertificateValidationCallback]::Ignore();

[ 517 ]

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

# REST API Call via Invoke-WebRequest cmdlet $response = Invoke-WebRequest -Uri "$NSXManager$NSXURI" Method:Get -Headers $NSXAuthHeader -ContentType "application/xml" -ErrorAction:Stop -TimeoutSec 180 Write-Host "$response"

2. Run the .ps1 script from the Windows PowerShell prompt:

You can also copy the code and paste it into Windows PowerShell console to see what is happening in the background.

Requesting the HTTP POST REST API via PowerShell In this example, we will create a logical switch using the HTTP POST REST API request via PowerShell: 1. For HTTP POST, change the -Method to Post and include an XML payload using the -Body option, as follows: # NSX Variables $NSXUsername = "admin" $NSXPassword = "VMware1!" $NSXManager = "https://nsxmgr-01a.corp.local" $NSXURI = "/api/2.0/vdn/scopes/vdnscope-1/virtualwires" # NSX Authorization Header $NSXAuth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.G etBytes($NSXUsername + ":" + $NSXPassword)) $NSXAuthHeader = @{"Authorization"="Basic $NSXAuth"} # NSX XML Payload [xml]$XMLBody = " PowerShell-Logical-Switch Logical Switch created from PowerShell PowerShell Tenant UNICAST_MODE

[ 518 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

false " # Add code to allow untrusted SSL certs - taken from https://d-fens.ch/2013/12/20/nobrainer-ssl-connection-error-whe n-using-powershell/ Add-Type @" using System; using System.Net; using System.Net.Security; using System.Security.Cryptography.X509Certificates; public class ServerCertificateValidationCallback { public static void Ignore() { ServicePointManager.ServerCertificateValidationCallback += delegate ( Object obj, X509Certificate certificate, X509Chain chain, SslPolicyErrors errors ) { return true; }; } } "@ [ServerCertificateValidationCallback]::Ignore(); # REST API Call via Invoke-WebRequest cmdlet $response = Invoke-WebRequest -Uri "$NSXManager$NSXURI" Method:Post -Body $XMLBody -Headers $NSXAuthHeader -ContentType "application/xml" -ErrorAction:Stop -TimeoutSec 180 Write-Host "$response"

The following is a screenshot of the codes executed from a Windows PowerShell session with the virtualwire-3 response content:

[ 519 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

2. Verify in the vSphere Web Client that the logical switch with Virtual Wire ID matching the output from the virtualwire-3 PowerShell code is created. In our example, the logical switch Name is PowerShell-Logical-Switch:

[ 520 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

How it works... In this example, we used the built-in Invoke-WebRequest cmdlet to perform HTTP GET and HTTP POST requests from PowerShell. PowerShell is available on the Windows platform; for non-Windows platforms, such as macOS and Linux, you can use PowerShell Core: https://aka.ms/getps6-linux. In this example, we store all the required values, such as the FQDN or IP of NSX Manager, URL, headers, and credentials, in variables so they can be reused: # NSX Variables $NSXUsername = "admin" $NSXPassword = "VMware1!" $NSXManager = "https://nsxmgr-01a.corp.local" $NSXURI = "/api/2.0/services/usermgmt/user/admin" # NSX Authorization Header $NSXAuth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($NSX Username + ":" + $NSXPassword)) $NSXAuthHeader = @{"Authorization"="Basic $NSXAuth"}

The authentication part will need to be input as an HTTP header option, so in this example, we convert the authentication credentials and use a new variable for the authentication header called $NSXAuthHeader. There are multiple ways to ignore client SSL certificates verification or allow insecure server connections. In this example, we will use codes spinet taken from the https:/​/​d-​fens.​ch/ 2013/​12/​20/​nobrainer-​ssl-​connection-​error-​when-​using-​powershell/​: # Add code to allow untrusted SSL certs - taken from https://d-fens.ch/2013/12/20/nobrainer-ssl-connection-error-when-using-powe rshell/ Add-Type @" using System; using System.Net; using System.Net.Security; using System.Security.Cryptography.X509Certificates; public class ServerCertificateValidationCallback { public static void Ignore() { ServicePointManager.ServerCertificateValidationCallback += delegate ( Object obj,

[ 521 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

X509Certificate certificate, X509Chain chain, SslPolicyErrors errors ) { return true; }; } } "@ [ServerCertificateValidationCallback]::Ignore();

Once all the variables are set, we can make an HTTP GET request using the InvokeWebRequest cmdlet with the -Method option set to Get, as follows: # REST API Call via Invoke-WebRequest cmdlet $response = Invoke-WebRequest -Uri "$NSXManager$NSXURI" -Method:Get Headers $NSXAuthHeader -ContentType "application/xml" -ErrorAction:Stop TimeoutSec 180 Write-Host "$response"

The -ErrorAction parameter allows you to specify which action to take if a command fails, such as Stop, Continue, SilentlyContinue, Ignore, or Inquire, and in this example, we use Stop. We also set a timeout value on how long the HTTP request can be pending, using the -ErrorAction option and we used 180 seconds in this example. For HTTP POST, we need to pass data in the HTTP POST and use XML as the payload. First, we store the payload on a variable called $XMLBody and typecast (https://en.wikipedia.org/wiki/Type_conversion) that variable to the [xml] type: # NSX XML Payload [xml]$XMLBody = " PowerShell-Logical-Switch Logical Switch created from PowerShell PowerShell Tenant UNICAST_MODE false "

Lastly, we include the payload or body of the XML content to the -Body parameter, as per following code: # REST API Call via Invoke-WebRequest cmdlet $response = Invoke-WebRequest -Uri "$NSXManager$NSXURI" -Method:Post -Body $XMLBody -Headers $NSXAuthHeader -ContentType "application/xml" ErrorAction:Stop -TimeoutSec 180

[ 522 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

Write-Host "$response"

For more information on how to make an HTTP request using the requests library, see https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility /invoke-webrequest.

There's more... There is an open source PowerShell module called PowerNSX that abstracts the VMware NSX for vSphere API to a set of easily used PowerShell functions. PowerNSX has over 280 cmdlets that focus on exposing Create, Read, Update, and Delete operations for all of the key NSX for vSphere functions. However, PowerNSX is not supported by VMware as it is open source and not developed as an official VMware product. PowerNSX is available on VMware's GitHub repository (https://github.com/vmware/powernsx) and the project wiki is located at https://powernsx.github.io. VMware Press also has a free guide or book that introduces PowerNSX called Automating NSX for vSphere with PowerNSX: https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/pr oducts/nsx/vmware-automating-vsphere-with-powernsx.pdf.

Using the REST API with Python Python is one of many programming languages that is widely used for automating networks. There is no built-in REST or HTTP client in Python, but Python allows importing libraries, functions, modules, or frameworks. One of the libraries that can be used to send HTTP REST API requests is the requests library—an Apache2 Licensed HTTP library written in Python. In this recipe, we will import and leverage the requests library to perform a REST API call to NSX in Python version 2.7.

[ 523 ]

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

Getting ready 1. Make sure you have Python and the requests library installed. Python comes pre-installed on many Linux/Unix operating systems. If you do not have Python installed, head over to https:/​/​www.​python.​org/​downloads/​ to obtain it. 2. Once Python has been confirmed as installed and available, you can then verify the installation of the Requests Python module. One way to install Requests is through pip using the pip install requests command.

How to do it... This recipe is divided into two parts of REST API requests using Python: retrieving a configuration or information using HTTP GET, and creating a logical switch using HTTP POST.

Requesting the HTTP GET REST API via Python In this example, we will perform an HTTP GET REST API request via Python: 1. Open a text editor, input the following code and save it into the .py extension, for example NSX-PythonGET.py: # Import Requests library import requests # NSX Variables nsxmanager = 'https://nsxmgr-01a.corp.local' nsxurl = '/api/2.0/services/usermgmt/user/admin' nsxheaders = {'Content-Type': 'application/xml'} nsxuser = 'admin' nsxpass = 'VMware1!' # REST API call using requests.get function from request library. Set verify to False to ignore SSL response = requests.get(nsxmanager + nsxurl, auth = (nsxuser, nsxpass), verify = False, headers = nsxheaders) # Print HTTP Response Code print (response) # Print XML Content print (response.text)

[ 524 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

2. Run the .py Python script from the command prompt:

You can also copy each line of code and paste it into the Python interpreter to see what is happening in the background. To use the Python interpreter, type python from the command prompt:

[ 525 ]

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

Requesting the HTTP POST REST API via Python In this example, we will create a logical switch using the HTTP POST REST API request via Python: 1. Open a text editor, input the following code and save it into the .py extension, for example NSX-PythonPOST.py: # Import Requests library import requests # NSX Variables nsxmanager = 'https://nsxmgr-01a.corp.local' nsxurl = '/api/2.0/vdn/scopes/vdnscope-1/virtualwires' nsxheaders = {'Content-Type': 'application/xml'} nsxuser = 'admin' nsxpass = 'VMware1!' nsxpayload = '''

Python-Logical-Switch Logical Switch created from Python Python Tenant UNICAST_MODE false

''' # REST API call using requests.get function from request library. Set verify to False to ignore SSL response = requests.post(nsxmanager + nsxurl, data = nsxpayload, auth = (nsxuser, nsxpass), verify = False, headers = nsxheaders) # Print HTTP Response Code print (response) # Print XML Content print (response.text)

[ 526 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

2. Run the saved code from a command prompt or a Python interpreter. The following is a screenshot of the Python script executed from the command prompt with the 201 response code and the virtualwire-9 response content:

3. Verify in the vSphere Web Client that the logical switch with the Virtual Wire ID matching the output from the virtualwire-2 Python code is created. In our example, the logical switch Name is Python-Logical-Switch:

How it works... In this example, we made HTTP GET and HTTP POST requests using functions from the Requests Python module. To use the functions, we import the module first by adding the import requests at the beginning of a code.

[ 527 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

The required values, such as the FQDN or IP of NSX Manager, URL, headers, and credentials, are stored in variables so they can be reused: nsxmanager = 'https://nsxmgr-01a.corp.local' nsxurl = '/api/2.0/services/usermgmt/user/admin' nsxheaders = {'Content-Type': 'application/xml'} nsxuser = 'admin' nsxpass = 'VMware1!'

For making an HTTP GET request, we used the request.get function, and for making an HTTP POST request, we used request.post imported from the requests library. The HTTP request is then stored on a variable called response as shown in the following code: response = requests.get(nsxmanager + nsxurl, auth = (nsxuser, nsxpass), verify = False, headers = nsxheaders)

To get the HTTP response code, such as 200 for OK, we use the print (response) command. To see the actual content of the response, we use the print (response.text) command. For HTTP POST, we need to pass payload data in the HTTP POST and XML using XML, as the payload. First, we store the payload on a variable called nsxpayload: nsxpayload = '''

Python-Logical-Switch Logical Switch created from Python Python Tenant UNICAST_MODE false

'''

We then include the payload or dictionary to the data argument: response = requests.post(nsxmanager + nsxurl, data = nsxpayload, auth = (nsxuser, nsxpass), verify = False, headers = nsxheaders)

In this recipe example, we performed the HTTP GET and HTTP POST requests using the requests.get and requests.post functions. For more information on how to make an HTTP request using the requests library, see http:/​/​docs.​python-​requests.​org/​en/ master/​user/​quickstart/​#make-​a-​request.

[ 528 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

There are some Python packages or modules for VMware NSX, such as the PyNSXv Python library for VMware NSX, that are also available on VMware's GitHub: https:/​/​github. com/​vmware/​pynsxv. Other Python packages are available on https://pypi.python.org/

There's more... Postman has a feature to generate snippets of code in various languages, including Python. To generate a Python code snippet, click the Code link under the blue Send button. This will open up the GENERATE CODE SNIPPETS dialog box. Select Python and the library, for example the requests library, from the drop-down menu on the left, and Postman will generate the Python code for you:

Using the vRealize Orchestrator plugin for NSX In this recipe, we will install the vRO plugin for the NSX plugin and run an NSX workflow from vRO.

[ 529 ]

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

Getting ready You should have a vRealize Orchestrator installed with the host settings and its authentication provider configured.

How to do it... This recipe is divided into several parts: checking the VMware Product Interoperability Matrix, downloading and installing the vRO plugin for NSX, and running an NSX-vRO workflow.

Checking the VMware Product Interoperability Matrices The first step is to check which version of vRO Plugin is compatible with the installed NSX: 1. Go to your web browser and navigate to the VMware Product Interoperability Matrices: http://www.vmware.com/go/interop 2. Select the Interoperability tab 3. Select NSX-vRO Plugin as the first Select a Solution 4. Select All Solutions as your second Add Platforms/Solution. 5. Verify that your NSX version and the NSX-vRO Plugin are listed on the compatibility matrix page.

Downloading the vRO plugin for NSX Once you know which vRO Plugin version to use, download the plugin from the My VMware portal: 1. Go to your web browser and navigate to the VMware downloads website: https:/​/​my.​vmware.​com/​web/​vmware/​downloads. Log in with your credentials and select View & Download Products. 2. Select All Downloads, scroll down to the Networking & Security menu item, and click Drivers & Tools. 3. Under the Drivers & Tools tab, expand VMware NSX for vSphere Tools, select the appropriate NSX-vRO plugin (in our example, VMware vRealize Orchestrator Plugin for NSX 1.2.0), and click Go to Downloads.

[ 530 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

4. Click Read More to expand the additional information, verify the file details, and click the blue Download button or the Download Manager link:

Once you have downloaded the VMware vRO plugin for the NSX file, it is best practice to verify the file against the listed checksum to ensure that the downloaded file is an identical copy of the source.

Installing the vRO plugin for NSX Follow these steps to install the downloaded vRO plugin from the vRO control center: 1. Log into the vRealize Orchestrator Control Center page (https://:8283/vco-controlcenter) and go to the Plug-Ins | Manage Plug-Ins.

[ 531 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

2. Under Install plug-in, BROWSE the previously downloaded vRO plugin (in this example, 011nplugin-nsx-1.2.0.vmoapp) and click the blue INSTALL button:

3. Review the EULA and click the Accept EULA button once finished reviewing. Click the blue INSTALL button to install the plugin. 4. Verify that the plugin is installed and click the blue SAVE CHANGES button in the top-right corner to save the changes:

[ 532 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

5. Go to homepage | Startup Options and RESTART the Orchestrator server service:

[ 533 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

6. Verify that the installed plugin is listed under the Plug-In section:

[ 534 ]

Chapter 12

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

7. For vRO to be able to run workflow against an NSX Manager, an NSX endpoint must be registered in the vRO. To perform this registration, open the vRealize Orchestrator client and log in. Make sure you are in the Run mode, select the workflows tab (the blue icon) in the left-hand pane, expand the NSX | Configuration folder, select Create NSX endpoint workflow, and click the green Start workflow icon:

8. Input all the required parameters on the text boxes and click the Submit button to run the workflow:

[ 535 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

9. Verify that the workflow finishes successfully.

[ 536 ]

Chapter 12

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

10. On the left-hand pane, select the last inventory tab icon and perform a refresh by clicking the refresh icon in the top-right corner. Verify that you can see a new NSX endpoint and its inventory. The endpoint name should be endpoint@NSXManagerFQDNorIP. In this example, the NSX endpoint is nsxmgr-01a@https://nsxmgr-01a.corp.local:

[ 537 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

Running an NSX-vRO workflow In this example, we will run a prebuilt NSX-vRO workflow to create a logical switch: 1. Make sure you are in the Run mode, select the workflows tab (the blue icon) in the left-hand pane, expand the NSX | NSX workflows folder, select the Create logical switch workflow, and click the green Start workflow... icon:

[ 538 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

2. For the NSX Endpoint, browse and select the desired NSX endpoint, and for Transport zone id input the desired transport zone's MoRef ID. Input all the remaining parameters into the text boxes and click the Submit button to run the workflow:

3. Verify that the workflow finishes successfully.

[ 539 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

4. Verify in the vSphere Web Client that the logical switch is created. In our example, the logical switch Name is vRO-Logical Switch:

How it works... The vRealize Orchestrator (vRO) plugin for NSX offers pre-existing vRO workflows that can be used to automate NSX workflows using VMware vRO for both day-0 and day-2 operations:

[ 540 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

There's more... vRO includes an HTTP-REST plugin that can be used to consume the NSX API via the REST API:

This enables the creation of custom workflows to perform advanced NSX operations based on the NSX REST API. To use the HTTP-REST workflows, run the Add a REST Host workflow to add the NSX Manager as an HTTP-REST endpoint. Once the NSX Manager has been registered as an HTTP-REST endpoint, you can run an HTTP-REST workflow against it. There are some HTTP-REST-based sample workflows for NSX, called vRA Extensibility for NSX, available here: https://communities.vmware.com/docs/DOC-30791.

[ 541 ]

||||||||||||||||||||

||||||||||||||||||||

Leveraging the VMware NSX REST API for Management and Automation

Chapter 12

See also For more information on how to install and use vRealize Orchestrator, see these links: VMware vRealize Orchestrator Documentation: https://www.vmware.com/support/pubs/orchestrator_pubs.ht ml

VMware vRealize Orchestrator Essentials: https://www.packtpub.com/virtualization-and-cloud/vmware-vre alize-orchestrator-essentials

VMware vRealize Orchestrator Cookbook - Second Edition: https://www.packtpub.com/virtualization-and-cloud/vmware-vreal ize-orchestrator-cookbook-second-edition

[ 542 ]

||||||||||||||||||||

||||||||||||||||||||

Other Books You May Enjoy If you enjoyed this book, you may be interested in these other books by Packt:

Learning VMware NSX - Second Edition Ranjit Singh Thakurratan ISBN: 978-1-78839-898-5 Understand software-defined networks Deploy and configure VXLAN-enabled logical switches Secure your environment using Distributed Firewall and Data Security Configure third-party services in NSX Manage, configure, and deploy edge gateway services Perform various Edge operations including configuring CA certificates Explore the different monitoring options to check their traffic flow

||||||||||||||||||||

||||||||||||||||||||

Other Books You May Enjoy

VMware NSX Network Essentials Sreejith.C ISBN: 978-1-78217-293-2 Deep dive into NSX-v Manager, Controller deployment, and design decisions Get to know the strategies needed to make decisions on each mode of VXLAN that is based on physical network design Deploy Edge Gateway and leverage all the gateway features and design decisions Get to grips with NSX-v Security features and automate security Leverage Cross VC, identify the benefits, and work through a few deployment scenarios Troubleshoot an NSX-v to isolate problems and identify solutions through a stepby-step process

[ 544 ]

||||||||||||||||||||

||||||||||||||||||||

Other Books You May Enjoy

Leave a review - let other readers know what you think Please share your thoughts on this book with others by leaving a review on the site that you bought it from. If you purchased the book from Amazon, please leave us an honest review on this book's Amazon page. This is vital so that other potential readers can see and use your unbiased opinion to make purchasing decisions, we can understand what our customers think about our products, and our authors can see your feedback on the title that they have worked with Packt to create. It will only take a few minutes of your time, but is valuable to other potential customers, our authors, and Packt. Thank you!

[ 545 ]

||||||||||||||||||||

Index A Active Directory (AD) 394 Active Flow Export Timeout 483 address resolution protocol (ARP) 76 Applied To field Firewall Default Applied To settings, modifying from Firewall Table Menu 262 Service Composer Firewall Default Applied To Settings, modifying 263 settings, modifying 261 ARM (Application Rule Manager) about 453 using 484, 485, 487, 489, 490 Automating NSX for vSphere with PowerNSX URL 523

B Bidirectional forwarding detection (BFD) 137 Border Gateway Protocol (BGP) 95 bridging about 134 hardware VTEP gateway 135 broadcast, unknown unicast, and multicast (BUM) traffic about 136 broadcast 52 multicast 52 unknown unicast 52 business critical support (BCS) 14

C CDO logical switch 91 certificate authority (CA) 23 certificate signing request (CSR) 23 CLI user accounts

||||||||||||||||||||

configuration, verifying 403 creating, in NSX Manager 395, 406 enable password, modifying 402 managing, in NSX Manager 395, 406 password, modifying 402 REST API access, granting 398 VTY session, clearing 404 content addressable memory (CAM) 105 content packs 454 Controller Disconnect Operation (CDO) about 47 enabling, on transport zone 89, 91 Controller VM (CVM) 237 Cross-vCenter functionality 278 cURL REST API, using 511, 514 script, generating from Postman 515 URL 511

D Data Loss Prevention (DLP) 224 DFW protection virtual machines, excluding 235, 237 DFW rules ESXi Host CLI, using 260 NSX Manager central CLI, using 260 verifying 259 DFW session timeout configuring 238 DHCP server configuring 161, 166 distributed firewall (DFW) about 219 URL 230 Distributed Logical Router (DLR)

||||||||||||||||||||

||||||||||||||||||||

about 50, 93 configuration, for dynamic routing 107, 112 configuring 95, 99, 103 forwarding, versus protocol address 114 graceful restart 115 HA interface 107 hardware requisites 107 route redistribution 113 DLR Control VM (DLR CVM) 95 DNS relay configuring 158, 160 dvPortGroup 132 dynamic routing Distributed Logical Router, configuring 107, 112

E Edge Firewall configuring 166, 168, 172 Edge services gateway (ESG) 93 Endpoint Monitoring about 453 data collection, initiating 494, 496 prerequisites, verifying 492 using 491 Enhanced Linked Mode (ELM) 287 ESXi Agency Manager (EAM) 38 ESXi hosts selecting 15 external BGP (eBGP) 128

F firewall table menu rules, creating 242, 244 sections, creating 240 security policy rules, creating 240 security policy, creating 245 Flow Monitoring about 453 collection, enabling 480, 481 collection, exporting 481 enabling 479, 482 forwarding address about 114 versus, protocol address 114

fully qualified domain name (FQDN) 26

G gratuitous ARP (GARP) 445 Guest Introspection Services deploying 264, 270 Non-IP Layer 2 Traffic, blocking 270 VMware tools, installing 268

H Hardware switch controller (HSC) 136 hardware VTEP gateway adding, to NSX 151 connecting, to NSX controller 151 integrating, with VMware NSX 147, 152 references 153 replication cluster, configuring 149 selecting 146 VMware NSX Logical Switch, extending 154, 156 Hardware VXLAN gateway HCL URL 147 High Availability (HA) about 106, 299 configuring 211, 218 HyTrust CloudControl for VMware NSX URL 377

I Identity Firewall (IdFW) about 224 configuring 272 Microsoft Active Directory Domain, registering with NSX Manager 272, 274 Security Rules, creating with Active Directory Objects 275 interfaces internal 122 uplink 123 internal BGP (iBGP) 128 Internet Protocol Flow Information eXport (IPFIX) 482 IP discovery configuring, for virtual machines 230

[ 547 ]

||||||||||||||||||||

learned IP address, verifying 232 IPSEC VPN configuring 196, 198

L layer 2 bridging about 131 use cases 131 Lightweight directory access protocol (LDAP) 394 Load Balancing configuring 178, 180, 196 NSX edge load balancer configuration, verifying 194 NSX Edge Load Balancer, configuring 187 NSX Edge Load Balancer, deploying 180, 186 logical interface (LIF) about 105 internally 105 uplink 105 logical switch backing port group restoring 354, 355

M Managed Object Reference (MoRef) 499 minification 515 mission critical support (MCS) 14 monitoring tools about 449, 452 Application Rule Manager 453 endpoint monitoring 453 Flow Monitoring 453 multi-chassis link aggregation URL 56

N network adapters selecting 15 Network Address Translation (NAT) configuring 173, 177 destination NAI (DNAT) 173 DNAT rule, configuring 176 SNAT rule, configuring 174 Source NAT (SNAT) 173 network and security service deployments

upgrading 446, 448 Network information services (NIS) 394 network interface card (NIC) 15 network introspection service deploying 264, 270 Non-IP Layer 2 Traffic, blocking 270 Service Definition, registering 265 Service VM, deploying 266 network virtualization controller (NVC) 136 NSX Administration Guide URL 158 NSX component logs 449 NSX components communication checking 45 NSX Components Syslog configuring 459, 465, 467 NSX Controller Node Syslog, configuring 462 NSX Edge Log, configuring 463 NSX Manager syslog, configuring 460 NSX controller cluster controller password parameters 35 deploying 30 deployment 32 DRS anti-affinity rules 33 NSX IP pool, configuring 32 vCenter environment 35 NSX controller nodes restoring 348, 352, 353 upgrading 435, 438 NSX DFW rules configuration, exporting from firewall menu 359 configuration, restoring from firewall menu 361, 366 NSX DFW about 220, 222 component status, verifying 226 firewall installation status, verifying 227 policy 224 references 226 topology 224 vShield stateful firewall (vsfwd) connection, verifying 227 vShield stateful firewall (vsfwd) status, verifying 227 working 229

[ 548 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

NSX Distributed Firewall Log configuring 468, 469, 471 log, viewing from ESXi host console 471 viewing 468, 471 NSX Edge restoring 356, 357, 359 NSX ESG configuration, for routing 123, 126 configuring, in HA mode 115, 118, 121 deploying, in HA mode 115, 118, 121 NSX for vSphere API Guide URL 502 NSX license applying 29 NSX logical switch broadcast 86 creating 74, 75, 76, 77, 79 ping 84 testing 84, 87, 89 virtual machine, connecting 80, 83 NSX Logs about 450 ESXi host 452 NSX Edge Gateway VM 452 NSX Manager 451 vCenter Server 451 NSX manager certificate PKCS#12 certificate 24 replacing 23, 25 NSX Manager virtual appliance installing 19, 21 user account 378 NSX Manager, roles primary 288 secondary 288 standalone 288 transit 288 NSX Manager about 38 backing up 339, 343, 345 CLI user accounts, creating 395, 396, 406 CLI user accounts, managing 395, 406 configuration mode, entering 395 enhanced linked mode 288 Microsoft Active Directory Domain, registering

272, 274 primary role, configuring 283, 286 registering, with PSC 28 registering, with vCenter server 26 restoring 346, 347 secondary role, configuring 283, 286 troubleshooting 289 Universal Synchronization Service Management 289 upgrading 430, 434 vCenter server, registering 25, 29 NSX security policy exporting, from Service Composer menu 367 restoring, from Service Composer menu 371 NSX transport zone about 50 creating 70, 72, 73 NSX Upgrade Coordinator about 417 URL 417 NSX VIB installation checking manually 42, 45 controller communication 41 distributed firewall communication 40 validating 40, 41 NSX, roles auditor 377 Enterprise Administrator 377 NSX Administrator 377 Security Administrator 377 NSX access, granting 388 downloading, for vSphere 16, 19 media, downloading via VMware downloads website 17 media, downloading via VMware software manager 18 monitoring, with NSX Dashboard 454, 456, 458 NSX-vRO workflow, executing 538, 539 product interoperability matrix, checking 16 role, assigning to user account 391, 394 vCenter role, assigning to user account 389 vRealize Orchestrator plug-in, using 529, 540, 541 vRO plug-in, downloading 530, 531

[ 549 ]

||||||||||||||||||||

vRO plug-in, installing 531, 532, 535 vSphere cluster, preparing 36

O Open Shortest Path First (OSPF) 95 open virtual application (OVA) 16 open VM tools (OVT) 222 Open vSwitch 136 Open vSwitch Database (OVSDB) 136 OpenFlow 136

P phantom controller 351 Platform Services Controllers (PSCs) 26, 288 Postman REST client REST API, using 506 Postman cURL script, generating 515 PowerNSX references 523 PowerShell Core URL 521 PowerShell HTTP GET REST API, requesting 517 HTTP POST REST API, requesting 518 REST API, using 516 product interoperability matrix checking 16 URL 16 protocol address about 114 versus forwarding 114 Python HTTP GET REST API, requesting 524 HTTP POST REST API, requesting 526 REST API, using 523, 528 URL 524

R Receive side scaling (RSS) 15 Recommended Configuration Maximums URL 178 recovery point objective (RPO) policy 458 remote desktop session host (RDSH) 277

Remote Office and Branch Offices (ROBO) 10 replication modes URL 53 Replication Service Nodes (RSN) 148 requisites, for hardware VTEP gateway Bidirectional forwarding detection (BFD) 137 Hardware switch controller (HSC) 136 Network virtualisation controller (NVC) 136 Replication service nodes (RSN) 136 REST API HTTP GET REST API, requesting via cURL 511, 512 HTTP GET REST API, requesting via Postman 506, 508 HTTP GET REST API, requesting via PowerShell 517 HTTP POST REST API, requesting via cURL 512 HTTP POST REST API, requesting via Postman 508 HTTP POST REST API, requesting via PowerShell 518 using, with cURL 511 using, with Postman REST client 506, 510, 514 using, with PowerShell 516 using, with Python 523, 527 REST Status codes URL 501 RFC7047 URL 136 role-based access control (RBAC) 377 route redistribution 113

S security policy rules creating 254, 258 creating, from firewall table menu 240, 245 creating, from service composer menu 248 DFW rule ID 246 DFW saved configurations 247 logs 246 Security Group, creating with Dynamic Membership 251 Security Group, creating with Security Tag as Dynamic Membership Criteria 252

[ 550 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

security group, creating with static inclusion 248 Service Composer menu NSX security policy, exporting 367 NSX security policy, restoring 371 security policy rules, creating 248 service user account creating, for vCenter server registration 379 service virtual machine (SVM) 237 Simple Network Management Protocol (SNMP) 115 Single Sign-On (SSO) 394 software defined datacenter (SDDC) 10 software-based gateway layer 2 bridging about 132 configuration, verifying 141, 143, 145 configuring 137, 139 SpoofGuard about 219 working with 232, 233, 235 SSL VPN configuring 201, 210 syslog protocol (RFC 5424) 454

web-tier-to-app-tier Universal Firewall Rule, adding 326, 328 web-tier-to-web-tier Universal Firewall Rule, adding 322, 325 Universal Distributed Logical Router (UDLR) 279 Universal Logical Router creating 299, 301, 303, 305, 307, 309, 310 deployment models 311 local egress 312, 314 Universal Logical Switch configuring 299 creating 296, 298 VM, adding 314, 317, 319 Universal Transport Zone creating 290, 294, 295 vSphere cluster, adding 290, 294, 295 unusable multicast address URL 69 user datagram protocol (UDP) 15 user world agent (UWA) 229

T

vCenter Managed Object Reference ID (MoRef ID) about 504 references 505 vCenter server registration NSX Manager, registering 385, 386 service user account, creating 379 SSO user account, adding as SSO administrator 382 user account, creating 379 vCenter server about 38 NSX manager, registering 26 registering, with NSX manager 25 virtual MAC (vMAC) 105 virtual machine (VM) adding, to Universal Logical Switch 314, 317, 319 connecting, to NSX logical switch 80, 83 excluding, from DFW protection 235 excluding, from virtual machine 237 IP discovery, configuring 230 Virtual Machine Communication Interface (VMCI) 269

TCP segmentation offload (TSO) 15 teaming policy URL 57 Transit logical switch (LS-TRANSIT) 115 transport zone Controller Disconnected Operation mode, enabling 89, 91 Trust on First Use (TOFU) 231 typecast URL 522

U Universal Controller Cluster (UCC) 280 Universal Distributed Firewall (UDFW) about 279, 319 app-tier-to-db-tier Universal Firewall Rule, adding 331, 334 configuring 319, 321, 336 Universal IPSets, creating 321 Universal Section, adding 322, 325

V

[ 551 ]

||||||||||||||||||||

virtual Network Interface Card (vNIC) 220 VMware Compatibility Guide URL 15, 146, 413 VMware Hands-on Labs URL 13 VMware installation bundles (VIBs) 36, 38 VMware Internetwork Service Insertion Platform (VSIP) 452 VMware KB 2148511 URL 147 VMware lifecycle product matrix URL 19 VMware NSX Controller disconnected operation mode 53 VMware NSX Edge upgrading 442, 445 VMware NSX Hands-on Lab Advanced URL 13 VMware NSX Hands-on Lab Intro URL 13 VMware NSX host clusters upgrading 439, 442 VMware NSX logical switch about 48 extending, to hardware VTEP Gateway 154, 156 VMware NSX replication modes 52 VMware NSX working state NSX components working state, verifying 423, 427 NSX Manager virtual appliance working state, verifying 418, 422 verifying 418, 429 vSphere components, verifying 428 VMware NSX deprecated features, reviewing 414 discontinued features, reviewing 414 edition, evaluating 13 editions 12 hardware VTEP gateway, integrating 147, 152 monitoring tools 14 product interoperability matrices, checking 410 selecting, for vSphere edition 10, 14 Supports and subscription (SnS) 13 third-party integrations compatibility, checking 413

upgrade bundles, downloading 415 upgrade, preparing 409 VMware NSX upgrade path, checking 411 VMware vRealize Log Insight, for NSX 14 vSphere release documents, reviewing 413 vSphere release notes, reviewing 413 VMware Product Interoperability Matrices checking 410, 530 URL 410, 411, 530 VMware service insertion platform (VSIP) 40, 229 VMware's Customer Experience Improvement Program (CEIP) 432 VMware URL 16 vRealize Automation (vRA) 261 vRealize Log Insight (vRLI) about 449, 454 configuring 472 DFW rules, filtering from interactive analytics menu 475, 479 NSX Content Pack Dashboards, navigating 474 references 472 VMware NSX, installing for vSphere Content Pack 473 vRealize Network Insight 454 vRealize Orchestrator (vRO) 540 vRealize Orchestrator plug-in references 542 using, for NSX 529, 540, 541 VMware Product Interoperability Matrices, checking 530 vShield Firewall Daemon (vsfwd) 229 VSIP I/O Control (VSIPIOCTL) 229 vSphere cluster NSX, enabling in brownfield environment 40 preparing, for NSX 36, 38 vSphere distributed switch (vDS) 77 vSphere edition VMware NSX, selecting 10, 14 vSphere environment URL 409 vSphere installation bundle (VIB) 229 vSphere Storage Metro Cluster (vSMC) 55 vSphere Update Manager (VUM) about 439

[ 552 ]

||||||||||||||||||||

||||||||||||||||||||

||||||||||||||||||||

URL 439 vSphere Web Client plugin URL 339 vSphere NSX, downloading 16 VXLAN 48 VXLAN Network Identifier (VNI) 30, 49, 66 VXLAN networking configuring 54, 58, 60, 62, 66 DHCP, using for IP pool 55 IP address, for VTEP VMkernel 55 multi-VTEP, with route based on originating port ID 57

validating 61 VDS teaming options, for NSX 56 VTEP, configuration 61 VTEP, with LACP 56 VXLAN VTEP VMkernel, testing 65 VXLAN offload 15 VXLAN segment ID configuring 66, 67, 68 VXLAN Tunnel Endpoint (VTEP) 49

X XML beautifier URL 515