NSX

VMware NSX Distributed Firewall Rules – Scoping and Direction Matter

I, like I’m sure many of you, were not traditionally firewall or security admins prior to adding VMware NSX to your vSphere environments.  As such, there’s been a bit of a learning curve for me regarding what I knew [or thought I knew] regarding physical firewalls and how that translates [or doesn’t] to the NSX Distributed Firewall (DFW).

As I’ve been rolling out NSX DFW rules to various types of systems with different accessibility requirements, I ran across some unexpected behavior when scoping the rules.

Let’s look at an example 2 tier application consisting of a “web server” and an “app server”.  If this were a traditional physical firewall setup, the web server would probably be in the DMZ, or at least a different subnet from the app server, the traffic would route through the firewall and rules would be applied to allow or restrict traffic.

nsx-firewall-blog-v2

As a theoretical example, for our web tier, we’re allowing HTTP/HTTPS/FTP inbound to the web server from “any” source (presumably, any number of public networks), letting FTP back outbound to “any” destination, DNS outbound to our internal DNS servers, and SMB traffic to the app server where files are stored.  We make the assumption that while FTP traffic may be allowed outbound to any destination, it’s only going to reach that destination if it allows FTP inbound.  Everything else is denied by default.  Pretty straight forward.

For the app server, we’re allowing SMB inbound from “any” source (maybe there are several hundred internal VLAN’s that users could access the server from and it is not accessible externally), RDP is allowed inbound from “any” source, we have some various Active Directory / LDAP related ports open for domain membership, pings are allowed outbound to “any” due to a monitoring application hosted on the server, and DNS is allowed outbound to our DNS servers.  Everything else is denied by default.

Based on these firewall rules, when comparing what traffic is allowed in or out of each server, there is really only one traffic pattern which should match between the two, which is SMB from the web server to the app server (highlighted).

However – everything is not as it seems…

At this point, I have created DFW rules functionally identical to the first diagram in this post.  Let’s go through some various connectivity checks…

dfw-rules-3dfw-rules-4

From the web server, we can access file shares on the app server, thanks to a combination of firewall rule 4 allowing SMB traffic outbound from the web server to the app server, and firewall rule 5, allowing SMB traffic inbound to the app server from “any” source.

dfw-rules-6

From a user workstation, we can pull up the default website on the web server, thanks to firewall rule 1 allowing inbound HTTP traffic from “any” source.  So far so good.

dfw-rules-5

Let’s try to ping it from the same workstation…no dice, and as expected, since ICMP is not allowed anywhere in the rule set “Web Tier” (rules 1 through 4).

dfw-rules-7

Now let’s try the same tests from the app server itself…wait – that’s strange…both ICMP and SMB traffic is allowed from the app tier to the web tier, even though there are no rules applying to the security group containing the web server which specifically allows that traffic in.  Is such a thing even possible?

dfw-rules-meme-2

dfw-rules-8v2

The “problem”…

Let’s use the “Apply Filter” option in the Distributed Firewall to determine which rule(s) are to blame.  I specified the “Source” as the app VM, the “Destination” as the web VM, changed the action to “Allow” (this could also be handy to see what rule was blocking traffic you thought should be allowed by choosing the “Block” option), and then selected ICMP as the “Protocol”.

dfw-rules-9v2

And now we can see that Rule 1038 that allows the Security Group containing the app VM to send ICMP traffic to “any” destination has matched the filter.

dfw-rules-10

When I think of firewall rules in the “traditional” manner, I would expect allowing outbound ICMP from our application server to a destination of “any” wouldn’t also imply that ALL VM’s in my NSX environment should also allow that traffic inbound.  The whole point of “zero trust” and “default deny” is that unless traffic is explicitly allowed, it should be denied.  Perhaps to someone who comes from a network/security background and has used many different firewalls, this would be seen as expected behavior in certain scenarios – but that is not intuitive to this virtualization guy.

