VMware Hands-on Labs - HOL-PRT-1462


Lab Overview - HOL-PRT-1462 - Palo Alto Networks Next-Generation Security Platform with VMware NSX

Lab Guidance


How do you accelerate the deployment of business-critical applications without compromising security? How do you define dynamic security policies to protect against advanced threats while keeping pace with data center virtualization? VMware and Palo Alto Networks have partnered to deliver a solution that combines fast provisioning of network and security services with next-generation security in the data center. In this lab, learn how to configure the Palo Alto Networks virtualized next-generation firewall VM-1000-HV with VMware NSX to secure VM to VM communications.

Network virtualization provides speed and flexibility when provisioning network and network services in the virtualized datacenter. But what is more important than speed and flexibility when provisioning such virtualized networks?  Security and the securing of your virtualized networks!

Securing your VMs, your databases, your webservers, your file servers, and your data stores should be of paramount importance to you, and to the reputation of your company. Therefore, here within this hands-on-lab, you will learn how to do just that using the latest in next-generation enterprise security – The Palo Alto Networks VM-Series Firewall platform as integrated with VMware NSX.

Throughout this lab we will demonstrate how to secure the datacenter using the Palo Alto Networks virtualized next-generation firewall VM-1000-HV with VMware NSX protecting VM to VM communications from today’s advanced threats.


Palo Alto Networks VM-Series and VMware NSX Dynamic Security Policy Configuration

Module Descriptions


Module 1: Creating Dynamic Next-generation Policy for Securing a Virtualized Data Center (30 Minutes)

 Module 2: Integrating Palo Alto Networks Next-generation firewalls with NSX Security Groups and Traffic Steering (45 Minutes)

Module 3: Using Distributed FireWall (DFW) to Protect Intra-tier Traffic (30 Minutes)

 Lab Captains: Warby Warburton/ Francis Guillier


Key Concepts and Terms

Some Components and Concepts of Vmware and Palo Alto Networks


Before jumping into either module it will be helpful to learn more about some of the key components, concepts and terms that you will be working with.  So at this time let's make sure we understand what these are.  


 

VMware NSX

 

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.

Logical networks decouple virtual machine connectivity and network services from the physical network, giving cloud providers and enterprises the flexibility to place or migrate virtual machines anywhere in the data center while still supporting layer-2 / layer-3 connectivity and layer 4-7 network services.

 

 

VMware NSX Service Composer

When defining a Security Group, a user can select between dynamic inclusion, static inclusion and static exclusion.

A Dynamic inclusion provides the capability to automatically include objects based on the VM Name or Security Tag.

A Security Policy (SP) defines the network and security policy to be applied for a particular Security Group (SG). For instance, a Security Policy can be created to define traffic redirection to the Palo Alto Networks VM-Series firewall for all types of traffic (i.e. all TCP or UDP ports) [traffic from a user defined SG to a specific SG]. To make this Security Policy operational, the next and last step is to attach the Security Policy to a Security Group or to a set of Security Groups.

 

 

 

VMware NSX Distributed FireWall (DFW)

VMware NSX DFW is a distributed L2-L4 firewall component provided within the NSX solution. It provides stateful firewalling capability down to each vNIC of a VM and operates at the hypervisor kernel layer delivering near line rate performance. Global management of DFW is performed though the vCenter UI under the NSX Home tab.  Security Policy policy rules can be written using vCenter objects like VM, cluster, DVS port-group, logical switch and so on. NSX DFW fully supports vMotion and current active connections remain intact during the workload mobility event.

NSX DFW is a key component of micro segmentation.

VMware NSX Service Composer is a framework containing 2 major constructs: Security Groups and Security Policy.

Security Group (SG) is a container that can include any vCenter objects like VM, cluster, logical switch, vAPP, DVS and port group.

 

 

 

Decoupled Logical Networks

 

Decoupled logical networks consist of a physical network and a virtual network. Within each you will find a number of networks, sub-networks, servers and systems. In our case here we are viewing one physical network made up of 3 subnets that is decoupled by VMware NSX from 2 virtual networks.  

 

 

Palo Alto Networks VM-1000-HV

 

This VM-Series NSX edition firewall is jointly developed by Palo Alto Networks and VMware. This solution uses the NetX API to integrate the Palo Alto Networks next-generation firewalls and Panorama with VMware ESXi servers to provide comprehensive visibility and safe application enablement of all datacenter traffic including intra-host virtual machine communications.

Logical networks decouple virtual machine connectivity and network services from the physical network, giving cloud providers and enterprises the flexibility to place or migrate virtual machines anywhere in the data center while still supporting layer-2 / layer-3 connectivity and layer 4-7 network services.

The VM-1000-HV is deployed as a network introspection service with VMware NSX and Panorama. This deployment is ideal for east-west traffic inspection, and it also can secure north-south traffic.

 

 

Panorama by Palo Alto Networks

 

Your Palo Alto Networks Panorama enables you to manage your distributed network of physical and/or virtual Palo Alto Networks firewalls from a centralized location while providing the ability to: View the traffic of each deployed firewall; manage all aspects for device configuration; push global policies; and generate reports on traffic patterns or security incidents, all from one central location.

Panorama is available as either a dedicated management appliance or as a virtual machine.

 

 

The Palo Alto Networks Operating System (PAN-OS)

 

The PAN-OS by Palo Alto Networks is the software managing the computer hardware and software resources of the Palo Alto Networks Next-generation firewall.  In addition, the PAN-OS provides a long list of functions, features, and services to ensure a safe and secure environment. The PAN-OS is the same OS used throughout all Palo Alto Networks firewalls.

 

 

 

 

Dynamic Address Groups

Provide the ability to maintain awareness of changes in the virtual machines/applications and ensures that security policy stays in tandem with the changes in the network. This awareness provides visibility and protection of applications in an agile environment. This is made possible because Dynamic Address Groups are used as a source or destination object within security policies. Additionally, because IP addresses are constantly changing in a datacenter environment, Dynamic Address Groups offer a way to automate the process of referencing source and/or destination addresses within security policies. Unlike static address objects that must be manually updated in configuration and committed whenever there is an address change (addition, deletion, or move), Dynamic Address Groups automatically adapt to these changes.

 

 

Lab Components and Topologies

Lab Components


At times you will need to enter commands, usernames, and passwords using Command Line Interface (CLI) commands. Therefore, a text file named “README.txt” has been placed on the desktop of the environment so that you can easily reference these commands which will allow you copy and paste complex commands or passwords in the associated utilities CMD, Putty, console, etc., as necessary.  

This README.txt file is divided into Module Sections and numbered. The manual will have a number associated with every CLI command. That command will be numbered in the README.txt file for you to copy and paste.

Certain characters are often not present on keyboards throughout the world. This README.txt file also includes keyboard layouts which do not provide those characters.

Thank you and enjoy the labs!


Lab Topologies


The following diagrams illustrate physical and logical topologies implemented for this Lab:


 

Physical Topology

 

2 ESXi clusters will be deployed: Cluster site A and Mgmt Cluster.

Cluster site A is a compute cluster where workloads will be instantiated and connected to a logical switch. VMs from HR and Legal organizations will be deployed there.

Mgmt Cluster is a management cluster where control plane components of NSX will be instantiated. NSX controller is typically hosted there (NSX controller controls VXLAN operations on compute clusters).

 

 

 

 

Logical Topology for HR Organization

 

3 VMs from HR organization (2 web servers and 1 DB server) are instantiated and connected to the same logical switch (VXLAN).

Traffic protection is enforced as following:

-Inter-tier traffic (web server to DB server) is protected by the Palo Alto Networks VM-series firewall which provides advanced security capabilities with its single pass architecture in the form of App-ID, Content-ID, User-ID.

-Intra-tier traffic (web server to web server) is protected by NSX DFW which provides near line rate performance L2-L4 security functions.

 

 

 

