VMware NSX

0.

VMware NSX is the leading network virtualization platform that delivers the operational model of a virtual machine for the network.
Just as server virtualization provides flexible control of virtual machines running on a pool of server hardware, network virtualization
with NSX provides a centralized API to provision and configure many isolated logical networks that run on a single physical network.

This demo depicts a company who wants to host a three-tier web application in the data center. Each tier is in a different Layer 2 network.
NSX will be utilized to provide routing, firewall, and load balancing services for the application needs across the datacenter,
which spans multiple VMware vSphere clusters.

[Click Networking & Security]

7.

This diagram shows the logical view of the VXLAN related configuration and the different NSX components.

8.

This diagram shows the NSX network topology of the logical switch with two Web Virtual Machines connected.

20.

Let's set up a logical network that spans all three of our VMware vSphere clusters so that NSX can provide
distributed routing, distributed firewall, and load balancing services.

[Click Logical Switches in the left pane.]

Please wait...

100.

Here, we will create a new logical switch that spans all of the hosts in our VMware vSphere Cluster. Since the logical switch spans
all of the hosts in our VMware vSphere Cluster, any virtual machines in those clusters will be able to take advantage of the
services that are offered by VMware NSX.

[Click the green '+' button in the top left under Logical Switches]

Please wait...

140.

Now we will give the new logical switch a friendly name and choose a transport zone for it to use. A transport zone has already
been set up that defines what clusters can utilize VMware NSX services.

[Hit any key to type 'Prod_Logical_Switch' or click the textbox to autocomplete]

160.

[Hit any key to type 'Prod_Logical_Switch']

340.

A Transport Zone defines which clusters can participate in the use of a logical network.

[Click Change next to Transport Zone]

Please wait...

380.

This transport zone that spans multiple clusters has already been defined.

[Click the radio button next to Global-Transport-Zone]

440.

[Click OK]

Please wait...

480.

[Click OK]

Please wait...

560.

The new logical switch has been created. We can now utilize the new logical switch to provide VMware NSX services.

[Click Prod_Logical_Switch]

Please wait...

600.

Now we will add an NSX Edge to the logical switch to provide the networking services (routing, firewall, and load balancing) that we need for our three tier application.

[Click the 'Add NSX Edge' button to the left of Actions]

Please wait...

670.

NSX Edge can be installed in two different forms: Distributed-Router and Perimeter-Gateway.

-The Edge Services gateway, named 'Perimeter-Gateway' provides network services such as DHCP, NAT, Load Balancer, Firewall, and VPN,
along with dynamic routing capability.

-The Logical Router, named 'Distributed-Router' supports distributed routing and dynamic routing.

[Click Perimeter-Gateway]

Please wait...

730.

[Click Next]

Please wait...

810.

Here we are just choosing the NSX Edge appliance interface to use for connectivity to the new logical switch that we created.

[Click vnic5]

Please wait...

870.

[Click Next]

Please wait...

940.

Now we will give the interface a friendly name, make sure it is connected, and define the IP address that this interface will use.

[Hit any key to type 'Prod_Interface' or click the textbox to autocomplete]

960.

[Hit any key to type 'Prod_Interface']

1090.

[Click the radio button next to Connected]

1140.

[Click the green '+' sign under configure subnets]

1160.

[Click the green '+' sign under Specify the Ip addresses in the subnet.]

1190.

[Hit any key to type '172.16.40.1' or click the textbox to autocomplete]

1210.

[Hit any key to type '172.16.40.1']

1310.

[Click the Subnet prefix length textbox]

1330.

[Hit any key to type '24', or click again to autocomplete]

1350.

[Hit any key to type '24']

1360.

[Click OK next to the IP address]

Please wait...

1420.

[Click OK]

Please wait...

1460.

[Click Next]

Please wait...

1510.

[Click Finish]

Please wait...

1600.

Now that the logical switch is created, and the NSX edge appliance has been configured and connected to the logical switch, we can
add some virtual machines so that they can take advantage of the network services provided by NSX.

[Click the 'Add Virtual Machines' button to the right of the red 'X' button]