In a nutshell, there are a couple things in play here…

  1. Scoping matters.  By selecting a destination of “Any”, NSX truly means ANY.  Even though you may not have allowed a particular traffic type inbound on some unrelated system, because we have this “Any” rule, our application server can talk to it over that protocol.  I can see this being particularly problematic in a multi tenant environment, or maybe some kind of PCI environment where you have to prove a definitive dividing line between different systems.  One improperly scoped rule later and you have unintended consequences.
  2. Direction matters.  Hidden by default is the column titled “Direction”.  When creating a new firewall rule, this column is hidden, and the default value is “In/Out”, which is the root of our problem here.  If we’d configured Rule 1038’s “Direction” value as “Out”, it wouldn’t have been implied that it should be allowed “In” on the web server.  In my opinion, VMware should not have this column hidden by default, and an administrator should have to choose a direction on the rule without a value being pre-populated.  In addition, I could find no way to manipulate the “Direction” value when using “Service Composer” – the default value is In/Out and there’s no way (at least in the GUI,) to change it.

The “fix”…

The first way to “fix” this issue is to always assign the appropriate directional value to each firewall rule.  Through a combination of “In” and “Out” rules, your traffic should be allowed in the direction you expect without any “unintended consequences”.  The rules are still Stateful, meaning that if we allow ICMP out to “Any” from the app VM (but only in the “Out” direction), that traffic is allowed to return back to the app VM without requiring a second rule stating so.

Add the “Direction” column to your view

dfw-rules-11

Then, click the “Edit” icon next to the “Direction” value

dfw-rules-12

Then select the appropriate value from the “Direction” drop down menu

dfw-rules-13

Let’s go ahead and modify these DFW rules with the appropriate “Direction” and test again.

dfw-rules-16

As you can see here, from the app VM to the web VM, HTTP, SMB, and ICMP which previously worked is now blocked.

dfw-rules-17

Scoping matters…

The other important thing to consider is the rule scoping – in the example above, the web server allows HTTP/HTTPS traffic inbound from “Any” source.  Perhaps in this case the web server is publicly facing and there’s no real need for internal systems to access it directly.  In such a scenario, an IP Set allowing only public IP addresses to communicate with it could be used.

Here I’ve created two “IP Sets” on my NSX Manager.  One contains “all subnets” that I’ve called “ipset_all-networks” with a range of 1.1.1.1-254.254.254.254 and the other is a called “ipset_all-private-networks” with the three private IP spaces specified (if you only use a small part of one private IP space, you could certainly get that granular, too).

dfw-rules-14

Then, I created a Security Group called “sg_all-public-networks”, chose a static member of my IP Set called “ipset_all-networks”, then created an exclusion using my IP Set “ipset_all-private-networks” to block any internal IP address from matching the rule.  I could use this Security Group in place of the “Any” scoping object on my publicly facing web server, or even inverse it so that no public IP’s are allowed when scoping a rule.

dfw-rules-15

Obviously, there are many ways to as they say “skin a cat” with the Distributed Firewall, but as I found out…direction and scoping matter.

Got a better or more efficient way to manage the NSX Distributed Firewall rules?  I’m all ears!  😛

VMware NSX Lab Environment – Part 2: Prepare Hosts and Deploy NSX Controllers

Introduction

In Part 2 of this series I will cover preparing the ESXi hosts for NSX and deploying an NSX Controller cluster.  As mentioned in the first part of this series “Part 1:  Import and Configure NSX Manager“, the NSX Manager facilitates the deployment of the Controller clusters and ESXi host preparation (among other things), so needless to say having it up and functioning is a prerequisite for this phase.

At the completion of this post, the NSX environment should be mostly configured and we will be able to start doing fun stuff like deploying logical switches, setting up distributed routing, and playing with distributed firewall rules.  I’m pretty excited. /geekout

As you may have gathered by their name, the NSX Controllers reside in the “Control plane” while the NSX Manager resides in the “Management plane”.  Services such as logical switches, distributed logical routers / firewalls are all hypervisor kernel modules and reside in the “Data plane”.  NSX Edge, a virtual appliance(s) also resides in the data plane.  The focus of this post will be the Control plane.