Logical Topology for Legal Organization

 

3 VMs from HR organization (2 web servers and 1 DB server) are instantiated and connected to the same logical switch (VXLAN).

Traffic protection is enforced as following:

-Inter-tier traffic (web server to DB server) is protected by the Palo Alto Networks VM-series firewall which provides advanced security capabilities with its single pass architecture in the form of App-ID, Content-ID, User-ID.

-Intra-tier traffic (web server to web server) is protected by NSX DFW which provides near line rate performance L2-L4 security functions.

 

 

Module 1: Palo Alto Networks VM-Series and VMware NSX dynamic security policy configuration (30 Min)

Module 1 Overview: Palo Alto Networks VM-Series and VMware NSX dynamic security policy configuration (30 minutes).�


During this first lab you will focus on how to create dynamic security policies on the Palo Alto Networks VM-1000-HV based on context from VMware NSX. Specific tasks will include: 

To successfully complete this module you will need to identify and correct ill configured settings within your policies, tags, and/or grouping.  

Let's begin! 


Environment Setup


vCenter Login: Let's make sure our environment, and all its systems, are up and running by checking within vCenter.  To do so launch and login to vCenter.    


 

vSphere Web Client to access vCenter

 

To login into vCenter, find and launch your vCenter desktop icon as identified by the globe icon.   When the VMware vSphere Web Client Login box is displayed, login with the credentials:

            Username = root

            Password = VMware1!

Please note: If this is your first time logging into vCenter for this lab, the login process may take several minutes as modules are initially loaded. During this wait time please be patient. It should also be noted that subsequent logins to vCenter will be much quicker going forward.

 

 

 

 

 

vSphere Web Client to access vCenter

 

When logged into the vSphere web client, to view your datacenter 1) click on the Home tab and then select 2) Hosts and Clusters.

 

 

vCenter View

 

1) Expand your tree view on the left side of your screen so that you can see a listing of all of your virtual systems running within your "vcsa-01a" Datacenter Site A.

At this time take a moment to check the status of your VMs to make sure each are up and running. Each of the high-lighted systems above should have an illuminated green arrow indicating the specified system is up and running.  

Please Note: It is very likely that your Tree view listing is slightly different than what you see here. If so, that is ok. The other VMs you are seeing will be used later during the last lab found in Module 3. At this time we are just checking to make sure all of our virtual systems are up and running as reflected by the green arrow preceding the name of each virtual system. Once that is done please continue ignoring the other VMs listed.

 

 

Examining the NSX Security Groups within NSX Manager


We want to find out what Security Groups already exist and so let's navigate into Networking & Security to check.


 

Networking & Security

 

1) Go back to the "Home" page and then 2) click on "Network & Security" from either the left menu tree panel, or from the "Inventories" section of the Home tab.

 

 

 

Security Groups

 

1) From the left tree panel click on "Service Composer" and then select "Security Groups" tab in the center.

Notice we have two specific Security Groups for our HR Team servers.  These are our HR-DB-Servers security group for the database servers and a HR-Web-Servers Security Group for the web servers. We've now confirmed our Security Groups. At this time go ahead and minimize your browser page and proceed to the next step.

 

 

 

Examine your Dynamic Address Groups


It's now time to introduce you to Panorama by Palo Alto Networks. As previously mentioned, Panorama provides centralized management for all of your physical and/or virtual Palo Alto Networks firewalls.  Panorama itself is available as either a dedicated management appliance or as a virtual machine.

Let's login to Panorama so that we can take a look at our Dynamic Address Groups. To do so go to your desktop to find and launch the Panorama desktop icon.

 


 

Panorama Login

 

After launching the "Panorama" desktop icon, your browser will display the Panorama login screen.  The credentials to login are:

              Username = admin

              Password = VMware1!

 

 

 

Panorama Dashboard > Objects Tab

 

Once logged into Panorama you'll be taken to the "Dashboard" view.  Among your menu tabs at the top you'll have an "Objects" tab. Click on this tab to view your Address Groups.

 

 

Address Groups

 

Select "Address Groups" from the left tree panel and then click on "HR-Web-Servers" from under the Name column.  After doing so you will launch the settings display box.

 

 

 

 

Address Group Settings

 

Notice the NSX Security Group name is listed as "HR-Web-Servers-securitygroup-10" within your "Match" value display.  Panorama learned this NSX Security Group information automatically from the NSX Manager.

Now that we've verified the Address Group settings, click "Cancel" to exit without making any changes.  

 

 

Examine the Security Policies


Security policies play a crucial role on firewalls.  As you know, these security policies state what can and cannot traverse the firewall. Applications like ping, SSH, FTP, etc., (among many others), going to and from various zones, while running on various ports, can be permitted or denied.  So let's take a look at what security policies we have in place here within our environment.  


 

Policies Tab > Security Pre Rules

 

While still logged into Panorama, let's now examine your security policies.  To do so click on the 1) Policies tab.  Then 2) make sure you're viewing the Pre-Rules of your Security policies from the left tree panel.  Then looking to the right under the "Name" column notice you have three policies.  Verify you have a policy rule for your HR web-server to HR database server traffic. This rule is called "HR Web to DB".  Familiarize yourself with this rule by looking at the field headers for each of the configurations.  Notice your Source and Destination Address settings and that this policy allows mysql traffic between the two. 

Let's now do some testing of these rules by generating some traffic. So without making any changes here please move on to the next step.

 

 

Generate Traffic from your Web Server to the Database


At this time we're ready to do some testing.  We can do so by generating certain types of traffic from our Web server to our Database server.  

Since we've just checked our security policies, we already know the types of traffic that will be allowed, or denied, between these two servers.  So let's generate some traffic, testing to make sure everything works as expected. If so, great!  But if not, well then we'll need to troubleshoot to find out why our tests failed, and once we know the reason why we'll need to implement the solution to resolve.


 

Generating Traffic from hr-web-01

 

To generate some traffic let's begin by logging into the web server using "putty.exe".  You'll notice we already have a desktop icon for you and so simply click on the "hr-web-01" desktop icon to do so.  

You will be logged in automatically as the username and password have been entered and saved for you.  In the event you need to manually enter the username and password to login, please see the README.txt file on the desktop for the credentials.

 

 

 

Generate Traffic - ping Test.

 

Now that we are logged into our HR webserver let's attempt to ping our HR database using the "ping -c 5 hr-db-01" command.  

Notice our ping to the HR database server is successful.  We are now going to check the VM-Series traffic logs to confirm the traffic was steered to the firewall.  To check these traffic logs we'll need to go back into Panorama again and so to do so click on your Panorama browser tab again.    

 

 

Checking the Logs within Panorama

 

Access your browser tab again and click on the Panorama tab.  If prompted for credentials use "admin" and "VMware1!" for the username and password.

 

 

Monitoring the Logs

 

1) From within Panorama click on the "Monitor" tab followed by the 2) "Traffic" tab under "Logs".  3) Next adjust your log filter to reflect "Last 15 Minutes" by using the circled drop down arrow.  This way we will be sure that we are filtering from view any logs older than the previous 15 minutes.

Notice our logs are empty even though we generated traffic via our successful PING test.  This indicates our traffic was not successfully steered to and through our VM-Series firewall.  We’ll need to find out why and so let's troubleshoot to find out and then let’s implement the resolution.

 

 

Troubleshoot Traffic Steering Problem


We need to determine what is preventing our VM-Series firewall from seeing the traffic generated by our PING test.  So let's start off by checking our Dynamic Address Groups for both the HR web server and the HR database server.


 

Dynamic Address Groups as Listed and Configured within Panorama

 

1) From within Panorama click on the Objects tab. 2) Then make sure the left tree panel selection is "Address Groups".  Note we currently have two Dynamic Address Groups listed.  We'll check our HR-Web-Servers group first. Specifically we want to check the IP addresses of the "HR-Web-Servers" Dynamic Address Group (DAG).  3) To see these IP addresses we'll need to click on "more" under the Addresses column.  

 

 