Please wait...

1680.

We want to add our application tier web servers to the logical switch so we will filter the results on the word 'web.'

[Click the Filter textbox]

1690.

[Hit any key to type 'web', or click again to autocomplete]

1710.

[Hit any key to type 'web']

Please wait...

1780.

Our application tier servers are 'web-sv-03a' and 'web-sv-04a' so we will check the boxes to select them.

[Click web-sv-03a]

Please wait...

1840.

[Click web-sv-04a]

Please wait...

1900.

[Click Next]

Please wait...

2010.

The screen lets us define which virtual network interface cards (vNIC) from each virtual machine will be connected to the new
logical switch. Each virtual machine has only one vNIC, so we will choose those.

[Click the checkbox next to web-sv-04a]

Please wait...

2070.

[Click the checkbox next to web-sv-03a]

Please wait...

2130.

[Click Next]

Please wait...

2180.

[Click Finish]

Please wait...

2260.

Let's recap. So far we have created and configured a logical switch that spans multiple VMware vSphere clusters.We have added an
NSX Edge appliance to the logical switch to provide edge services to our virtual machines.
We have added two virtual machines to the new logical switch.
Next we will test the virtual machine network connectivity with some simple ping tests, from a putty terminal window.

[Hit any key or click anywhere to continue]

Please wait...

2510.

This putty session is connected to 'web-sv-03a'. We will ping 'web-sv-04a.' It's IP address is 172.16.40.12. Since the virtual
machines are on the same logical switch we expect the ping test to be successful.

[Hit Enter or click anywhere to continue]

Please wait...

2540.

The ping test was successful. The new logical switch connectivity is working.
Let's switch back to the vSphere Web Client window.

[Hit any key or click anywhere to continue]

Please wait...

2560.

Next let's take a look at NSX resiliency by simulating an NSX controller failure.

[Click 'Installation' in the navigation pane]

Please wait...

2650.

Note that there are three NSX controller nodes, each on a separate vSphere ESXi host.

[Click Home at the top left]

Please wait...

2690.

[Click VMs and Templates]

Please wait...

2860.

The virtual machine that is highlighted is one of the NSX controller nodes.
Let's simulate a node failure by shutting down the virtual machine.NSX should continue to provide connectivity and services to the
virtual machines that are connected to the new logical switch.

[Click Actions]

2880.

[Click 'Shut Down Guest OS']

2930.

[Click Yes]

Please wait...

2960.

Now that the NSX node is shut down, let's perform the ping test on 'web-sv-04a' again to verify connectivity. The connectivity
should still be working, even though we have experienced an NSX node failure.

[Hit any key or click anywhere to continue]

Please wait...

2980.

[Hit any key to type, or click anywhere to insert text]

2990.

[Hit any key to type]

3200.

[Hit Enter to continue]

Please wait...

3240.

As expected, connectivity is maintained even though an NSX node has failed.
The logical switch that we have created also offers dynamic routing between different networks.
Let's demonstrate this by performing a traceroute to the two internal application server virtual machines and the database virtual machine.
The two application servers and the database server are on different networks.
Since NSX provides dynamic routing, we should be able to successfully run a traceroute between our application servers and database server.

[Hit any key to type, or click anywhere to insert text]

3250.

[Hit any key to type]

3470.

[Hit Enter to continue]

3480.

As expected, the traceroute was successful.Next we will try the second application server.We should see similar results.

[Hit any key to type, or click anywhere to insert text]

3490.

[Hit any key to type]

3710.

[Hit Enter to continue]

Please wait...

3730.

The traceroute was successful.Next we will try the database server.We will expect similar results.

[Hit any key to type, or click anywhere to insert text]

3740.

[Hit any key to type]

3960.

[Hit Enter to continue]

3970.

Again, the traceroute is successful.
Now we have established communication between different tiers of the three tier application.
However, the communication between our three tiers is completely open.
Let's take a look at protecting our application with microsegmentation using the NSX distributed firewall service.
This allows us to protect any east-west network traffic that pertains to the application.