This diagram, courtesy of the VMware NSX 6 Design Guide, depicts the various “planes” in which NSX components reside.

Controller Deployment 2

Deploying the NSX Controllers

1. Now that NSX Manager is running and linked to your vCenter server, the next step in the process would be to enter your NSX licenses.  However, since this is a lab I am running it in evaluation mode for 60 days, I have nothing to enter here.  If you do own the product, or are lucky enough to have a license key for perpetual lab purposes, you’d just go to “Administration > Licensing > Licenses” in the vSphere Web Client and enter the appropriate license keys.

Controller Deployment 1

2. After you’re licensed (or running in eval mode), it’s time to deploy the NSX Controllers.  Under “Networking and Security”, click “Installation.

Controller Deployment 3

3. Click the green “+” sign underneath “NSX Controller nodes”…

Controller Deployment 4

…and you will be asked to enter vSphere cluster, storage, and networking info.

Controller Deployment 5

Click “Select” next to “IP Pool”.  If you’ve already created one you’d like to use, select it and then click “OK”.  Otherwise, click the green “+” and add a new IP Pool.  Once you’ve entered the details appropriate to your environment, click “OK” on the “Add IP Pool” window, select the radio button next to your new IP Pool, and then click “OK” again on the “Select IP Pool” window.

I’ve created a 10 address IP pool for the NSX Controllers to use – technically you’d only need as many IP addresses as you’d have NSX Controllers, but I get kind of OCD about that sort of thing so I’ve allocated a block of 10.  IP’s are one of the few things I have an abundance of in the lab environment.

Controller Deployment 6

4. Click “OK” on the “Add Controller” window.

** It’s worth noting – the NSX Controller password requirements are fairly strict.  My “lab password” I’ve been re-using throughout the environment did not meet the length requirement and it complained…as you see here.  I have a feeling this is one of those passwords you don’t want to lose so be sure to keep it somewhere safe.

Controller Deployment 7