Address Group for the HR-Web-Servers

 

Notice we have two registered IPv4 addresses.  Note these IP addresses then click "Close".

 

 

Now let's do the same for our HR-DB-Servers Dynamic Address Group (DAG).  

 

As before click on "more" under the Addresses column but this time doing so for the "HR-DB-Servers" group.  

 

 

Address Group for the HR-DB-Servers

 

Notice we have no addresses listed. In fact it's all blank.  This is a problem in need of resolution, but first we must do more troubleshooting to see what else we may need to resolve.  To proceed, click "Close" without making any changes here.

 

 

NSX Manager - Security Groups

 

To continue our troubleshooting let's now move over to our NSX Manager to check the Security Groups listed there. To do so we'll need to go back to our vSphere Client.

1) Click on the vSphere Web Client tab of your browser.  Making sure you're still within "Networking & Security". 2) Click on Service Composer and 3) select your Security Groups tab in the middle.

At this time notice your Virtual Machines column on the right.  Note you have a value of 1 for your HR-Web-Servers which is listed as a Virtual Machine.  4) Let's take a look at that value by clicking on that high-lighted 1.

 

 

Virtual Machine Memberships - "HR-Web-Servers".

 

At this point we may need to wait approximately 45 seconds before anything populates.  What we're looking for though, is that under the "Virtual Machines" tab we should see our HR web server "hr-web-01" listed as a member of our virtual machine.  Now that we’ve confirmed the presence of our VM go ahead and close by clicking on the “x” in the upper right corner of the display box.Now let's take a look at our HR-DB-Servers security group by attempting to do the same.

 

 

Virtual Machine Memberships - "HR-DB-Servers".

 

This time select your HR-DB-Servers Security Group.   Then notice the virtual machine membership for this Security Group is zero. In fact, if you click on the blue (0) zero, a display box won't even open for you. This indicates a problem here within our NSX Security Group configurations and something in need of resolution. For now though, we need to investigate further and so let's continue.

 

 

Checking NSX Security Group Membership

 

High-light your HR-DB-Servers Security Group.  Then click on the "edit" icon.

 

 

Define Dynamic Membership

 

Click on "Define dynamic membership" and notice the criteria is set to "Security Tag Equals to HR-DB-Server".  This is correct and so do not make any changes.  Instead just click Cancel to exit and continue to troubleshoot.

 

 

Checking Settings and Configurations Continued

 

To continue checking configurations and settings go to the Home tab and then click on Hosts and Clusters.

 

 

Security Tag Assignments

 

From the far left tree panel, expand your datacenter view by clicking on the expand arrow to list the VMs of your Data Center.

We need to check the settings for the hr-db-01 server and so select it.  Note on the right side of your screen under "Security Tags", the wrong Security Tag has been applied. This is the Security Tag for your Legal-DB-Server when it should be for your HR-DB-Server. This is what we must correct. To do so click "Manage".  (Repositioning of the Security Tags widget may be necessary).  

PLEASE NOTE: If you are working from a laptop or a smaller desktop with a limited view, you may not be able to see the step 2) "Manage" option located on the bottom right hand side of the "Security Tags" widget's display box.  You'll also notice the lack of a scroll bar to adjust. To resolve this issue simply click on the "Security Tags" widget's menu bar and drag & drop it over to the left side of the panel display as these widget boxes can be moved for positioning and viewing purposes.  

 

 

Security Tag Assignments

 

To fix the problem un-check the Legal-DB-Server check box and then check the HR-DB-Server check box and click OK.  

 

 

Security Tag Assignments

 

Notice your Security Tag value has changed and is now specifying your HR-DB-Server which is what it should say at this time.  Let's now go back and view your NSX Security Group identification and settings.

 

 

Networking & Security

 

Continue by verifying the NSX Security Group Membership.  To do so, view the Security Group settings by clicking on Home and then Networking & Security.

 

 

Security Group Settings

 

1) Click on Service Composer and then 2) click on the Security Groups tab and note the number of "Virtual Machines" that are now listed which is 1.

Your Security Groups now include a virtual machine for both your HR-DB-Servers and your HR-Web-Servers group as opposed to before when you only had a virtual machine for the HR-Web-Servers security group.  

To view the server for this virtual machine, click on the high-lighted number 1 for HR-DB-Servers.

 

 

Virtual Machine Memberships

 

Again you may need to wait approximately 45 seconds for this display box to populate. After it does populate we should see our hr-db-01 server listed as a member of the Security Group "HR-DB-Servers".  Now that we’ve confirmed the presence of our newly added VM, go ahead and close by clicking on the “x” in the upper right corner of the display box.

 

 

Confirming Registration in Panorama

 

Go back to Panorama via your Panorama browser tab.  When back in Panorama, click the Objects tab and then click on "more" under Addresses for the HR-DB-Servers group.

 

 

Successful IPv4 Address Registration Confirmed

 

Notice we now have two registered IPv4 addresses for this Dynamic Address Group (DAG).  Success!  Go ahead and click Close and then proceed on to the re-testing phase.

 

 

 

Generating Traffic Re-Test

 

Once again generate traffic from the HR web server to the HR database server.  To do so let's go back to our putty.exe utility for "hr-web-01". From the hr-web-01 web server initiate a ping to the hr-db-01 database server using the "ping -c 5 hr-db-01" command.

The output should indicate another successful ping.  Now proceed back into Panorama to check the logs.  

 

 

 

Panorama Logs

 

After the successful ping we're expecting to see that the traffic did indeed go through our VM-Series Firewall.  So check the log file by clicking on the "Monitor" tab and selecting "Traffic" from the Logs tree menu on the left. Then do a manual refresh of the logs.

Notice we see the ping logged as expected.  This verifies that we correctly resolved the problem and that our groups, policies, and traffic steering rules are all working properly.  Great job!  Let's now move on to the next portion of this lab.

 

Prepare to Generate Database Traffic With Logging


Logs are an effective tool that can be used not only for reporting purposes, but for also enabling us to track and see what's taking place on our network. Then based upon what we're seeing, we can adjust accordingly to ensure a safe and secure network.  Additionally, we can use logs for troubleshooting purposes as well which is what we'll continue to do next.  So in preparation for our next set of tests we will want to do some minor maintenance on our logs. This will ensure the logs we are seeing are both current and accurate.


 

Checking Traffic Logs

 

1) Notice your logs within the last 15 minutes of which you should have very few.  Most likely you'll only have two log entries such as you see displayed here.  Of the logs listed you should only have entries for the ping test that we ran.  

Remember, you can always change the filter and you can always do a manual refresh.  Here our filter is set to the minimum setting of "Last 15 Minutes" and so set yours to the same if not already done so and then do a "Manual refresh".

Now let's continue to generate more log traffic but this time we'll generate some database table calls and so go ahead and proceed to the next step.  

 

Generate Database Table Calls


For this step we want to generate more traffic through our firewall via a database table call. To do so we'll run a mysql command from one of our Web servers to our database.


 

Database Query

 

For this step you will want to use the README.txt file located on your desktop.  Open this file and under Module 1, look for the high-lighted command circled in red above. Go ahead and copy this command to the clipboard from within the README.txt.  

 

 

Database Query from "hr-web-01"

 

Using putty go back into the hr-web-01 server and run the command as found within the README.txt file.  To do so simply "paste" the command you copied from within the README.txt file into your SSH session at the CLI prompt by "right clicking" to paste the command at the prompt.

Within the output notice the table call was successful.  Is this what you expected?  Why?

If you said yes, this is what was expected and the reason why is because your policy is set to allow MySQL traffic, you are correct!  In fact we can even see this traffic was logged within the VM-Series firewall as shown in our next step.

 

 

 

Panorama Logs

 