[Hit any key or click anywhere to continue]

Please wait...

4010.

[Click Home in the top left]

Please wait...

4060.

[Click Networking & Security]

Please wait...

4090.

[Click Installation]

Please wait...

4180.

[Click the Host Preparation tab in the middle pane]

4190.

[Click the Host Preparation tab in the middle pane]

Please wait...

4290.

With the NSX distributed firewall service, the firewall exists as a kernel module on each vSphere ESXi host. This ensures scalable
performance and management as each ESXi host applies the firewall policies defined centrally to the virtual machines that it hosts
locally.
Whenever a new host is added with the firewall enabled, more throughput is added, offering scalable, predictable performance and
policy application.

The distributed nature of the NSX firewall service is what allows the efficient security of east-west network traffic using
stateful firewall inspection rules.

[Hit any key, or click anywhere to continue]

Please wait...

4330.

Right now, the default firewall policy is set to accept all traffic as demonstrated by the following ping tests.
Since this is not ideal for the security of our three tier application,we will need to change that policy.

[Hit any key to type, or click anywhere to insert text]

4340.

[Hit any key to type]

4550.

[Hit Enter to continue]

Please wait...

4580.

The ping to 'web-sv-02' (IP 172.16.10.12) was successful, which is fine because 'web-sv-01' and 'web-sv-02' are in the Web Tier.
However, when we ping IP addresses in on different networks that reside in our Application Tier and Database Tier, we do not want
the ping to be successful.

[Hit any key to type 'ping -c 3 172.16.20.11' or click anywhere to insert text]

4590.

[Hit any key to type 'ping -c 3 172.16.20.11' or press tab to autocomplete]

4800.

[Hit Enter to continue]

Please wait...

4830.

The ping was successful, indicating that the communication is open. We will need to fix that.

[Hit any key to type 'ping -c 3 172.16.30.11' or click anywhere to insert text]

4840.

[Hit any key to type]

5050.

[Hit Enter to continue]

Please wait...

5080.

Again, the ping is successful, which is not the desired result.Let's switch back to the vSphere Web Client and modify the firewall
settings.

[Hit any key or click anywhere to continue]

Please wait...

5110.

[Click Firewall in the navigation pane]

Please wait...

5210.

We need to change the default rule to 'Block' so that traffic cannot travel between networks unchecked.

[Click Allow under the action column of the Default Rule]

Please wait...

5260.

We need to change the default rule to 'Block' so that traffic cannot travel between networks unchecked.

[Click Allow, then click Block]

5300.

[Click OK]

5330.

When we click the 'Publish Changes' button, every firewall node will receive the new ruleset.

[Click Publish Changes]

Please wait...

5420.

To make sure that the new rule is working, let's switch back to the putty session. We expect the communication to be blocked
between the different tiers now.

[Hit any key or click anywhere to continue]

Please wait...

5450.

In fact, the firewall rule is working. The firewall rule said to block all traffic, which is why the putty session has disconnected.
While we want to limit the type of traffic that will travel between the network tiers, we do want some types of
traffic to traverse the network between the tiers.
For example, we will want SSH to be able to traverse between the tiers so that we can manage our servers.
Let's apply some new firewall rules so that we can allow appropriate types of traffic to travel between the different network tiers.

[Hit any key or click anywhere to continue]

Please wait...

5470.

The web application is also not working at this point because no network traffic is allowed to travel between the different tiers.
We can verify by trying to load the web application in our browser.

[Click the 'New Tab' browser tab]

5490.

[Click the '3 Tier WebApp - Inline' bookmark]

Please wait...

5520.

[Click the 'vSphere Web Client' browser tab]

5540.

Before we can define new rules, we need to define the objects that those rules apply to. We could select each object (in this case
servers), one at a time and add them to the new rule, but we will take advantage of NSX Security Groups to ease the administrative
burden of managing objects.

[Click Service Composer in the Networking & Security navigation pane]

5550.

Before we can define new rules, we need to define the objects that those rules apply to. We could select each object (in this case
servers), one at a time and add them to the new rule, but we will take advantage of NSX Security Groups to ease the administrative
burden of managing objects.