Assuming everything is good with your configuration, NSX Manager should begin deploying the Controllers to your vSphere environment using the supplied credentials linking it to vCenter (as you can see in the “Initiated by” column under “Recent Tasks”).  It’s also worth noting that the NSX Controllers get a unique identification string appended to them – avoid the urge to modify this – it’s by design.  (And yes, I did just throw a screenshot of the “fat”/C# client in here…I do catch myself flipping back to it from time to time.  It’s a habit I’m working on breaking 😛 )

Controller Deployment 8

5. Once the Controller deployment has completed, it should show a “Normal” status in the vSphere Web Client window.  If that’s the case, it’s fairly safe to say subsequent Controller deployments will be successful, so you can now repeat this process 2 more times in order to meet the “3 Controller node minimum” recommendation.  NSX Controllers should be deployed in odd numbers so that a “majority vote” can occur for electing a Master controller.

**You will not be prompted to enter a Controller password again on subsequent Controller deployments – this is shared between all NSX Controllers in the Controller cluster.

Controller Deployment 9

The Controllers are clustered?  Yes, they are.

Without going in too much detail (the NSX Design Guide does a great job explaining it), the “responsibilities” of an NSX Controller get distributed among all members of the Controller cluster.  A Master Controller is responsible for determining when a Controller node has failed and where the “slices” of a particular role it held should be transitioned to.

This image, courtesy of the VMware NSX Design Guide, shows the number of nodes that can fail for a particular NSX Controller cluster count.

2015-04-27 13_25_03-NSX 6 Design Guide.pdf - Adobe Reader

6. In this step, we will create “anti-affinity” rules for the NSX Controllers to ensure no two Controllers ever reside on the same host.  This is an important step in mitigating impact to the NSX environment if an ESXi host fails.  For a lab environment it’s probably not a big deal but I felt it was important to show, as I frequently see vSphere environments with no DRS rules setup when they should probably be used for resiliency of redundant guest VM’s.  As has been commented on by others, I’m kind of surprised that the creation of the anti-affinity rule isn’t done by NSX Manager automatically when deploying two or more Controllers.  I believe other components, such as NSX Edges, do have a rule created by default…perhaps I’m mistaken and will find out shortly.

Anyhow…

In the vSphere Web Client, navigate to the “Hosts and Clusters” view, select the applicable vSphere cluster, then click the “Manage” tab.  Select “VM/Host” Rules and then click “Add”.

Controller Deployment 10

7. Give your DRS Rule a name – I usually like to get descriptive about the nature of it (i.e. add “Anti-Affinity”) in the name.  Click the “Add” button, select your NSX Controllers, and click “OK”.  Click “OK” once more on the “Add VM/Host Rule” window.

DRS Rules 2

8. Now we will prepare the ESXi hosts for NSX.  Click on the “Host Preparation” tab and then select “Install” next to the appropriate cluster(s).  When prompted, click “Yes” to continue with the install.

Controller Deployment 12

If the host preparation was successful, you should see a green checkmark underneath the “Installation Status” and “Firewall” columns.

Controller Deployment 13

9. The next step is to configure VXLAN on our NSX enabled cluster.  On the “Host Preparation” tab, under the “VXLAN” column, select “Configure”.  You will need to select a Distributed Virtual Switch for VXLAN traffic (I’ve created one dedicated for that purpose with a single vNIC uplink…hey, it’s a lab), enter the appropriate VLAN, set your MTU size (it’s not recommended to go below 1600 due to the ~50 byte VXLAN header addition) so make sure your underlying physical (or in this case, virtual) network is configured for jumbo frames.

I’m going to create an IP pool dedicated for VTEP’s so I’ve selected “New IP Pool…” from the drop down box.

Controller Deployment 14

Enter the appropriate IP Pool information here, then click “OK”.  Like the IP Pool I created for the NSX Controllers, this one has 10 IP addresses in it.  You will need a pool large enough to provide IP addresses for each VTEP (VXLAN Tunnel End Point) interface on each host in that IP space.

Controller Deployment 15

Click “OK” in the “Configure VXLAN networking” window.

At this point, we should have green checkmarks across the board on our “Host Preparation” tab.

Controller Deployment 16

** There are considerable design decisions that must be made when choosing your VMKNic Teaming Policy – the layout of your physical networking and Distributed Virtual Switch uplink configuration could dictate which options are viable.  The VMware NSX Design Guide goes over this in great detail (beginning around page 73) and is worth the read.

This table courtesy of the VMware NSX Design Guide shows the teaming and failover modes available based on the uplink type.

Controller Deployment 17

10. The next step is to create a Segment ID (which I believe is also sometimes called a VXLAN Network Identifier/VNI) Pool.  I like to think of Segment ID’s like special VLAN’s inside of the NSX environment – they are used to differentiate the various logical network segments just like VLAN’s on a physical switch logically segment the traffic.  NSX let’s you specify a range of 5,000 to 16,777,216…so roughly 16 million possibilities.  The range you specify in your Segment ID Pool will dictate the maximum amount of logical switches available to your NSX environment.

Under the “Installation” section, click the “Logical Network Preparation” tab and select the “Segment ID” section.  Click “Edit” next to “Segment IDs & Multicast Address allocation…”

Controller Deployment 18

11. Specify your Segment ID Pool range.  I chose 5000-5999, which gives me 1000 possible network segments…far greater than I’d ever need in a lab, but hey why not?

Controller Deployment 19

** I’ve not checked the option to “Enable multicast addressing” and am relying on Unicast for my BUM traffic (Broadcast, Unknown, Unicast, and Multicast).  Not to sound like a broken record, but there are considerable design decisions you’d make to determine whether or not to use Multicast, Unicast, or Hybrid modes.  Page 25 of the VMWare NSX Design Guide goes into detail about the pros and cons of each, when to use or not use, etc.  This is not something I ever had to give much thought to in my “server centric” world prior to starting down the NSX wormhole, and found it one of the harder concepts to grasp and remember when studying for the VCP-NV exam.  This is an area I am still shoring up because it’s directly related to the way NSX propagates information throughout the environment, so it’s obviously a critical piece.

12. The final piece is to configure our Transport Zone.  What is a Transport Zone you ask?  Well, per VMware, it quite literally “defines a collection of ESXi hosts that can communicate with each other across a physical network infrastructure.”  In other words, it determines which cluster(s) participate in the NSX environment.

Click on the “Transport Zones” section, then the green “+” sign.

Controller Deployment 20

Give the Transport Zone a name, select the appropriate replication mode, and the cluster(s) you wish to be included in the Transport Zone.  Click “OK”.

Controller Deployment 21

12. At this point, all the NSX Controllers and supporting configuration should be in place.  Review each tab under “Networking and Security > Installation > Logical Network Preparation” to ensure everything looks correct.

Controller Deployment 22

Controller Deployment 23

Controller Deployment 24

If so, we’re ready to do all the fun stuff you really wanted to deploy NSX for.  The next post in this series will handle the configuration of logical switching, distributed routing, and Edge Services.  A couple of the big things I’m looking to demonstrate are isolation of mock customers in a multi tenant environment and securing a VDI deployment with NSX.

Being my first go-round installing NSX, if you see any inaccuracies or a better way of doing things, please let me know.  And as always, thanks for reading!

 

VMware NSX Lab Environment – Part 1: Import and Configure NSX Manager

Introduction

This blog series will cover the installation and configuration of VMware NSX 6.1.3 in a lab environment.  As such, there are certain design considerations I am overlooking because this is not a production deployment and lab resources are somewhat limited.  It goes without saying a production deployment may and should look a little different 😉

An example of this would be to distribute the vSphere and NSX infrastructure into multiple clusters – a “Management” cluster which might house vCenter, NSX Manager, and the NSX Controllers; an “Edge” cluster which might house things like the NSX Edge Services Gateway and the Distributed Logical Router (DLR) / DLR Control VM, which control the flow of L2 (NSX Bridging) or L3 traffic (NSX Logical Routing) into and out of the NSX logical networking environment; and a “Compute” cluster where the bulk of your server and/or desktop virtualization workload would live.  In a production deployment, these clusters may even span two or more racks to provide resiliency of all workloads in the event of a rack loss.

Example of “dispersed clusters” courtesy of VMware Hands on Labs (Management/Edge cluster + Compute cluster):

NSX Clusters

However, my purpose for deploying NSX in my lab is to get more hands on exposure to the product and as a “proof of concept” for the various capabilities of NSX.  While important to know all the design considerations, it’s not particularly important in THIS instance.

I highly recommend familiarizing yourself with the NSX Design Guide – it’s a great piece of reference material.  I read it start to finish as part of studying for the VCP-NV exam and largely attribute its content, in combination with the VMware Hands on Labs, for passing the exam.  The NSX Design Guide can be found HERE.

The Lab Environment

I will also not be covering the installation and configuration of the various vSphere 6.0 infrastructure that all the NSX components ride upon.  There are many great blogs and white papers covering this, and let’s be honest – if you’re looking to lab out NSX, you probably already have vSphere configuration down pat.

This NSX lab environment exists on a nested ESXi cluster running vSphere 6.0.  There are three ESXi 6.0 virtual machines, each with 24 GB of RAM, 4 vCPU, and ~200 GB of “local” storage across multiple datastores (a couple of which will be used for VSAN at a later date).  A vCenter Server Appliance 6.0 was imported into the nested environment and runs on top of the virtualized ESXi hosts.  Running a nested hypervisor gives you a lot of flexibility on the hardware which it runs on (and flexibility for isolation if desired, to avoid screwing important stuff up 😛 ), so this could just as easily run on top of a couple “home lab” type boxes without issue.

William Lam (@lamw on Twitter) has a GREAT series of posts on his blog virtuallyGhetto.com detailing the requirements and configuration for running nested ESXi – I highly recommend checking it out.  In fact, the 3-node ESXi cluster I am using for this blog post was deployed from an .OVF file he’s made available to the community.  Check out his Nested ESXi Series here and VSAN .OVF Template series here.  I’ve configured this lab environment to be 100% isolated to the outside world from a network, storage, and hardware perspective…which gives me some freedom to make changes and mistakes without breaking anything I care about.

There’s probably many (and better) blogs covering this same subject, but hey, I need the blogging practice anyway so maybe someone will find it useful…so thanks in advance for reading.

And without further ado, importing and configuring NSX Manager.

Import the NSX Manager

The first step in getting NSX running in your environment is to install and configure the NSX Manager.  The NSX Manager is a virtual appliance that is responsible for deploying all the other components of NSX such as the NSX Controllers, Edge Gateways, etc.

There is a 1:1 relationship between a NSX Manager and a vCenter server – one NSX Manager serves a single vCenter Server environment.

** As stated in the NSX Installation Guide, the NSX Manager virtual machine installation includes VMware Tools.  Do not attempt to upgrade or install VMware Tools on the NSX Manager.  One of the first things I noticed (and felt compelled to do) once the NSX Manager was running is to get rid of the angry yellow “VMware Tools is outdated on this virtual machine” warning on the NSX Manager VM Summary tab.  Fight the urge and leave it at the included VMware Tools level.

NSX Manager 1

1. Deploying the NSX Manager must be done through the vSphere Web Client instead of the C# client due to some “extra configuration options” that are only present in the Web Client. Right click on your vCenter Server and select “Deploy OVF Template”.

** You must have the Client Integration Plugin installed in order to deploy an OVF through the vSphere Web Client.  I’ve had issues with the plugin and Internet Explorer 11, so I recommend running this through Chrome or Firefox until/if those issues are resolved.

NSX Manager 2

2. Browse to your .OVA file.  Mine is on an .ISO mounted in the virtual DVD drive of the virtual “jump box” workstation I access my lab environment from.  Click “Next”.

NSX Manager 3

NSX Manager 4

3. On the “Review details” screen, select the “Accept extra configuration options” check box (this option wouldn’t be presented in the C# client, and then you’d have issues with your NSX Manager).

NSX Manager 5

4. Accept the EULA, blah blah blah, then click “Next”.

NSX Manager 6

5. Select a name for the NSX Manager – I got super creative with mine and left it “NSX Manager” – select a folder/location, then click “Next”.

NSX Manager 7

6. Select a cluster or host, then click “Next”.

NSX Manager 8

7. Select a disk format.  I chose “Thin Provision” since this is a lab and storage is at a premium right now.  If necessary, change your VM Storage Policy.  While this lab will have VSAN configured in it eventually, it does not now, and I’m installing on “local” storage (in quotes because it’s actually a .VMDK file on a SAN LUN) of my ESXi host, so I’ve left it at “Datastore Default”.  Click “Next” once you’ve selected the appropriate storage settings for your environment.

** Another shout out to William Lam (@lamw) and his blog www.virtuallyghetto.com for the super handy nested ESXi VSAN OVF templates from which this lab cluster was deployed.

NSX Manager 9

8. Now it’s time to select a network for your NSX Manager.  Right now I’m using the default “VM Network” that was created when I installed ESXi, but I’m essentially treating it as my management network for management/vMotion VMkernel interfaces.  I’ll have some other network interfaces for VXLAN traffic etc. which will be setup at a later time.  Once you have selected the appropriate network, click “Next”.

NSX Manager 10

9. The “Customize template” window has quite a bit for you to fill in – there are some passwords for various purposes on the NSX Manager, IP/DNS/network settings, etc.  Fill in the info as it applies to your environment, then click “Next”.

NSX Manager 11

10. On the “Ready to complete” screen, verify all your information is correct before clicking finish.  If everything looks good, click “Finish”.  The NSX Manager virtual appliance will now be deployed and powered on automatically (if selected).

NSX Manager 12

Configure the NSX Manager

1. Once the NSX Manager appliance has finished booting and is online, log into the NSX Manager appliance to resume configuration.  You will have specified this IP address in Step 9.  Example https://172.16.99.150.  The credentials used for login will also have been specified in Step 9.  Username: admin Password: [user defined].  If you did not define a password during installation, it should be “default”.

NSX Manager Home

2. The first thing to do is check that all the necessary services are running…if they’re not…you won’t get much further.  Click the “View Summary” button to be taken to the appliance summary page.  All services should show “Running”, with possibly exception to the “SSH Service”.

NSX Summary

 

NSX Summary 2

3. Now we will register NSX Manager with your vCenter Server.  Click the , click “Manage” tab, and then click “NSX Management Service” under the “Components” menu section.

NSX Manager 14

Click “Edit” to enter your vCenter Server details

NSX Manager 15

4. Enter the appropriate credentials to connect to your vCenter Server.  Yeah yeah yeah, I used my personal lab account instead of a service account…so what?!  Click “OK” and you should be prompted to trust the vCenter Server certificate.  Click “Yes” on this window.

NSX Manager 16

NSX Manager 17

 

**Update**

I ended up ditching using my “personal” lab account for the vCenter connection…not exactly sure why yet, but whenever I logged into vCenter it showed a “No NSX Managers available” error.  I switched to a new “service” account that also has Administrator rights in vCenter and the NSX Manager populated correctly.  It even showed my “personal” account listed as an NSX Enterprise Administrator but I could not see anything.  After logging into vCenter with the “nsxservice” service account, I went to Networking and Security > NSX Managers > Manage > Users and deleted my personal account and re-added it as an Enterprise Administrator.  Once I did that, I was able to log into vCenter with my personal account and see the NSX Manager fine.  Who knows…perhaps I did something wrong during the initial vCenter linking.  So just a heads up in case you run into a similar issue.

nsx users 1

5. If the connection to your vCenter Server was successful, you should see a green circle next to the “Status” field.

NSX Manager 18

 

6. Next, the Lookup Service will be configured.  Click the “Edit” button in the “Lookup Service” area.

NSX Lookup Service

Enter your Lookup Service details – it’s worth noting that in vSphere 6.0, the Lookup Service port is now 443.  I had assumed it was still 7444 and ran into some errors applying the configuration.  Luckily I ran across Chris Wahl’s (@ChrisWahl) blog with a quick explanation.

NSX Lookup Service 2

As when linking your vCenter server, trust the certificate.

NSX Lookup Service 3

And you should now see a “Connected” status under the lookup service.

NSX Lookup Service 4

7. The final step for configuring NSX Manager in the lab is to make a backup of the configuration.  It is recommended to do a backup while NSX Manager is in a “clean state” so that it can be rolled back to in the event of an issue during subsequent changes.

Click “Backup and Restore” in the “Settings” menu.

NSX Manager 19

Click “Change” next to “FTP Server Settings”, then enter your FTP/SFTP server details here.  I actually don’t have an FTP server in my lab yet, so I’m going to forego a backup at this point.  I like to live on the edge anyway.  If you’d like to setup scheduled backups, there is an option to do so on this page as well…probably recommended for a production deployment.

NSX Manager 20

8. At this point, configuration of NSX Manager is complete and it has been linked to your vCenter Server.  You should now be able to log into the vSphere Web Client and continue with deployment of the remaining NSX infrastructure pieces.

If you’re currently logged into the Web Client, log out and then log back in and you should see a new “Networking and Security” panel.  Click on “Networking and Security”.

NSX Manager 21

It is from here that most of the NSX configuration will be managed and further NSX services and components deployed from.  The next post in this series will cover deploying and configuring the NSX Controllers.  Stay tuned and thanks for reading!

NSX Manager 22

 

Part 2:  Prepare Hosts and Deploy NSX Controllers is up!