Ensure the VM-Series firewall logged the generated traffic.  To do so go back into Panorama and click on the Monitor tab and select Traffic logs.  

Notice the two entries identifying, and allowing, the mysql application.

Before moving further ahead let's take a moment to pause to learn about Application Identification and the ability of your VM-Series firewall to allow or deny various types of traffic between the VMs within your datacenter based upon application type.  

 

App-ID by Palo Alto Networks


What is App-ID?

App-ID is a patented traffic classification system developed by Palo Alto Networks. App-ID provides the ability to determine what application is traversing through the VM-Series firewall irrespective of the port, protocol, encryption (SSH or SSL) or any other evasive tactic that may be used by a suspect application.

How does App-ID work?

App-ID applies multiple classification mechanisms, application signatures, application protocol decoding, and heuristics to your network traffic stream to accurately identify applications.  All traffic is then matched against policy to check whether this type of traffic is allowed or not on the network or between your VMs.  Signatures are then applied to the allowed traffic identifying the application based on its unique application properties and its related transaction characteristics. These signatures also determine if the application is being used on its default port or is using a non-standard port. If the traffic is allowed by policy, the traffic is then scanned for threats and further analyzed for identifying the application more granularly.

What if the traffic is encrypted? 

App-ID has the ability to identify encrypted traffic determining the type of encryption (SSL or SSH) in use.  If a decryption policy is in place the session is decrypted and the application signatures are applied again on the decrypted flow.  Decoders for known protocols are then used to apply additional context-based signatures to detect other applications that may be tunneling inside of the protocol (e.g., Yahoo! Instant Messenger used across HTTP).  Afterwards decoders validate that the traffic conforms to the protocol specification and provide support for NAT traversal and opening dynamic pinholes for applications such as SIP and FTP.

Now that we know more about App-ID let’s see how it works in action within the last remaining steps of this lab.  


App-ID for SSH


Within this step you'll see how, and why, ssh is blocked between your two VMs (hr-web-01 and hr-db-01).


 

Policies within Panorama

 

Go back to your browser and select the Panorama tab.  If necessary, login into Panorama.  

1) Once logged into Panorama review your current policy settings by clicking on the Policies tab.

2) From within the left tree panel view, make sure your looking at the "Pre Rules" of your Security policy.  

3) Note your three policies which only allow the ping and mysql applications.  

 

 

Test App-ID

 

To test App-ID let's try to ssh between your two VM servers.

Let's try doing so from the hr-web-01 server and so use your putty desktop icon to access this server.

Using the "ssh ubuntu@hr-db-01" command attempt to ssh into the hr-db-01 server.  

After 30 seconds, during which the ssh attempt will fail, go ahead and break out of the command with the "CTL-C" option.  

Then move on to check your logs within Panorama to see what was captured.

 

 

Examine Traffic Logs

 

As expected, notice the denied SSH on port 22 attempts that were blocked. This demonstrates successful inter-tier VM protection at the application layer.

 

Module 1 Lab 1 - Conclusion


During this lab we demonstrated how we can protect inter-tier application traffic - also referred to as east-west traffic. To do so we used our VM-Series firewall and Panorama management station to integrate Palo Alto Networks security with VMware NSX. This stateful synchronization is possible through the Palo Alto Networks VM-1000 HV’s ability to maintain constant awareness of the changes made within your datacenter in regards to the ever adding, moving, and deleting of virtual machines, their applications AND their dynamic IP addressing. But that’s only half of the story. The other half includes the capabilities of the VMware NSX Manager which completes this synchronization between the Palo Alto Networks Dynamic Address Groups, and the VMware NSX Manager’s Security Groups, providing a datacenter awareness, and datacenter protection, like no other because it all takes place automatically. In fact, in the next module we’ll walk you through a lab where you’ll see just how automatic everything is and how easily everything integrates to ensure an ever aware and secure datacenter.


Module 2: Deploying Palo Alto Networks VM-Series with VMware NSX to protect a multi-tier application (45 Min)

Module Overview


Within this in-depth module, VMware NSX and the Palo Alto Networks VM-Series platform are configured to secure a multi-tier application with web front-end servers and database back-end servers.  Throughout the module itself we will show how to define dynamic security policies on the VM-1000-HV virtual firewalls based on context from VMware NSX. Let's take a look at the learning objectives where we will be focusing on how to deploy the Palo Alto Networks VM-Series platform while walking through each Lesson. These lessons will enable you to gain an understanding of, as well as perform, the following: 

Let's begin! 


Review Security Tags for Legal Servers


We need to ensure our security tags for our servers of the Legal department are in order and so let's take a look.


 

vSphere Web Client

 

We'll first need to log into our vSphere Web Client.  To do so launch your vCenter desktop icon, or you may simply launch Firefox.  You'll be directed to the VMware vSphere Web Client and when prompted for your credentials login with:

                         Username = "root"

                         Password = "VMware1!"

 

 

 

Hosts and Clusters

 

Once logged in, and from the 1) Home screen, click on 2) Hosts and Clusters.

 

 

 

Assigned Security Tags

 

1) Within the Tree panel view at the left we see a listing of all of our connected servers.  In this case we want to review both of our legal servers to ensure they're properly registered and assigned to the appropriate Security Tag.  

So let's start with our Legal Web server, "legal-web-01" first by clicking on "legal-web-01". Then take note that this server is correctly assigned with the "Legal-Web-Server" Security Tag.  

Next check the Security Tag status of our other Legal server.

PLEASE NOTE: If you are working from a laptop or a smaller desktop with a limited view, you may not be able to see the step 2) "Manage" option located on the bottom right hand side of the "Security Tags" widget's display box. You'll also notice the lack of a scroll bar to adjust. To resolve this issue simply click on the "Security Tags" widget's menu bar and drag & drop it over to the left side of the panel display as these widget boxes can be moved for positioning and viewing purposes.  

 

 

 

Assigned Security Tags

 

By selecting the Legal Database server, "legal-db-01" we also see that this server is assigned to the appropriate Security Tag dubbed, "Legal-DB-Server".  

So now that we know both our Legal Dept. servers have Security Tag assignments, we can now move on to the next step.

Note: Within this module we will only be using the these two Legal Servers (legal-web-01 and legal-db-01).

 

 

Create NSX Security Groups and Configure Traffic Steering


During this stage we need to create and define the additional NSX Security Groups that we will be using.  These will include the Web-Servers and Database Servers of our Legal Department.  Therefore we'll simply call these Security Groups "Legal-Web-Servers" and "Legal-DB-Servers".  Then after these two new Security Groups are created we'll then want to create a traffic steering policy for all of our Web server to Database server traffic.  

 


 

Creating NSX Security Groups

 

Go back to your browser and click on the vSphere Web Client tab.  If necessary login again with the credentials "root" and "VMware1!".

Once logged and from the Home page of the vSphere Web Client click 1) Home and 2) Networking & Security.

 

 

Creating NSX Security Groups

 

From within Networking & Security select Service Composer and then click on the Security Groups tab in the center.  Notice we only have Security Groups for our HR Teams and so let's create additional NSX Security Groups for our Legal Teams.

To do so we'll need to click on our "Add" icon which is circled and labeled as sub-step 3.

 

 

Creating NSX Security Groups

 

We will need to name our new security group and so let's call it "Legal-Web-Servers".  

 

 

Creating NSX Security Groups

 

1) Next click on Define dynamic membership in order to set the values for this Security Group. NOTE: If after clicking on "Define dynamic membership" from within the left tree panel, you do not see the options listed as reflected within the screenshot, click on the green plus sign that is circled in blue.

2) Define the dynamic membership as a Security Tag. To do so click on the drop down arrow next to "Security Tag" and select Security Tag.  

 

 

Creating NSX Security Groups

 

1) Define the value by selecting "Equals to".  

2) Then populate by entering the designated name of "Legal-Web-Server" and 3) click Finish.

 

 

Creating NSX Security Groups

 

