New role within VMware

I’ve been working at VMware for just over a year now, and trust me when I say this, time has literally flown by.  I made the move last year from being a customer to working for a vendor and I’ve never looked back.  I’ve spent the last year working as a partner SE working with four of the premier partners based out of the North of England.  This was a great role which allowed me to learn how the whole partner and vendor landscape works and also work with a lot of technical guys on a daily basis both within VMware and my aligned partners.
 

You may have noticed over the last few months an increase in posts relating to NSX.  There was no particular reason for this, it was just a new product that I knew would change the way we provisioned and consumed network services in the future and I wanted to understand the product for my own personal knowledge but also to pass this knowledge onto partners, co-workers and the wider VMware community.  This hadn’t gone unnoticed and I was recently presented with the opportunity to take on a new role as an NSX Specialist in the UK.  Being a partner SE was a great start but I’ve always liked the idea of specialising in a particular product so you can be one of the experts in that particular field.  I don’t come from a 100% networking but I do have a fair bit of experience from my customer days which is a great start.  There are a lot of very clever people working within the Networking and Security Business Unit (NSBU) at VMware and I’m looking forward to learning from everyone as well as helping customera and partners understand what Software Defined Networking is and how it can benefit their organisation and customers.  It’s going to be a steep learning curve but one which I’m thoroughly looking forward to.

Integrating NSX with Active Directory and creating Identify-Based Firewall Rules

NSX has the ability to integrate with Active Directory and allow you to create security groups based on user identity, create identity-based firewall rules, and run Activity Monitoring reports.  In this post I'm going to show you how you can integrate NSX with Active Directory and then create a security group within NSX that only allows users to SSH into all Linux VM's that are in the Allow SSH Active Directory Security group.  First step is to configure NSX to query Active Directory for user / group information as well as query the security logs to map usernames to IP addresses.  Browse to the NSX Manager plugin, select your NSX Manager and click on the Domains tab:

Click on the green plus icon to add a new domain.  Specify the name of the domain and the NetBios name and click Next:

Specify your domain controller name and a username and password that can query LDAP information and click Next:

Specify the username and password for an account that has access to view the event logs and click Next (for testing purposes I'm using a domain admin account):

Finally verify your settings are correct and click Finish:

NSX should now start pulling in user and group information from Active Directory and also monitoring the security logs for logon / logoff events.  It may take a few minutes for the refresh to take place, take this time to grab a coffee and a few biscuits:

Now I'm going to create a few user account and security groups within AD for testing purposes.  The security groups and user accounts are called:

Allow SSH - SG - D (Domain Local Security Group)

Allow SSH - SG - G (Global Security Group)

Allow_SSH_User

No_SSH_User

The Allow SSH - SG - G is going to be a member of the Allow SSH - SG - D as I like to follow best practises for multi-domain environments.  The Allow_SSH_User is going to be a member of Allow SSH - SG - G which means he is also going to be a member of Allow SSH - SG - D.  I will then add the Allow SSH - SG - D to a security group object within NSX which I can then add to a firewall rule but we will cover that off later.  The No_SSH_User will not be a member of any groups.  Once everything is in place the idea is that when I log into a domain member workstation as Allow_SSH_User I should be able to SSH into my linux VM's, when I log in as No_SSH_User I should NOT be able to SSH into my linux VM's.

Here are my security groups and user accounts:

It's best to quickly update the Active Directory objects within NSX by going back to the Domains tab and clicking on the double cog icon and verifying the update has occurred by checking the last sync status:

Now we need to create the security group within NSX that will point to the Active Directory group called Allow SSH - SG - D (Which contains Allow SSH - SG - G and thus the Allow_SSH_User).  Within the NSX Manager configuration screen select the Grouping Objects tab.  I already have some groups that dynamically adds VM's to specific groups.  Click on the green plus arrow to create a new group:

Give the new group a name and click Next:

Remove the dynamic membership criteria as we will be statically assigning the resource and click Next:

Change the object type to Directory Group and select the group you require and click Next.  In my case its Allow SSH - SG - D:

We don't want to exclude any resources so just click Next

Finally verify everything is correct and click Finish:

We can now see the newly created NSX group:

Finally we need to edit the ruleset to only allow the Allow SSH NSX security group permission to SSH to the Linux VM's.  My current ruleset allows anything to SSH into the Linux VM's:

If you hover over the source field a plus icon will appear.  Click it and then change the Object Type to Security Group (Remember these are NSX Security groups) and click the arrow to move it across to the Selected Objects box and click OK:

Publish the changes and the ruleset is now active:

Time for testing.  I logged into my jumpbox workstation as Allow_SSH_User and successfully opened a putty session to WEB01:

I then logged in as No_SSH_User and was unable to connect to WEB01:

How impressive is that.  Stay tuned for the next thrilling installment

Configuring Spoofguard in NSX

NSX includes Spoofguard which allows you to authorise IP addresses reported by VMware tools running inside a virtual machine.  You can configure multiple policies for a different networks (Logical Switches and Distributed Port Groups) depending on your requirements.  If Spoofguard is enabled you will not be able to communicate with a VM until the IP address has been approved (Either automatically or manually)

Spoofguard is configured via the NSX plugin in the vSphere Web Client and by default it's disabled so traffic to all VM's is allowed.  You can see a list of active vNIC's and which IP addresses (IPv4 and IPv6) are associated with those VM's:

In order to enable Spoofguard across all networks simply edit the Default Policy and check the Enabled option.  You then have two options to either automatically trust IP assignments on their first use which basically will automatically approve the first IP address of the VM.  You also have the option to manually inspect and approve all IP assignments before use which basically means that you have to approve all IP addresses before you can establish connectivity with them.  In this example I'm going to manually approve all IP address assignments.  Once finished click Finish:

Don't forget to Publish Changes:

Once configured you should loose connectivity to all VM's.  I've sent a continuous ping to my test WEB01 VM (192.168.0.11) and as you can see, once spoofguard was enabled it stopped responding to pings:

We can also see that Active Virtual NICs view is empty:

If we change the view to Virtual NICs IP Required Approval we can see a list of all NICs that we need to approve.  If we configured the default policy with the automatically trust IP assignments on their first use then these would have been pre-approved but subsequent IP changes would require manual intervention:

Once I approve the WEB01 IP address and Publish the changes connectivity is restored:

If the IP address were to change then VMware tool would detect this and you would have to approve the new IP address.  In this example I changed the IP address of the VM from 192.168.0.11 to 192.168.0.19:

If you only wanted Spoofguard enabled on a particular Logical Switch or Distributed Port Group such as a DMZ then you can set the default policy to disabled which will trust all IP addresses.  You can then enable Spoofguard for a particular network which requires approval of all IP address changes.  To create a new policy simply click the green plus icon and give the new policy a name and set the required policy.  In this example I want Spoofguard on the DB network to be enabled and all IP address changes manually approved.  Click Next when ready:

Finally click the green plus icon and add the required Distributed Port Group or Logical Switch that you want to enable Spoofguard for.  You can add multiple networks to same policy if you wish.  Once finished click Finish and don't forget to Publish the changes:

We can now see the new policy and all the VM's that require their IP address approved before you can communicate with them:

Hope this helps with understanding Spoofguard a little more and how to configure it within NSX

Configuring DHCP Relay in NSX

One of the new features with NSX 6.1 is the ability to configure DHCP Relay on a Distributed Logical Router.  Before NSX 6.1 in order to use DHCP you had to have a DHCP server directly attached to each subnet.  Chris Wahl (Blog | Twitter) has a great article about all the new NSX 6.1 features.  To configure DHCP relay you must be running NSX 6.1 and ensure that all your Distributed Logical Routers are running at least version 6.1.  The first thing you need to do is ensure that you have the required scope with options configured on your DHCP server.  In my example I have an APP01 VM on the 192.168.1.0/24 network that is currently assigned a static IP address of 192.168.1.11 which I'm going to configure to use DHCP.  I've already configured the required DHCP scope as per below:

In order to configure DHCP Relay simply browse to the Distributed Logical Router that is connected to the network that you want to enable DHCP Relay for and browse to the DHCP Relay tab:

Click the Edit option and enter the IP address of the DHCP server that you want to forward DHCP request packets to and click OK:

In the DHCP Relay Agents section click the green plus icon and select the network that you want to relay DHCP request packets for and click OK.  In my example I'm using the Tenant-01-App-Tier:

Verify all details are correct and click Publish Changes:

Ensure the VM on the network is configured for DHCP, renew the lease and then check the DHCP server to ensure that a lease has been give out:

DHCP Relay has now been configured on the 192.168.1.0/24 network.

Upgrading to NSX 6.1

In this article I'm going to go through the steps of upgrading my nested NSX test lab from version 6.0.4 to 6.1  Chris Wahl (Blog | Twitter) has a great article with what's new in NSX 6.1.  First step is to download the NSX 6.1 upgrade bundle from the VMware site:

Once it's downloaded log into the NSX Manager admin page and browse to the Upgrade section:

Click on the Upgrade button and choose the upgrade bundle that you just downloaded and click Continue:

The upgrade bundle should start uploading.  This will take a few minutes:

Once the bundle has uploaded click Continue.  The upgrade process warns you to ensure you have taken a snapshot prior to the upgrade.  Once you are ready, click Upgrade:

Once the process starts you can monitor its progress:

Once the upgrade process has completed the NSX Manager VM will automatically reboot and take you back to the login screen.  Once you log back in and go to the Upgrade section you should see it completed successfully and that it's now running at version 6.1:

Now that the NSX Manager is running at version 6.1 it's time to upgrade all the controllers and Edges.  Since this is a test lab I only have one controller VM so as long as there are no vMotions within my lab I should not have any connectivity issues.  To upgrade the controller VM log into the vSphere Web Client and navigate to the NSX Manager plugin and then click on the Installation menu item:

Click on the Upgrade Available link and then Yes to upgrade the NSX controllers:

If you refresh the vSphere Web Client you should see the installation in progress and then eventually the controller rebooting:

Once the controller has rebooted it should also be at version 6.1.  

Next were going to upgrade the network virtualization components on the hosts.  Browse to the Installation tab and click update:

The VIBS on each ESXi host should update to 6.1 and show as Ready:

The final step is to upgrade any Edges that you have within your environment.  In my lab I only have two so this should be nice and easy.  As you can see, they are both at version 6.0.4:

To upgrade the Edges simply select one, click on the Actions menu and then Upgrade Version

Finally click Yes to confirm:

Once all Edges are upgraded they should show version 6.1:

The steps above shows you how to upgrade to NSX 6.1 without any issues.  During my upgrade I did have issues upgrading the Edges but I think this was because I hadn't upgraded the hosts prior to the Edges.  Ultimately I ended up re-creating the Edges but if I had RTFM I don't think I would have encountered any issues.  Also, remember to disable any firewall rules that block L2 connectivity between two VM's before testing :)

That's the upgrade complete, have yourself a well deserved cup of tea and go explore some of the new features.