[Click Service Composer in the Networking & Security navigation pane]

Please wait...

5600.

NSX allows us to create security groups with multiple objects so that policies can be applied to those objects.
In this case, we will create a security group that contains our external web servers so that a rule can be defined for the web
tier.

[Click the Security Groups tab]

Please wait...

5670.

[Click the New Security Group button]

Please wait...

5690.

[Hit any key to type, or click the Name field to insert text]

5710.

[Hit any key to type]

5800.

[Click Next]

Please wait...

5910.

Here, we can define dynamic group membership based on matching criteria, such as Operating System.
This ensures that any new virtual machine that is added to the infrastructure that matches the criteria has the firewall policies applied to it.

[Click Next]

Please wait...

6020.

[Click Security Group]

6050.

[Click the scroll bar down and click 'Virtual Machine']

Please wait...

6100.

[Click Filter]

6110.

[Hit any key to type 'web', or click again to insert text]

6130.

[Hit any key to type 'web']

6160.

Since web-sv-01a and web-sv-02a are the external web servers, we will add those virtual machines to the security group. If we add
any new external web servers in the future, we simply need to add them to this security group that we are creating so that the
firewall rule will apply to the new virtual machines.

[Click web-sv-01a]

6220.

[Click the blue arrow in the middle]

Please wait...

6260.

[Click web-sv-02a]

6300.

[Click the blue arrow]

Please wait...

6340.

[Click Finish]

Please wait...

6530.

Now we can create a firewall policy that applies to the new security group that we just created.
All of the firewall rules that we will be creating will be used for stateful packet inspection.

[Click 'Firewall' in the navigation pane on the left]

Please wait...

6560.

We will add a new section, so that we can keep the default section intact. It also allows us to group similar rules together more
easily. In this case we will create a new section that will group all of the firewall rules required for our three tier web
application.

[Click the 'Add New Section' button - at the far right by the green '+' sign]

6630.

Let's give the new section a friendly name.

[Hit any key to type '3-Tier App', or click the textbox to insert text]

6650.

[Hit any key to type]

6740.

[Click OK]

Please wait...

6790.

[Click Publish Changes]

Please wait...

6850.

Now we will add a new rule to define communication coming to the web tier.

[Click the green '+' sign on the right in the 3-Tier App section]

Please wait...

6880.

[Click the 3-Tier App Section]

6890.

[Click the empty box in the 'Name' column]

6950.

Let's give the rule a friendly name so that we can quickly identify what this rule is allowing.
In this case, we are allowing external traffic to travel to the web servers because the external web servers
will be hosting the web page for our three tier web application.

[Hit any key to type, or click the textbox to insert text]

6960.

[Hit any key to type]

7140.

[Click OK]

Please wait...

7180.

[Click in the Destination column]

7200.

We will select the Web-Tier security group so that any machine in that security group will be added to this firewall rule.

[Click the 'Object Type' dropdown box]

Please wait...

7230.

[Click the scroll bar down and click 'Security Group']

Please wait...

7300.

[Click Web-Tier]

7350.

[Click the blue arrow]

Please wait...

7400.

[Click OK]

Please wait...

7440.

Now we need to define what traffic types we want to allow to our external web servers.

[Click in the Service column]

Please wait...

7500.

[Click Filter]

7510.

[Hit any key to type 'https', or click again to insert text]

7530.

[Hit any key to type 'https']

7580.

[Click HTTPS]

7630.

[Click the blue arrow]

Please wait...

7670.

[Click the textbox that reads 'https']

7680.

[Hit any key to type 'ssh', or click again to insert text]

7700.

[Hit any key to type 'ssh']

Please wait...

7730.

[Click SSH]

Please wait...

7770.

[Click the blue arrow]

7790.

[Click OK]

Please wait...

7830.

The rule that we just defined states that SSH and HTTPS traffic coming from any source may travel to the virtual machines that
reside in the external web tier. This is defined by the security group that we configured.
Next we will add another rule to allow network communication from the web tier to the application tier.