At this stage you'll see the Security Group is being created.  

 

 

NSX Security Groups Created

 

Once created you'll see your "Legal-Web-Servers" Security Group listed.  

1) Expand to check the Virtual Machine name this Security Group is applied to by clicking on the high-lighted number 1 under the "Virtual Machines" column.  Notice the proper name of "legal-web-01" has been applied.  

Great job in creating your Legal-Web-Servers" NSX Security Group!  To close this display box click on the "x" located in the upper right corner of the display box.

2) Let's now proceed by doing the same for your Legal-DB-Servers NSX Group by clicking on the "New Security Group" icon circled in blue.

 

 

Creating NSX Security Groups

 

1) As before we need to name our new NSX Security Group. We'll call this one "Legal-DB-Servers".

2) Now click on Define dynamic membership.

 

 

Creating Security Groups

 

1) Click on Define dynamic membership in order to set the values for this Security Group. NOTE: If after clicking on "Define dynamic membership" from within the left tree panel, you do not see the options listed as reflected, click on the green plus sign that is circled in blue.

2)  Define the dynamic membership as a Security Tag. To do so click on the drop down arrow next to "Security Tag" and select Security Tag.  

 

 

Creating NSX Security Groups

 

Next define the value by selecting "Equals to".  Then populate by entering the designated name of "Legal-DB-Server" and click Finish.

 

 

NSX Security Groups Created

 

Once created you'll see your "Legal-DB-Servers" Security Group listed.  Expand to check the Virtual Machine name this Security Group is applied to by clicking on the high-lighted number 2 under the "Virtual Machines" column.  

Notice the proper name of "legal-db-01" has been applied (you may ignore the "hr-db-01" VM name as this was from the previous lab).

Great job in creating your "Legal-DB-Servers" NSX Security Group!  Let's continue on to the next step where we'll create some steering policies. Go ahead and close the display box by clicking on the "x" located in the upper right corner.

 

Create Steering Policy for all Web Server to Database Server Traffic


In this step we'll create policies that will steer our traffic from our Web servers to our Database servers through the NSX Manager.


 

Security Policy for Traffic Steering

 

1) We set our policies via the "Security Policies" tab and so go ahead and click on that tab now.  After doing so you'll notice that one entry already exists - a policy that is only for HR.  Therefore, we are going to create a broader policy that will steer all Web to DB traffic. Then we'll limit HR versus Legal traffic from within PAN-OS.

2) Let's continue by clicking on the "Create Security Policy" icon that is circled in blue and labeled as sub-step 2.

 

 

Security Policy for Traffic Steering

 

After a brief initializing phase it will begin to load the policies in preparation for the new one you'll be creating.  

1) Name your new security policy "Module2_Legal-Web-to-DB".  

2) Next click on "Network Introspection Services" on the left side of the screen.

 

 

Security Policy for Traffic Steering

 

1) From Network Introspection Services:

2) Click on the green plus sign to add a new service.

3) After doing so a display box will appear where you'll enter the name of the service calling it "Legal-Web-to-DB".

4) Click on Change in order to specify the Source.

 

 

Security Policy for Traffic Steering

 

Our "Select Source" display box will appear which will enable us to:

1) Select the radio button option for "Select Security Groups".  Of the options displayed check 2) our Legal-Web-Servers and 3) and then click OK.  

 

 

Security Policy for Traffic Steering

 

Notice that under "Source" you have Legal-Web-Servers. Complete this step by clicking the OK tab at the bottom.

 

 

Security Policy for Traffic Steering

 

At this step you should have 1 item listed which is the Network Introspection Service that you just created for your Source.  

1) Let's now repeat the same process for your Destination by creating another item by clicking on the green plus icon.

 

 

Security Policy for Traffic Steering

 

1) Name your new service "Legal-DB-to-Web".

2) Under Destination click Change to specify. Leave all other settings as they are.

 

 

Security Policy for Traffic Steering

 

1) Select the radio button option for Select your Security Groups, and then 2) select the check box for Legal-Web-Servers and then 3) click OK.

 

 

Security Policy for Traffic Steering

 

Notice under Destination that you now have your Legal-Web-Servers specified.  Click OK to complete this step.

 

 

Security Policy for Traffic Steering

 

You now should have 2 Network Introspection Services listed.  

Go ahead and click Finish after which you'll see your security policies being created.

 

 

Security Policy for Traffic Steering

 

You should see the two newly created Security Policies.  We must now apply our policies to their respective Security Groups and in this case that would be to our database servers. To do so we'll need to click on the "Apply Security Policy" icon (circled in blue) to proceed.

 

 

Security Policy for Traffic Steering

 

As we wish to apply to our database group we'll need to select the "Legal-DB-Servers" check box and then OK.  You'll then receive a brief display box as the security policy is applied.

 

 

Security Policy for Traffic Steering

 

At this point you should be able to verify all your actions by seeing 2 Applied policies and 2 Network Introspect Services.  If so, great job!  You just created your Traffic Steering Security Policies.  Please proceed to the next lesson of this module.

 

Create Dynamic Address Groups (DAG)


We learned about Dynamic Address Groups (DAG) and the purpose they serve in Module 1.  Here in Module 2 we will actually walk you through the creation of said groups from within Panorama by Palo Alto Networks.  Before we get started though, here's a recap on both Dynamic Address Groups (DAG) and Panorama.

Dynamic Address Groups (DAG) - Provide the ability to maintain awareness of changes in the virtual machines/applications and ensures that security policy stays in tandem with the changes in the network. This awareness provides visibility and protection of applications in an agile environment. This is made possible because Dynamic Address Groups are used as a source or destination object within security policies. Additionally, because IP addresses are constantly changing in a datacenter environment, Dynamic Address Groups offer a way to automate the process of referencing source and/or destination addresses within security policies. This is unlike static Address Objects that must be manually updated in configuration and committed whenever there is an address change (addition, deletion, or move), Dynamic Address Groups automatically adapt to these changes.

Panorama - Enables you to manage your distributed network of physical and/or virtual Palo Alto Networks firewalls from a centralized location while providing the ability to: View the traffic of each deployed firewall; manage all aspects for device configuration; push global policies; and generate reports on traffic patterns or security incidents  all from one central location. Panorama is available as either a dedicated management appliance or as a virtual machine.

Let's proceed.


 

Back into Panorama

 

If Panorama is still up and running, access Panorama via your browser tabs.  If Panorama is no longer running, open your browser and click on the Panorama bookmark.  Or you may launch the Panorama desktop icon to launch and login to Panorama.

     Username = admin

     Password = VMware1!

 

 

Panorama

 

The credentials for Panorama are username = "admin" with password = "VMware1!"

Note: The README.txt file on your desktop will reflect the credentials for Panorama as well as all of your servers for this module.

 

 

Creating Dynamic Address Groups

 

As soon as you're logged into Panorama go ahead and 1) select the Objects tab, then click on the 2) Add icon at the bottom of the screen to create your Legal team Dynamic Address Groups.

 

 

Creating Dynamic Address Groups

 

In this portion we're going to have a number of sub-steps, 6 in total, and so please follow along closely.  Let's start by:

1) Naming this Dynamic Address Group, "Legal-Web-Servers".  

2) Designate the "Type" of DAG by hitting the drop down arrow and selecting "Dynamic".  

3) Next click on Add Match Criteria.  At this point another display box will appear adjacent and on the left. Here you may need to expand the Name field of the display box to see the full name of the available options.

4) Look for your "Legal-Web-Servers-securitygroup-ID#) and click on the green plus mark to add it. Note: Your Security Group ID number may be different than what you see here.  That is ok and so continue. Once you do you'll notice the "Match" within the display box on the right listing your Security Group as indicated by the blue arrow.

5) Next assign a color coded tag to this DAG by clicking on the drop down arrow and selecting the tag, "Legal Web Server".  

6) click OK to finish.

 

 

Creating Dynamic Address Groups

 

Notice our newly created DAG of Legal-Web-Servers.  We'll now need to repeat the same process to create our Legal-DB-Servers DAG.  To do so click the Add icon at the bottom of your screen.

 

 

Creating Dynamic Address Groups

 

Just like before we'll have 6 sub-steps. Begin by:

1) Naming this Dynamic Address Group, "Legal-DB-Servers".  

2) Designate the "Type" of DAG by hitting the drop down arrow and selecting "Dynamic".  

3) Next click Add Match Criteria.  At this point another display box will appear adjacent and on the left. Here you may need to expand the Name portion of the display box to see the full name of the available options.

4) Look for your "Legal-DB-Servers-securitygroup-ID#) and click on the green plus mark to add it. Note: Your Security Group ID number may be different than what you see here.  That is ok and so continue. Once you do you'll notice the "Match" within the display box on the right listing your Security Group as indicated by the blue arrow.

5) Now assign a color coded tag to this DAG by clicking on the drop down arrow and selecting the tag, "Legal DB Server".  

6) Click OK to finish.

 

 

Creating Dynamic Address Groups

 

At this point you should have your two Legal Team Dynamic Address Groups, one for your Web servers and another for your DB servers.

Let's now move on to policy creation.

 

Create a Security Policy within Panorama


Here we'll create a security policy that will only allow web-browsing between the Web servers and the Database servers. So back into Panorama we go.


 

Creating Security Policies

 

In Panorama 1) click on the Policies tab.  

2) Click on the 2nd policy listed so that the next policy we create will follow immediately.  

3) Click on the +Add icon at the bottom left side of your screen.

 

 

Creating Security Policies

 

When the Security Policy Rule display box appears we'll have multiple tabs of which we'll need to configure.  Let's start on the General Tab by naming our new policy "Legal Web to DB".  

After entering the name, click on the "Source" tab.

 

 

Creating Security Policies

 

1) After clicking on the Source tab, specify by checking "Any" for Source Zone

2) For the Source Address, click on the green + icon and when the display options appear, choose the "Legal-Web-Servers" address group.  

Next click the Destination tab.

 

 

Creating Security Policies

 

1) After clicking on the Destination tab specify the Destination Zone by 2) clicking on the drop down arrow and choosing "any".  

3) Then again click on the green + plus icon and for Destination Address select "Legal-DB-Servers".  

The next tab to configure will be the Application tab.

 

 

Creating Security Policies

 

After 1) clicking on the "Application tab 2) click on the green + plus sign on the bottom left to Add, or specify your allowed application.  You can refine your listing of available applications by typing in "mysql" in the field high-lighted. Then select "mysql" to populate.  The next tab will be the Actions tab.

 

 

Creating Security Policies

 

From the Actions tab make sure we are 1) set to Allow and 2) under Log Setting we check the option to Log at Session Start and 3) for Log Forwarding we are forwarding to our Panorama Logging Profile.  Finally, 4) click OK to finish the creation of this Security Policy.

 

 

Commit Configurations

 

In order for our configurations to be applied we'll need to do a series of two Commits.  First we'll need to Commit to Panorama. To begin doing so click on "Commit" in the upper right hand corner.

 

 

Commit to Panorama

 

For Commit Type select the radio button for Panorama and click OK. Your commit will begin of which you'll see the following:

 

 

Commit to Panorama

 

After receiving a Commit Pending message you should receive a Configuration committed successfully message.  Click Close to proceed with the second commit type.

 

 

Commit to VM-Series Firewalls

 

Again click on Commit.

 

 

Commit to VM-Series Firewalls

 

For the Commit Type: 1) select the Device Group radio button and when 2) presented with your display check the VM-Series-DG check box and the 3) click OK.

 

 

Commit to VM-Series Firewalls

 

The commit will begin to our two VM-Series firewalls and may take a few minutes. Please be patient until your Progress bar and status indicate 100% completion.

 

 

Commit to VM-Series Firewalls

 

Notice our Progress of 100% and the Status stating our commit succeeded.  Please note - ignore the warnings messages as this is expected due to other settings that we have in place for logging purposes.  

At this stage simply click Close.

 

Review NSX Security Group and DAG Membership


At this point we'll want to review our NSX Security Group and DAG Membership by ensuring successful registration. To do so we'll need to go back into the vSphere Web Client.


 

VSphere Web Client

 

Check your browser and select your vSphere tab.  If your session timed-out login again using username = "root" with password = "VMware1!"

 

 

vSphere Web Client

 

1) Click on Home and then go to 2) Hosts and Clusters.

 

 

Review NSX Security Group and DAG Membership

 

1) Let's first check your Legal Web servers and so first select your "legal-web-01" server.

2) Near the center of the screen click on "View all 4 IP addresses" to ensure IP address registration.  At this time take notice of the IP Address 15.0.0.202.  We will need to look to ensure this IP address is the IP address as found within Panorama and also as listed within the respective Security Group of the NSX Manager.  

Before advancing to check Panorama and to check our NSX Security Groups, let's check to review our legal-db-01 server.

 

 

Review NSX Security Group and DAG Membership

 

Like before, to review your Legal Database servers 1) click on "legal-db-01" from the left hand tree panel and then 2) click on "View all 4 IP addresses".  

Again take note of the 15.0.0.204 address as we will be checking  both Panorama and our NSX Security Groups to ensure this IP address is indeed registered.

 

 

Review NSX Security Group and DAG Membership

 

Let's first check our settings in Panorama first.  1) From the Objects tab and under Address Groups, look for both Legal servers (Web and DB).

Check the Web server by clicking "more" under the Addresses column for "Legal-Web-Servers".

 

 

Review NSX Security Group and DAG Membership

 

Notice that our 15.0.0.202 IP Addresses is indeed a registered address for "legal-web-01" verifying our Legal Web Servers.  

Go ahead and click Close and then repeat doing so for the Database servers.

 

 

Review NSX Security Group and DAG Membership

 

Like before click "more" under Addresses for your "Legal-DB-Servers".

 

 

Review NSX Security Group and DAG Membership

 

For our Legal Database Servers notice that we indeed have the same 15.0.0.204 for this "legal-db-01" server.  This verifies successful IP registration for our Legal Database Servers Address Group.

Click Close.

 

 

Review NSX Security Groups

 

From your browser tab click on your vSphere Web Client tab to verify these same IP addresses are within your Security Groups for these two verified servers.  

To do so when you're back in vSphere, 1) click Home and then 2) Networking & Security.

 

 

Review NSX Security Groups

 

First click on Service Composer from the left tree panel and 2) select the Security Groups tab in the middle.  

3) Now you can check the registered Virtual Machines and their IP addresses by clicking on the high-lighted for both your Legal Web and Database Servers.

 

 

Review NSX Security Groups

 

Let's check our "Legal-Web-Servers" Security Group first of which we see our "legal-web-01" server that is the 15.0.0.202 IP Address.

 

 

Review NSX Security Groups

 

Next we'll check our "Legal-DB-Servers" Security Group of which we see our "legal-db-01" server which is the 15.0.0.204 IP address.  

And so we now know both of our Legal servers are registered and recognized as expected. We are now ready to move on.

 

Generate Traffic


To check our work and to ensure all of our groups, policies, and configurations have been correctly configured, we will now generate some traffic through our firewalls.  


 

Login to "legal-web-01"

 

Click the "legal-web-01" desktop icon to login to this server.

 

 

mysql command from README.txt

 

We will need Module 2 command from the README.txt file on your desktop and so 1) open this file and 2) scroll down to the Module 2 section and copy the first mysql command listed, copying it to your clipboard.

 

 

Run the Command from "legal-web-01"

 

Within the SSH session you have "paste" the copied command at the prompt to run the mysql command. Notice the output received.  

 

Inspect Panorama Traffic Logs


Checking the Traffic Logs from within Panorama


 