[Click in the first column by the number 1]

7850.

[Click 'Add Below']

Please wait...

7910.

[Click in the Name column]

7930.

Again, we will give the rule a friendly name that will allow us to quickly identify what the rule does.

[Hit any key to type 'Web-Tier to App-Tier', or click the textbox to insert text]

7940.

[Hit any key to type 'Web-Tier to App-Tier']

8130.

[Click OK]

Please wait...

8180.

[Click in the Destination column]

8200.

We have already defined a separate logical switch for the application tier. The application tier virtual machines are already
attached to that logical switch.
So now we will allow network traffic to move from the web tier to any virtual machine attached to the App-Tier-01 logical switch.

[Click the 'Object Type' dropdown box]

8220.

[Click Logical Switch]

Please wait...

8410.

[Click the blue arrow]

Please wait...

8450.

[Click OK]

Please wait...

8490.

[Click in the Service column]

8505.

Since, our application uses custom TCP ports to communicate, we will need to define a new service.
Here, we can create a new service that defines the network traffic characteristics of our application.

[Click 'New Service...']

8530.

[Hit any key to type 'MyApp', or click the textbox to insert text]

8550.

[Hit any key to type 'MyApp']

8590.

[Click the dropdown box that says AARP]

8640.

[Click the scroll bar down and click TCP]

8670.

[Click the Destination Ports textbox]

8680.

In this case the application uses TCP port 8443 to communicate with the web tier.

[Hit any key to type '8443', or click again to insert text]

8700.

[Hit any key to type '8443']

8730.

[Click OK]

Please wait...

8850.

[Click OK]

Please wait...

8900.

Finally, we will create a rule that allows network traffic to flow from the application tier to the database tier.

[Click the number 2 in the 'No.' column]

8920.

[Click Add Below]

8960.

[Click in the Name column]

8980.

[Hit any key to type 'App-Tier to DB-Tier', or click the textbox to insert text]

8990.

[Hit any key to type 'App-Tier to DB-Tier']

9170.

[Click OK]

Please wait...

9200.

[Click in the Source column]

Please wait...

9230.

In this rule, the only source allowed is traffic coming from virtual machines attached to the App-Tier-01 virtual switch. So the
network traffic defined in this rule will flow from the application tier to the database tier.

[Click the 'Object Type' dropdown box]

9250.

[Click Logical Switch]

Please wait...

9350.

[Click App-Tier-01]

9400.

[Click the blue arrow]

Please wait...

9430.

[Click OK]

Please wait...

9480.

[Click in the Destination column]

9500.

[Click the 'Object Type' dropdown box]

9520.

[Click 'Logical Switch']

Please wait...

9580.

[Click DB-Tier-01]

9630.

[Click the blue arrow]

Please wait...

9670.

[Click OK]

Please wait...

9730.

[Click in the Service column]

9770.

We want MySQL traffic to flow between the application tier and the database tier. So we will add the MySQL traffic type here.

[Click Filter]

9780.

[Hit any key to type 'my', or click again to insert text]

9800.

[Hit any key to type 'my']

9820.

[Click MySQL]

9870.

[Click the blue arrow]

Please wait...

9900.

[Click OK]

Please wait...

9940.

[Click Publish Changes]

Please wait...

9990.

Let's recap on what we have done with the distributed firewall.
We have defined a rule that says any source may communicate with virtual machines in the external web tier, but only using HTTPS
and SSH traffic.
We have defined a rule that defines the traffic type that can travel to the application tier.
Finally, we have defined a rule that says MySQL traffic coming from the application tier may travel to the database tier.
Now, let's take another look at our web application. We expect it to function properly.

[Click the 'Problem loading page' browser tab]

10010.

Again, the firewall rules that we have just created will allow the following traffic flows:
-Any source to the Web Tier
-The Web Tier to the Application Tier
-The Application Tier to the Database Tier

Each tier can only communicate with the tier it needs to and the services in each tier are isolated from any other traffic.
The web application should now work correctly.

[Click the '3 Tier WebApp - Inline' bookmark]

Please wait...

10070.

The firewall rules are working and now our web application functions properly.
The firewall rule should also allow us to connect with SSH to the web servers.
Let's reconnect to 'web-sv-01' to test this out.

[Hit any key or click anywhere to continue]

Please wait...

10100.

[Click OK]

Please wait...

10130.

[Click the top left corner of the putty window]

10140.

[Click Restart Session]

Please wait...

10170.

[Hit any key to type 'root', or click anywhere to insert text]

10180.

[Hit any key to type 'root']

10210.

[Hit Enter to continue]

10220.

[Hit any key or click anywhere to continue]

10290.

The firewall rule worked. We are able to log into 'web-sv-01' via SSH.
Only the traffic types that we have defined in the firewall rules will be allowed to travel between tiers. Everything else should
be blocked.
Let's perform a few ping tests to test this out. We should not be able to ping any of the other servers. This also includes the
other web server in the web tier because we set up the rule to only allow HTTPS and SSH traffic travel to the web tier).

[Hit any key to type 'ping -c 3 172.16.10.12' or click anywhere to insert text]

10300.

[Hit any key to type 'ping -c 3 172.16.10.12']

10510.

[Hit Enter to continue]

Please wait...

10530.

[Hit any key to type 'ping -c 3 172.16.20.11' or click anywhere to insert text]

10540.

[Hit any key to type 'ping -c 3 172.16.20.11']

10750.

[Hit Enter to continue]

Please wait...

10770.

[Hit any key to type 'ping -c 3 172.16.30.11' or click anywhere to insert text]

10780.

[Hit any key to type 'ping -c 3 172.16.30.11']

10990.

[Hit Enter to continue]

Please wait...

11010.

As expected, none of the ping tests were successful. This is the desired behavior.
Next we will return to the vSphere Web Client.

[Hit any key or click anywhere to continue]

Please wait...

11030.

[Click the vSphere Web Client tab]

11060.

This web application is on the company intranet and it should only be accessed by certain users.
We need to adjust the source in the External to Web-Tier rule to account for this.
The NSX firewall rules give us the flexibility to define the source using many different object categories.
In this case, we will define the source as a Security Group containing active directory users in the Sales Department.

[Click in the Source column of rule 1]

11110.

[Click the 'Object Type' box]

11140.

[Click the scroll bar down]

11150.

[Click 'Security Group']

Please wait...

11230.

We will add the active directory sales users to the rule. The 'AD_Sales' active directory group has already been defined for us.

[Click AD_Sales]

11240.

We will add the active directory sales users to the rule. The 'AD_Sales' active directory group has already been defined for us.

[Click AD_Sales]

11280.

[Click the blue arrow]

Please wait...

11310.

[Click OK]

Please wait...

11360.

[Click 'Publish Changes']

Please wait...

11420.

Now let's log in to a virtual machine on the intranet and see if the rule is functioning correctly.
If we log in as a non-sales user, we do not expect the web application to function properly.

[Click the 'iis-w-01a' browser tab]

Please wait...

11450.

[Click the 'Send Ctrl-Alt-Delete' button]

Please wait...

11500.

First, we will log in as a user that is not a member of the sales team.

[Hit any key to type, or click the Password field to insert text]

11520.

[Hit any key to type]

11590.

[Click OK]

Please wait...

11690.

[Click 'Internet Explorer']

Please wait...

11770.

[Click the 'NSX HOL - Multi-Tier App' bookmark]

Please wait...

11890.

As expected, the application does not work since we are logged in as a user that is not a member of the sales team.

[Click the 'Send Crtl-Alt-Delete' button]

Please wait...

11970.

[Click 'Log Off...']

Please wait...

12110.

Now we will log in as a sales user. We expect the web application to function properly as we will be logging in as a member of the
active directory 'AD_Sales' group that we defined in the firewall rule.

[Click the 'Send Ctrl-Alt-Delete' button]

Please wait...

12150.

[Click the 'User name' textbox]

12170.

Now we will log on as a member of the sales team.

[Hit any key to type 'sales1', or click again to insert text]

12190.