Panorama Traffic Logs

 

Go back into Panorama and 1) click on Monitor and 2) select your Traffic Logs.

Notice our Traffic Logs which indicate a successful test as we see our source and destination IP addresses and the mysql application which was properly allowed. Which means SUCCESS!

This completes this module.  Great job!!

 

Lab 2 Conclusion


Here in this lab we did a lot which hopefully instilled within you an awareness and appreciation of how easy it is to deploy, integrate, and manage this joint solution. Did you notice how quickly and easily you’re able to deploy new VMs, and groups of VMs, via VMware NSX? Or how easy it is for VMware NSX to provide traffic steering so that ALL traffic goes through the Palo Alto Networks firewall ensuring an ever aware and secure datacenter? All within a few clicks via a practically seamless integration between the Palo Alto Networks VM-Series firewall and VMware’s NSX, and all without having to make any kind of changes to the infrastructure of the datacenter itself.

So like in the previous lab, we see the benefits of: ease of deployment, ease of integration, ease of configuration and management, and ease of synchronization between the Dynamic Address Groups within the Palo Alto Networks firewalls, and the Security Groups within the VMware NSX Manager. Both of which provide a stateful synchronization to ensure all changes in the form of VM additions, deletions, moves, and dynamic IP addressing which means no manual changes in the infrastructure and/or reconfiguration on your part required! Reason being, all datacenter changes are automatically recognized and registered within the NSX Manager and so our datacenter is always secure, even when the traffic is intra-datacenter traffic among VMs.

On behalf of Palo Alto Networks and VMware, we’d like to thank you for sitting our labs. We hope you enjoyed our labs, as much as we enjoyed preparing them for you, and we hope we successfully demonstrated how easy it is to manage and secure your ever changing datacenter!

 


Module 3: Using Distributed FireWall (DFW) to Protect Intra-tier Traffic (30 Min)

Module Overview


In this module VMware NSX DFW is configured to secure intra-tier traffic between web front-end servers . This module shows you how to define dynamic Security Groups (based on VM name and based on Logical Switch) and then how to use them in DFW policy configuration.

During this module (30 minutes) we will be focusing on NSX DFW functionalities. These lessons will enable you to gain an understanding of, as well as perform, the following: 

 OK, now let's begin! 


Create NSX Security Groups


let's create 2 new NSX Security Groups using dynamic inclusion based on VM name (for Legal web servers) and using static inclusion based on Logical Switch / static exclusion based on VM (for HR web servers).


 

vSphere Web Client

 

We'll first need to log into our vSphere Web Client.  To do so launch your vCenter desktop icon, or you may simply launch Firefox.  You'll be directed to the VMware vSphere Web Client and when prompted for your credentials login with:

                         Username = "root"

                         Password = "VMware1!"

 

 

Networking & Security

 

Once logged in, and from the 1) Home screen, click on 2) Networking & Security.

 

 

Service Composer / Security Groups

 

Click on 1) Service Composer and then on 2) Security Groups.

Note: if you have previously performed module 1 and module 2 of this LAB, you will have a similar screenshot. If you start module 3 before the other modules, you won't see some of the displayed Security Groups.

 

 

Create new Security Groups for Legal Web Servers

 

Click on 1) icon to create a new Security Group

 

 

Security Group Name

 

Following window appear. in Name field input, enter:

Legal-Web-Servers-Module-3

 

 

Security Group Dynamic Inclusion using VM Name

 

Select 1) VM Name and then 2) enter 'legal-web' keyword.

Click on 3) Finish to terminate the operation.

 

 

Security Group Check

 

Following window should appear. The new Security Group appear at the end of the list. Characteristics of the Security Group like Virtual Machines appear under each corresponding column.

 

 

Security Group - VM

 

To check which VM are contained inside this new Security Group, click on the link under Virtual Machines column. In our case, both web servers of Legal organization should be displayed.

 

 

Create new Security Groups for HR Web Servers

 

Click on 1) icon to create a new Security Group

 

 

Security Group Name

 

Following window appear. in Name field input, enter:

HR-Web-Servers-Module-3

and then click on 2) Next button.

 

 

Security Group Dynamic Inclusion - Skip

 

We are not going to use dynamic membership so click on 1) Next button.

 

 

Security Group Static Inclusion - Logical Switch

 

Select 1) Logical Switch and then select  2) LS-HR-01. This is the Logical Switch (VXLAN) where all VM servers of HR organization are connected to.

Click on 3) Next.

 

 

Security Group Static Exclusion - DB server

 

Click on 1) right arrow to extend the list of filters and then see Virtual Machine. Click on 2) Virtual Machine and then select 3) hr-db-01.

Click on 4) Finish to terminate the operation.

 

 

Security Group Check

 

Following window should appear. The new Security Group appear in the middle of the list. Characteristics of the Security Group like Virtual Machines appear under each corresponding column.

 

 

Security Group - VM

 

To check which VM are contained inside this new Security Group, click on the link under Virtual Machines column. In our case, both web servers of HR organization should be displayed.

 

Create NSX DFW Security Policies


Let's use the 2 Security Groups previously created in DFW policy rules to enable or disable intra-tier traffic between web servers of Legal organization (and the same for HR organization).

The following security policies will be implemented:

Legal:

source: Legal Web Servers | destination: Legal Web Servers | Services: ICMP | action: allow

source: Legal Web Servers | destination: Legal Web Servers | Services: ANY | action: block

 

HR:

source: HR Web Servers | destination: HR Web Servers | Services: ICMP | action: allow

source: HR Web Servers | destination: HR Web Servers | Services: ANY | action: block


 

DFW Menu

 

Click on 1) NSX Home and then on 2) Firewall.

 

 

Create a New Section

 

Click on 1) add section icon and then enter section name:

INTRA-TIER protection

Click on OK to terminate the operation.

 

 

Create new Policy Rule

 

Click on 1) add rule icon and then click on 2) arrow to expand Section in order to see all defined policy rules.

 

 

Policy Rule Name

 

Click on 1) + icon in the Name column and then enter the following string in Rule Name window:

Legal-Web to Legal-Web ICMP

Click on OK.

 

 

Policy Rule Source Field

 

Click on 1) + icon in the Source column. A new window will appear. Then select 2) Security Group. All Security Groups will be listed. Look for Legal-Web-Servers-Module-3 and then click on 3) in the associated checkbox and then click on 4) the right arrow so it will transition to Selected list panel.

Click on OK to terminate the operation,

 

 

Policy Rule Destination Field

 

Click on 1) + icon in the Destination column. A new window will appear. Then select 2) Security Group. All Security Groups will be listed. Look for Legal-Web-Servers-Module-3 and then click on 3) in the associated checkbox and then click on 4) the right arrow so it will transition to Selected list panel.

Click on OK to terminate the operation,

 

 

Policy Rule Service Field

 

Click on 1) + icon in the Service column. A new window will appear. Click on 2) and enter icmp as keyword. All services related to ICMP will appear at the bottom panel. Find ICMP Echo and ICMP Echo Reply and click on 3) in the associated checkbox. Then click on 4) the right arrow so they will transition to Selected list panel.

Click on OK to terminate the operation,

 

 

Policy Rule Action Field

 

Click on 1) + icon in the Action column to select desired action for the policy rule.

By default, action is set to Allow for a newly created security policy. This is the action we want to enforce for our rule so there is no need to do anything here.

Click on Cancel since no change is needed.

 

 

Policy Rule Publish Operation

 

You should obtain this window at this stage.

Click on 1) Publish Changes button to enforce the new created security policy.

 

 

Policy Rule Publish Status

 

A message should be displayed at the top of the page showing successful publish operation (note: the message may take some time to arrive depending on the CPU load of the HOL infrastructure).

 

 

Create Remaining Policy Rules

 

Now that we learnt how to create a DFW policy rule using Security Group, let's go ahead and create these policy rules:

Name:  Legal-Web to Legal-Web ANY

Source:  (Security Group) Legal Web Servers

Destination:  (Security Group) Legal Web Servers

Services: Any

Action:  Block

 

Name: HR-Web to HR-Web ICMP

Source:  (Security Group) HR Web Servers

Destination: (Security Group) HR Web Servers

Services: ICMP Echo, ICMP Reply

Action: Allow

 

Name: HR-Web to HR-Web ANY

Source:  (Security Group) HR Web Servers

Destination: (Security Group) HR Web Servers

Services:  Any

Action: Block

 

IMPORTANT NOTE: click on 1) + icon (as shown in the diagram above) to add these new rules, New rules should always be created at the bottom of previously created rules because the order of rule definition is important with DFW (and in fact with any firewall on the market). Rule evaluation is always performed from top to bottom and the first rule that match the packet pattern is used.

 

 

Publish Changes to Enforce all Rules

 

You should obtain this window at the end of the configuration.

If you ruleset is displayed in different order than shown in this screenshot, you will need to re-order your rules. To perform this operation, select the rule that needs to be re-ordered and then click on the up or down arrow as shown on the screenshot.

Click on 1) Publish Changes to enforce all the rules.

 

 

Publish Changes Status

 

A publish operation success message should be displayed at the top of the page (after some short while).

 

Enable Flow Collection for NSX DFW Statistics


To get statistics about NSX DFW operations, we need to turn on global flow collection.


 

Flow Monitoring - Configuration

 

From NSX home, click on 1) Flow Monitoringmenu. Then click on 2) Configuration tab.

As you can see, global flow collection is disabled by default. Click on enable to turn it on.

 

 

Global Flow Collection Enabled

 

You should obtain the same window once global flow collection has been enabled.

 

Checking NSX DFW Policies


let's check the effects of NSX DFW configuration


 

Testing 1

 

 

Legal Web Server to Legal Web Server - ICMP

 

Click on 1) legal-web-01 icon. A new SSH window will appear with automatic login to legal-web-01.

2) Type the following command  to check ICMP response from this server:

ping legal-web-02

ICMP is allowed on DFW so the ping command should return successful responses. Type Ctl-C to terminate ping command.

 

 

Legal Web Server to Legal Web Server - SSH

 

on the same ssh window, now issue the following command:

ssh legal-web-02

After few seconds, you should see the error message: connection timed out (type Ctl-C to terminate ssh command if time out is too long).

This is expected as NSX DFW does not allow SSH between the 2 web servers.

 

 

HR Web Server to HR Web Server - ICMP

 

Click on 1) hr-web-01 icon. A new SSH window will appear with automatic login to hr-web-01.

2) Type the following command to check ICMP response from this server:

ping hr-web-02

ICMP is allowed on DFW so the ping command should return successful responses. Type Ctl-C to terminate ping command.

 

 

HR Web Server to HR Web Server - SSH

 

on the same ssh window, now issue the following command:

ssh hr-web-02

After few seconds, you should see the error message: connection timed out (type Ctl-C to terminate ssh command if time out is too long).

This is expected as NSX DFW does not allow SSH between the 2 web servers.

 

 

Check NSX DFW per Policy Rule Statistics

 

Go back to vSphere web client and select Networking & Security -> Firewall menu.

By default, NSX DFW per policy rule statistics is not displayed. Perform the following action under DFW menu to display it:

Click on 1) table arrow icon and then 2) select Stats. Once done, you will see a new column appearing in policy rule window with label Stats.

 

 

Statistics for policy rule 1

 

Click on 1) diagram icon and check flow statistics (number of packets and bytes) processed by NSX DFW rule number 1 (Legal-Web to Legal-Web for ICMP traffic).

 

 

Statistics for policy rule 2

 

Click on 1) diagram icon and check flow statistics (number of packets and bytes) processed by NSX DFW rule number 2 (Legal-Web to Legal-Web for ANY traffic).

 

 

Statistics for policy rule 3

 

Click on 1) diagram icon and check flow statistics (number of packets and bytes) processed by NSX DFW rule number 3 (HR-Web to HR-Web for ICMP traffic).

 

 

Statistics for policy rule 4

 

Click on 1) diagram icon and check flow statistics (number of packets and bytes) processed by NSX DFW rule number 4 (HR-Web to HR-Web for ANY traffic).

 

 

Modify NSX DFW rules to enable SSH

SSH is blocked by rule 2 (for Legal organization) and by rule 4 (for HR organization).

To enable SSH, let's include the protocol in rule 1 and rule 3.

 

 

Modify Rule 1 to Include SSH

 

in NSX DFW policy table, select rule number 1. Then click on 1) + icon in the Service Column to modify content of Service field.

A new window will appear. On 2) type ssh keyword and then 3) select SSH. Click on 4) right arrow icon to add SSH in the selected list panel.

Click OK to complete the operation.

 

 

Modify Rule 3 to Include SSH

 

in NSX DFW policy table, select rule number 3. Then click on 1) + icon in the Service Column to modify content of Service field.

A new window will appear. On 2) type ssh keyword and then 3) select SSH. Click on 4) right arrow icon to add SSH in the selected list panel.

Click OK to complete the operation.

 

 

Publish Changes

 

Click on 1) Publish Changes to enforce this new NSX DFW policy configuration.

 

 

 

Publish Changes Status

 

"Last publish operation succeeded" message will appear upon successful operation,

 

 

Testing 2

 

 

Legal Web Server to Legal Web Server - SSH

 

Click on 1) legal-web-01 icon. A new SSH window will appear with automatic login to legal-web-01.

Type 2) ssh legal-web-02.

ECDSA key Fingerprint Authenticity message will be displayed. Type yes to continue the connection.

Remote system will then ask for a password; enter VMware1!

A welcome message on legal-web-02 will be displayed upon successful authentication,

 

 

HR Web Server to HR Web Server - SSH (Copy)

 

Click on 1) hr-web-01 icon. A new SSH window will appear with automatic login to hr-web-01.

Type 2) ssh hr-web-02.

ECDSA key Fingerprint Authenticity message will be displayed. Type yes to continue the connection.

Remote system will then ask for a password; enter VMware1!

A welcome message on hr-web-02 will be displayed upon successful authentication,

 

Conclusion

Summary of what we've learned


Here in this lab we did a lot which hopefully instilled within you an awareness and appreciation of how easy it is to deploy, integrate, and manage this joint solution. Did you notice how quickly and easily you’re able to deploy new VMs, and groups of VMs, via VMware NSX? Or how easy it is for VMware NSX to provide traffic steering so that ALL traffic goes through the Palo Alto Networks firewall ensuring an ever aware and secure datacenter? All within a few clicks via a practically seamless integration between the Palo Alto Networks VM-Series firewall and VMware’s NSX, and all without having to make any kind of changes to the infrastructure of the datacenter itself.

So like in the previous lab, we see the benefits of: ease of deployment, ease of integration, ease of configuration and management, and ease of synchronization between the Dynamic Address Groups within the Palo Alto Networks firewalls, and the Security Groups within the VMware NSX Manager. Both of which provide a stateful synchronization to ensure all changes in the form of VM additions, deletions, moves, and dynamic IP addressing which means no manual changes in the infrastructure and/or reconfiguration on your part required! Reason being, all datacenter changes are automatically recognized and registered within the NSX Manager and so our datacenter is always secure, even when the traffic is intra-datacenter traffic among VMs.

On behalf of Palo Alto Networks and VMware, we’d like to thank you for sitting our labs. We hope you enjoyed our labs, as much as we enjoyed preparing them for you, and we hope we successfully demonstrated how easy it is to manage and secure your ever changing datacenter!

 


Conclusion

Thank you for participating in the VMware Hands-on Labs. Be sure to visit http://hol.vmware.com/ to continue your lab experience online.

Lab SKU: HOL-PRT-1462

Version: 20150227-065841