NSX For Vsphere Advanced Training: Lab Exercises

NSX for vSphere
Advanced Training
Lab Exercises Day 2
Confidential
2010 VMware Inc. All rights reserved
NSX Distributed Firewall Lab Exercises
Confidential
NSX vSphere Training Logical Topology and Security-Groups
Control Center
SG-WEB
Web-Tier-01
172.16.10.0/24
Websv-01a
.11
Websv-02a
.12
DBsv-01a
.1
.1
.11
.1
Ap-Tier-01
Appsv-01a
172.16.20.0/24
Distributed Logical
Router
.11
Logical Switch
SG-APP
Confidential
SG-DB
DB-Tier-01
172.16.30.0/24
NSX vSphere Training Allowed Traffic (Inter-Tier and Intra-Tier)

Control Center
HTTP
Web-Tier-01
172.16.10.0/24
Websv-01a
.11
HTTP
HTTPS
Websv-02a
.12
SSH
TCP-8443
Ap-Tier-01
NSX Edge GW
Appsv-01a
172.16.20.0/24
DBsv-01a
.1
.1
.11
.1
Distributed Logical
Router
.11
Logical Switch
SG-APP
Default rule set to block action

4
MySQL
Confidential
SG-DB
DB-Tier-01
172.16.30.0/24
Lab Exercise 10 NSX Distributed Firewall

This LAB consists of the following steps:
Step 1: Logical Topology and Connectivity Check.

Step 2 Create Security-Groups.
Step 3 Create and Allocate S-G TAG to Web Servers.
Step 4 Create DFW policy rules.
Step 5 Check DFW rules configuration with Applied to S-G.
Step 6 Check DFW rules work properly.
Step 7 Reject Action.
Step 8 Advanced Rules Filtering UI.
Step 9 CPU/Memory/CPS Threshold.
Confidential
Lab Exercise 10 NSX Distributed Firewall Step 1

Step objective: before starting the lab, lets make sure we got the right logical topology and
connectivity works as expected.
Check VMs are connected on the right logical switches:

Using vSphere web client (root / VMware1!) click on Hosts and Clusters.
Select web-sv-01a and check it is connected to Web-Tier-01 LS.
Select web-sv-02a and check it is connected to Web-Tier-01 LS.
Select app-sv-01a and check it is connected to App-Tier-01 LS.
Select db-sv-01a and check it is connected to DB-Tier-01 LS.
Verify web-sv-01a can ping everything:

Using PUTTY, open a SSH session to web-sv-01a (172.16.10.11)
Use root / VMware1! to log into the server.
Type the following commands to test ping reachability:
# ping 172.16.10.12 (web-sv-02a)
# ping 172.16.20.11 (app-sv-01a)
# ping 172.16.30.11 (db-sv-01a)
# ping 172.16.10.1 (default GW)
Verify all ping are successfuls.
Confidential
Verify web-sv-01a can SSH to all other VMs:

From the PUTTY session, SSH to app-sv-01a using the following
command:
# ssh 172.16.20.11
ssh should succeed. Type exit to come back to web-sv-01a.
From the PUTTY session, SSH to db-sv-01a using the following
command:
# ssh 172.16.30.11
ssh should succeed. Type exit to come back to web-sv-01a.
Verify web-sv-01a can send HTTP request to

web-sv-02a :
From the PUTTY session, send a HTTP request to
web-sv-02a using the following command:
# curl http://172.16.10.12
You should be able to see response from web-sv-02a.
Confidential
Verify app-sv-01a can send SQL request to

db-sv-01a:
Using PUTTY, open a SSH session to app-sv-01a
Use root / VMware1! to log into the server.
From the console, try to connect to SQL server (db-sv-01a)
using the following command:
# mysql u root h 172.16.30.11 -p
Type VMware1! when system prompt for password.
You should be able to see the same message as displayed on the
screenshot.
Confidential

Verify Control Center can access ABC Medical APP
OneArm web page:
Open a new tab on FIREFOX.
Click on ABC Medial App OneArm shortcut.
You should be able to see the
web page:
At this point of time, everything should work

fine as there is no DFW rule blocking traffic
(DFW default rule set to allow).
Confidential

Step objective: to create Security-Group to group web servers, app servers and DB servers into
their respective containers; We will leverage dynamic inclusion using VM name and SecurityGroup Tag mechanisms. Security-Groups will then be used as objects in DFW policy rules.
Create Security-Group SG-WEB using dynamic inclusion

with S-G TAG:
Using vSphere web client, go to NSX home and then click on Service
Composer. Select Security Groups tab.
Click on new Security Group icon and create SG-WEB using the
following characteristics:
Name: SG-WEB
Dynamic Membership: Security Tag Contains SG-TAG-WEB
Click on finish after configuring dynamic membership.
10
Confidential

Create Security-Group SG-APP using dynamic
inclusion with VM name:
Click on new Security Group icon and create SG-APP using the
following characteristics:
Name: SG-APP
Dynamic Membership: VM Name Contains app
Create Security-Group SG-DB using dynamic

inclusion with VM name:
Click on new Security Group icon and create SG-DB
using the following characteristics
Name: SG-DB
Dynamic Membership: VM Name Contains db
11
Confidential

Verify you obtain the same window as displayed below:
SG-APP and SG-DB show respectively 1 VM and 1 VM.
SG-WEB does not show anything as S-G TAG SG-TAG-WEB has not been allocated yet to web servers.
Clicking on the number (link) will show the VM name:
12
Confidential

Step objective: create S-G TAG SG-TAG-WEB and then associate it to all Web Servers in order to
populate correctly Security Groups SG-WEB.
Create SG-TAG-WEB and associate it to web-sv-01a:

Using vSphere web client, go to Hosts and Clusters.
expand Compute Cluster A then click on web-sv-01a.
In the summary window, look for Security Tags table.
Click on Manage within the table:
13
Confidential
Create SG-TAG-WEB and associate it to web-sv-01a

(contd):
A New window appears. Click on + button.
Use the following information to create the new SG TAG:
Name: SG-TAG-WEB
Description: Tag allocated for WEB servers
Click on OK.
SG TAG to VM allocation window re-appears one
more time.
Select SG-TAG-WEB and then click on OK.
14
Confidential
Web-sv-01a summary window should display SG-TAB-WEB in the Security Tags table as shown
below:
Associate the same tag SG-TAB-WEB to web-sv-02a now:

Repeat the previous actions to assign the S-G TAG to web-sv-02a.
15
Confidential
Check Security-Group SG-WEB is now correctly populated:

Go to NSX Home and click on Service Composer menu.
Select Security Groups tab.
You should be able to see now the 2 WEB servers part of Security-Group SG-WEB.
16
Confidential

Step objective: to create DFW policy rules to enforce application access control for intra-tier traffic
and inter-tier traffic.
Change default rule from Allow to Block:

Go to NSX Home and then click on Firewall menu.
Expand Default Section (Layer3).
Change Default Rule action from Allow to Block.
Click on Publish Changes to enforce the modification (check you get Last Publish Operation Succeeded message
after the publish).
We are going to use now the Positive Security Model where allowed traffic needs to be explicitly configured
17
Confidential

Create intra-tier policy rules:
Add a new section on top of default section and name it INTRA-TIER ACCESS CONTROL.
Add the following policy rule in this new section:
Name
Source
Destination
Service
Action
Applied to
Log
WEB to WEB
SG-WEB
SG-WEB
HTTP
Allow
SG-WEB
Log
Click on Publish Changes to enforce the new policy rules (check you get Last Publish Operation Succeeded
message after the publish).
18
Confidential

Create intra-tier policy rules (contd):
You should obtain the following window:
Note that Applied To to a Security-Group object is a new feature provided by NSX 6.1.
In the next step, we will check its application.
19
Confidential

Create inter-tier policy rules:
Add a new section on top of default section and name it INTER-TIER ACCESS CONTROL.
Add the following policy rules in the section (click on + button on the section raw to add rules inside the section):
Name
Source
Destination
Service
Action
Applied to
Log
ANY to WEB
ANY
SG-WEB
HTTP
HTTPS
Allow
SG-WEB
Log
WEB to APP
SG-WEB
SG-APP
SSH
TCP-8443
Allow
SG-WEB
SG-APP
Log
APP to DB
SG-APP
SG-DB
MYSQL
Allow
SG-APP
SG-DB
Log
Click on Publish Changes to enforce the new policy rules (check you get Last Publish Operation Succeeded message
after the publish).
20
Confidential

Create inter-tier policy rules (contd):
Note that Applied To to a Security-Group object is a new feature provided by NSX 6.1.
In the next step, we will check its application.
21
Confidential

Create management policy rules:
Add a new section on top of default section and name it MANAGEMENT.
Add the following policy rules in the section (click on + button on the section raw to add rules inside the section):
Name
Source
Destination
Service
Action
Applied to
Log
SSH to VM
192.168.110.
10
web-sv-01a
web-sv-02a
app-sv-01a
SSH
Allow
web-sv-01a
web-sv-02a
app-sv-01a
Log
Click on Publish Changes to enforce the new policy rules (check you get Last Publish Operation Succeeded message
after the publish).
22
Confidential

Create management policy rules (contd):
Management rules will allow SSH connectivity to WEB and APP VMs from Control Center (IP
192.168.110.10).
23
Confidential

Step objective: to check that DFW rules are properly downloaded to VM based on the Applied To
field application.
Check DFW configuration for web-sv-01a:

Open a PUTTY session on esxcomp-01a.
Use root / VMware1! to log into the ESXi host.
Type the following command to see all VM filter names:
# summarize-dvfilter
Retrieve vNIC 2 slot filter name for web-sv-01a and app-sv-01a:
web-sv-01a : nic-682809-eth0-vmware-sfw.2
Note: vNIC 2 slot filter name may vary based on vPOD
Type the following command to see DFW configuration
for web-sv-01a:
# vsipioctl getrules -f nic-682809-eth0-vmware-sfw.2
# vsipioctl getaddrsets -f nic-682809-eth0-vmware-sfw.2
24
Confidential

Step objective: to check that DFW rules are properly downloaded to VM based on the Applied To
field application.
Check DFW configuration for app-sv-01a and db-sv-01a:

Open a PUTTY session on esxcomp-02a.
Use root / VMware1! to log into the ESXi host.
Type the following command to see all VM filter names:
# summarize-dvfilter
Retrieve vNIC 2 slot filter name for web-sv-01a and app-sv-01a:
app-sv-01a : nic-683322-eth0-vmware-sfw.2
db-sv-01a: nic-745011-eth0-vmware-sfw.2
for app-sv-01a:
25
Confidential

Check DFW configuration for app-sv-01a and
db-sv-01a (contd):
for db-sv-01a:
Verify that each VM gets only the DFW policy rules that strictly applied to itself:
Using Applied To with Security-Group object allows to restrict the scope of DFW rule
publishing to members of the S-G only !
Check DFW configuration for web-sv-02a:

Open a putty session on esxcomp-01b.
Check DFW configuration for web-sv-02a using the same previous actions.
26
Confidential

Step objective: lets check that DFW rules are working properly meaning intra-tier and inter-tier
application access control are enforced as expected.
Connectivity and application access check from web-sv-01a:

Open (or re-use) a PUTTY session on web-sv-01a (root / VMware1!)
Test ping connectivity to other VMs (web-sv-02a, app-sv-01a, db-sv-01a)
using the following commands:
# ping 172.16.10.12 (web-sv-02a)
# ping 172.16.20.11 (app-sv-01a)
# ping 172.16.30.11 (db-sv-01a)
All ping should fails as there is no policy rule allowing it.
Send a HTTP request to web-sv-02a using the following command:
# curl http://172.16.10.12
You should see a response from web-sv-02a as DFW policy rule inside
INTRA-TIER ACCESS CONTROL section allows it.
Initiate a SSH session to app-sv-01a using the command:
# ssh 172.16.20.11
SSH should work as DFW policy rule inside INTER-TIER ACCESS
CONTROL section allows it.
27
Confidential

Connectivity and application access check from app-sv-01a:
Open (or re-use) a PUTTY session on app-sv-01a (root / VMware1!)
Test ping connectivity to other VMs (web-sv-01a, web-sv-02a, db-sv-01a)
using the following commands:
# ping 172.16.10.11 (web-sv-01a)
# ping 172.16.10.12 (web-sv-02a)
# ping 172.16.30.11 (db-sv-01a)
All ping should fails as there is no policy rule allowing it.
Simulate a MySQL request to db-sv-01a using the following command:
# mysql u root h 172.16.30.11 p
Type VMware1! when system prompt for password.
You should see a response from db-sv-01a as DFW

policy rule inside INTRA-TIER ACCESS CONTROL
section allows it.
28
Confidential

Verify Control Center can still access ABC Medical APP
OneArm web page:
Open a new tab on FIREFOX.
Click on ABC Medial App OneArm shortcut.
You should be able to see the
web page:
29
Confidential

Step objective: to check the behavior of Reject Action (versus Block Action).
Change default rule action from Block to Reject:

Go to NSX Home and click on Firewall menu.
Expand the default section Layer3.
Select Default Rule and change the action field from Block to Reject.
Enable Log for Default Rule.
Click on Publish Changes to enforce the new policy rules (check you get Last Publish Operation Succeeded message after
the publish).
You should have the same window as shown below:
30
Confidential

Check DFW configuration at VM layer:
Open (or re-use) a PUTTY session on esxcomp-01a (root / VMware1!).
Type the following command to see updated DFW configuration applied on VM (web-sv-01a here):
You should see the Reject keyword in the default rule (rule 1002)
31
Confidential

Test ping connectivity from web-sv-01a:
Open (or re-use) a console session on web-sv-01a (root / VMware1!).
Test ping connectivity to other VMs (web-sv-02a, app-sv-01a, db-sv-01a) using the following commands:
# ping 172.16.10.12 (web-sv-02a)
# ping 172.16.20.11 (app-sv-01a)
# ping 172.16.30.11 (db-sv-01a)
Reject action will send back to initiator:
ICMP unreachable with network administratively prohibited code for UDP, ICMP and other IP connections.
RST packets for TCP connections
You should obtain the following output:
32
Confidential

Check DFW packet log on ESXi host:
Open (or re-use) a PUTTY session on esxcomp-01a (root / VMware1!).
Type the following command to see DFW packets logs on the ESXi host:
# tail -f /var/log/dfwpktlogs.log
You should obtain this type of output:
33
Confidential

Change intra-tier policy rule (WEB to WEB) from Allow to Reject:
Select rule Web to Web.
Change Action field from Allow to Reject.
Double check Log is enabled for this rule.
Click on Publish Changes to enforce the new policy rules (check you get Last Publish Operation Succeeded message after
the publish).
34
Confidential

Check HTTP request from web-sv-01a:
Open (or re-use) a console session on web-sv-01a.
Simulate HTTP request using the following command:
# curl http://172.16.10.12
Reject action will send back to initiator:
ICMP unreachable with network administratively prohibited code for UDP, ICMP and other IP connections.
RST packets for TCP connections
You should obtain this type of output:
Check DFW packet log on ESXi host:

Open (or re-use) a PUTTY session on esxcomp-01a.
Type the following command to see DFW packets logs on the ESXi host:
# tail -f /var/log/dfwpktlogs.log
You should be able to see the log entries for HTTP request as
shown here:
35
Confidential

Modify DFW configuration for next steps:
Select rule Web to Web and modify Action field from Reject to Allow.
Click on Publish Changes to enforce the new policy rules (check you get a Last Publish Operation Succeeded message
after the publish).
36
Confidential

Step objective: to see capabilities provided by advanced rules filtering UI.
Advanced Rules Filtering UI capabilities:

Go to NSX Home and click on Firewall menu.
Click on Apply Filter button.
In Source field, enter IP address of web-sv-01a which is 172.16.10.11 and then click on Apply.
Only rules matching this condition will be displayed on the DFW policy rule table.
37
Confidential
Advanced Rules Filtering UI capabilities (contd):

In Source field, select VM app-sv-01a and then click on Apply.
38
Confidential

Delete Source field content, select Action equal Reject and then click on Apply.
39
Confidential

Change Action to Any and type WEB in the Name field. Then click on Apply.
40
Confidential

Delete Name field content and select HTTP in Specify Service field . Then click on Apply.
Click on Removed Applied Filter button to see again all DFW rules:
41
Confidential

Step objective: to configure and verify CPU/Memory/CPS Threshold function.
Retrieving Threshold values using REST API:

Click on RESTClient icon inside FIREFOX.
Select Headers -> Custom Header. Use Name = Content-Type and Value = application/xml. Click on OK.
Select Authentication -> Basic Authentication. Use Username = admin and Password = VMware1! . Click on OK.
Select Method = GET and enter the following URL information:
https://192.168.110.42/api/4.0/firewall/stats/eventthresholds
Click on SEND.
42
Confidential
43
Confidential
Retrieving Threshold values on ESXi host using CLI:

Open (or re-use) a PUTTY session on esxcomp-01a ( use root / VMware1! ).
Enter the following command to retrieve CPU/Memory/CPS threshold set on the host:
# vsipioctl getthresholds
You should obtain this result:
44
Confidential

Setting Threshold values using REST API (RESTClient UI):
Select Method -> PUT.
Enter the following URL information:
https://192.168.110.42/api/4.0/firewall/stats/eventthresholds
In the Body section, enter the following information:
<eventThresholds>
<cpu>
<percentValue>1</percentValue>
</cpu>
<memory>
<percentValue>1</percentValue>
</memory>
<connectionsPerSecond>
<value>1</value>
</connectionsPerSecond>
</eventThresholds>
Click on SEND button. Check that success is displayed in the Response section.
45
Confidential

Generate Traffic to trigger threshold crossing:
Open a console session on web-sv-02a ( use root / VMware1! ).
Enter the following command to send high number of HTTP request to web-sv-01a:
# ab2 n 6000000 c 100 w http://172.16.10.11/
(dont forget the / at the end of the URL otherwise the command will not work)
Check on ESXi host real time CPU/Memory/CPS value:

Type the following command:
# vsipioctl getthresholds
You should be able to see current usage values exceed
threshold configuration
46
Confidential
Check alarms raised in NSX Manager System Events window:

Go to NSX Home -> NSX Managers.
Click on NSX Manager IP address (192.168.110.42) and select Monitor -> System Events.
You should be able to see alarms related to DFW CPU/Memory/CPS threshold crossed:
47
Confidential

Check logs on ESXi host:
Go to /var/log using the following command:
# cd /var/log
Type the following command to see syslogs related to CPU/Memory/CPS threshold alerts:
/var/log # grep threshold vsfwd.log
You should be able to see the following messages:
Stop ab2 command running on web-sv-02a.
48
Confidential
NSX Service Composer Lab Exercises
49
Confidential
Lab Exercise 11 Deploy/Apply/Automate w/Service Composer

Goal : Demonstrate TrendMicro Deep Security integration with Guest & Network introspection
services and NSX Service Composer. We will be using AV and IPS features of Trend Micro.
1) First as we changed the DFW default rule to Block in the previous exercise we will now allow
certain traffic for future lab exercises. Add sec-mgr-01a and big-iq-01a to the NSX DFW
Exclusion List to ensure it is not blocked by the firewall rules defined in the previous lab
exercise. Refer to the NSX Admin Guide on the desktop for details on where to configure an
exclusion
2) Create 2 DFW rules at the top of the Default Section to allow inbound and outbound access for
VM: av-win7-01a
3) Then power on Virtual Machine: sec-mgr-01a in the Management and Edge Cluster
4) Once the Windows VM has finished booting
Click to open a new tab in Firefox on the ControlCenter
Click on the Trend Micro Deep Security bookmark
Login to Trend Micro Deep Security Manager
Login with username = admin
Password = VMware1!
Click Sign In
50
Confidential
Lab Exercise 11 Service Insertion

The first step is to insert the Trend Micro service into the NSX platform.
4) After logging in, you will see the Trend Micro Deep Security
dashboard as shown below.
5) Click on Computers. On the Computers tab,

click on New -> Add VMware vCenter
6) Complete the registration for both vCenter & NSX to insert

service into NSX (accept any certificates) and click Finish
51
Confidential
Lab Exercise 11 Service Insertion

Verify Service Insertion is successful by going to the Service Defintions pane in the vSphere Web Client
Also verify that you can see all

VMs and ESXi hosts in the
Computers tab of the Trend
Micro console
52
Confidential
Lab Exercise 11 Deploy Guest Introspection Service

The next step is to deploy Guest Introspection Service as we have already completed successful
Host Preparation. Under Networking & Security-> Installation-> Service Deployments, click the
green Add and choose Guest Introspection while leaving the default schedule as Deploy Now. Use
the following values:
Datacenter: ABC Medical

Cluster: Compute Cluster B
Datastore: ds-site-a-nfs02
Network: Compute_VDS - Mgmt
IP assignment: DHCP
4
53
Confidential
Lab Exercise 11 Deploy Guest Introspection Service

Deployment and status update will take several minutes, so after some time verify
successful Guest Introspection Service Deployment Status has changed from Warning
to Up:
This process deploys a USVM

Universal Services VM per Host in the
prepared Cluster. Review USVM
progress and check for Guest
Introspection VMs under ESX Agents
Resource Pool. Each ESXi host in the
cluster you have selected for Service
deployment will have a dedicated USVM
54
Confidential
Lab Exercise 11 Deploy Trend Micro Deep Security Service

The Next step is to deploy the TrendMicro Service VM. The deployment steps are
similar to Guest Introspection Service.
Under Networking & Security->Installation > Service Deployments, select Add and
choose Trend Micro Deep Security Service.
Datacenter: ABC Medical

Cluster: Compute Cluster B
Datastore: ds-site-a-nfs02
Network: Compute_VDS - Mgmt
IP assignment: DHCP
55
Confidential
Lab Exercise 11 Deploy Trend Micro Deep Security Service

This will also take several minutes to complete - verify that the Trend Micro Deep
Security Service deployment is successful:
This process deploys a Trend Micro SVM

Service VM per Host in the prepared
Cluster. Each ESXi host in the cluster
you have selected for Service
deployment will have a dedicated Trend
Micro SVM
56
Confidential
Lab Exercise 11 Prepare Trend Micro

We are going to run tests on win7-av.corp.local. The VM is available in
cluster B (as av-win7-01a). The first step is to power it on
Notice the eicar.com executable on the desktop see if you are able to run it
No activate the VM in TrendMicros console - win7-av.corp.local to run
security tests
Click on the Computer tab, click on the vCenter and search for the VM. Right
click on the VM,
click Actions -> Activate/Reactivate.
Verify that the VM is activated and the status changes from unmanaged to
managed
57
Confidential
Lab Exercise 11 Service Composer

Now a Security Group is needed to group the VMs protected by the Trend Micro Deep
Security service. Navigate to Service Composer-> Security Groups
Create and define the SG-Protected Security Group that includes the Virtual Machine
av-win7-01a
58
Confidential

Now we will create the Security Policy Object
for the SG-Protected SG under
Service Composer-> Security Policies
Create a Security Policy with a name of AV

Protection Security Policy and a Weight of
50,000
Under Guest Introspection Services Add a

service with:
Name: Antivirus Scan

Action: Apply
Service Name:
Trend Micro Deep Security
Service Profile:
Trend Micro Deep Security_Deep Security
Profile
State: Enabled
Enforce: Yes
Then click Finish to add the security

policy
59
Confidential

Next add a Security Group that will be used to Isolate Servers and restrict all
network access if a vulnerability or Virus is found by the Symantec Security
Appliances. Again navigate to Service Composer-> Security Groups
Create and define the Quarantine-Prod Security Group to include Dynamic

Membership defined by Security Tag ANTI_VIRUS.VirusFound.threat=high
60
Confidential

Now add the corresponding Security
Policy Object for the Quarantine-Prod
Security Group
Create the Quarantine-Prod SPO Security
Policy with a Weight of 51,000 and add
the following 2 Firewall rules:
Source
Destination
1. Policies Security Groups Any
Any
Block
2. Any
Any
Block
Policies Security Groups
Then click Finish

61
Service Action
Confidential

Assign the AV Protection Security Policy Security
Policy to the SG-Protected Security Group
Open the Service Composer-> Canvas tab and

confirm the av-win7-01a VM is a member of the
SG-Protected Security Group
62
Confidential

Also assign the Quarantine-Prod SPO
Security Policy to the Quarantine-Prod
Security Group
And check the Service Composer

Canvas to confirm there are no Virtual
Machines in the Quarantine-Prod
Security Group
63
Confidential
Lab Exercise 11 AV Enforcement with DFW Test

1. Open the Trend Micro console and double
click on the av-win7-01a VM
2. Click on the Anti-Malware link
on the left pane
Select Anti-Malware and on the General tab,

change the Anti-Malware Configuration to
On
Now on the Manual Scan section, uncheck

Inherited check box, then assign Default
Manual Scan Configuration configuration
Click Save
In the lab exercise we will not configure a
Real-Time Scan to allow the process to be
observed (rather than having infected files
cleaned up automatically), although in
production you would typically use
real time scanning
64
Confidential

4. Click on Advanced tab. Go to the
NSX Security Tagging section.
5. Uncheck Inherited and Apply NSX
Security Tag only if remediation
action fails.
6. Select
ANTI_VIRUS.VirusFound.threat=high
in the NSX Security tag.
7. Click Save and then Close the window.
65
Confidential

4. Open a cmd window on the
Control Center and run a
continuous ping test to the avwin7-01a VM to verify it is
accessible
5. Right-click on the VM avwin7-01a in the Trend Micro
console and then click on
Actions > Full Scan for Malware
to start the scan
6. Take a short break as the
scan will take several minutes
complete
66
Confidential
After the scan

completed, check
the VM Summary
screen to see we
have two SG
memberships and
the security tag is
applied
Go to Service
Composer ->
Canvas View and
verify the VM
membership of the
Quarantine Prod
security group
67
Confidential
Verify that the ping test running on the VM now shows

connectivity lost
This quarantine process allows the NSX/security administrator to

investigate the VM and ensure there are no other issues, before
network connectivity is restored
While dynamic detection and enforcement of security policy

highlights the flexibility of NSX Service Composer and one of the
available 3rd party integration solutions
68
Confidential
Lab Exercise 11 - Cleanup
Before proceeding to the next test, update the Security Tag on avwin7-01a virtual machine manually. From Summary Tab of the avwin7-01a virtual machine in the Security Tags Pane select Manage.
Uncheck the ANTI_VIRUS.VirusFound.threat=high Security Tag

and click OK.
69
Confidential
Lab Exercise 11 IPS Enforcement
First test that we can use the search function of the Admin Portal by
accessing the admin page again and enter the following into the
search input: google
This should return the same

string as a search result
70
Confidential
Now we will update the AV Protection Security Policy Security

Policy with IPS rules.
Navigate to Service Composer-> Security Policies and edit the AV

Protection Security Policy.
71
Confidential
Add 2 new rules in the Network Introspection tab.

Redirect Outbound Traffic to Trend Micro
Redirect Inbound Traffic to Trend Micro
72
Confidential
Click Finish to update the security policy with network

introspection rules.
73
Confidential
Since the security policy is already applied to a security group,

verify that the new rules are reflected in the security group.
Go to Canvas View and click
on the security group SG
Protected.
Verify you see the rules that you created.
74
Confidential

Lets create the test signature that we would like to block.
1. Open the Trend Micro console and double click on the avwin7-01a VM. Click on the Intrusion Prevention link on the left
pane.
2. In the General tab, section Intrusion Prevention, select

configuration to On
3. Select on Assign /
Unassign in the Assign
Intrusion Prevention rule
section to open a new
window
75
Confidential
We will create a specific IPS signature for our test. Click on New - >
New Intrusion Prevention Rule in the IPS Rules window.
Change the rule name in the

General tab to Test IPS
Select Application Type as
Web Client Internet Explorer
In the Rules tab add google as
a signature and the Option tab
select schedule as Every Day
All Day
76
Confidential
Click Save to apply the IPS rule to the VM and to apply the policy
77
Confidential
Wait till the policy is applied, then open IE again and test searching
Again using the string: google
This time the page should

be blocked by the Trend
IPS
78
Confidential

From the Trend Micro Deep Security console again double click on the avwin7-01a VM and access the Intrusion Prevention menu
1. In the Events tab, section Intrusion Prevention, click on Get Events at the
bottom of the screen
2. This should return a match for the Test IPS rule where the connection
that matched the google pattern was Reset
3. Double Click on the Event tab
to retrieve detailed information

on the traffic which was
redirected by NSX to the Trend
IPS
4. You have now completed the

Service Composer lab
exercises
79
Confidential
NSX F5 Integration Lab Exercises
80
Confidential
NSX vSphere Training Management Components
Control
Center
vCenter
Server A
.22
.10
.79
Log
Insight
.75
vCenter
Orchestrator
NSX
Manager
.201
.42
NSX
Controller
Node 1
.202
NSX
Controller
Node 2
.203
NSX
Controller
Node 3
F5
BIG-IQ
.91
.91
Storage
Appliance
.60
Mgmt: 192.168.110.0/24
.85
Trend
Deep
Security
F5-Mgmt: 192.168.111.0/24
.2
.2
vPod Router
.2
vCenter
Server B
.22
Mgmt Site B:
192.168.210.0/24
81
Confidential
NSX vSphere Training Logical View
.10
Control Center
192.168.110.0/24
.2
F5-Mgmt
192.168.111.0/24
Mgt
192.168.110.0/24
Mgmt_Edge_VDS-HQ_Uplink
192.168.100.0/24
.2
Dynamic Routing
(BGP)
.3
Perimeter NSX Edge
.1
(HA, FW, NAT, LB, VPN Services)

Pool .106/109
Pool .106/109
F5 BIG-IP
VE
(LB)
.1
Pool .106/109
Dynamic Routing
(BGP)
Pool .106/109
Transit-Network-01
192.168.10.0/29
.6 (BGP)
.1
Distributed Logical Router

.1
.1
Web-Tier-01
172.16.10.0/24
web-sv-01a
.11
82
web-sv-02a
.12
DB -Tier-01
172.16.30.0/24
App-Tier-01
172.16.20.0/24
app-sv-01a
.11
db-sv-01a
.11
Confidential
Distributed Firewall
Lab Exercise 12 F5 NSX Integration
1. Validation of readiness of the environment

2. NSX/F5 Registration
3. F5 BIG-IP VE Auto-Deployment
4. NSX/F5 ADC configuration
83
Confidential
Lab Exercise 12 F5 NSX Integration Step 1

84
Confidential
Update BIG-IQ NIC interfaces with VDS
Note:
Those port groups should have been created during Day1 on Mgmt_Edge_VDS.
If not created yet, create them:
From vCenter Home -> Networking, Create New Distributed Port Group
85
Confidential
Validate the BIG-IP VE OVF is accessible

To verify the BIG-IP OVF file is accessible, open a browser and
enter the following URL:
http://192.168.110.60/BIGIP-11.5.1.0.0.110-ide.ovf
Note: The web server hosting the BIG-IP VE OVF file is the storage server
86
Confidential
Validate BIG-IQ IP configuration

BIG-IQ Management interface and default gateway:
This is the interface connected to F5 Management
[root@big-iq-01a:Active] config # ifconfig eth0
eth0
Link encap:Ethernet HWaddr 00:50:56:8E:32:9E
inet addr:192.168.111.91 Bcast:192.168.111.255
[root@big-iq-01a:Active] config
Kernel IP routing table
Destination
Gateway
<snip>
0.0.0.0
192.168.110.2
0.0.0.0
192.168.111.2
Mask:255.255.255.0
# netstat -rn
Genmask
Flags
0.0.0.0
0.0.0.0
UG
UG
MSS Window
0 0
0 0
irtt Iface
0 internal
0 eth0
Once these details are verified you can proceed with configuration of the F5
NSX Integration
87
Confidential

88
Confidential
[BIG-IQ] Create BIG-IQ connector

From BIG-IQ Cloud -> Connectors, click on + and follow the screenshots below
Password for all inputs is: VMware1!

89
Confidential
[BIG-IQ] Create BIG-IQ connector

Validation:
From NSX Home -> Service Definitions
90
Confidential
[BIG-IQ] Create BIG-IQ Tenant

From BIG-IQ Cloud -> Tenants, click on +
91
Confidential

92
Confidential
[NSX] Create F5 IP Pools

From NSX Home -> NSX Managers, click on NSX Manager, access Manage ->
Grouping Objects -> IP Pools, and click +
The Future BIG-IP VE will use the following IP Addresses:
HQ_Uplink
192.168.110.105-109/24
Mgt
192.168.110.105-109/24
F5-Mgt 192.168.110.105-109/24
93
Confidential
Web-Tier-01
192.168.110.105-109/24
[NSX] Enable Load Balancing with Service Insertion

From NSX Home -> NSX Edges, double-click on Edge, access Manage ->
Load Balancer, and click Edit
Enable Load Balancer: Checked

Enable Service Insertion: Checked
Service Insertion: F5-NSX Connector
Note: This is the name of the NSX/F5 connector.
Service Configuration: F5 ADC Make a BIG-IP VE

Note: Currently the only option available (will be enhanced once BIG-IP physical
appliances will be supported)
94
Confidential

Cont. :
Service Instance Runtime Configuration

Modify the BIG-IP VE interfaces as follow:
Note1: Currently you must use IP allocation
Mode of IP Pool.
Note2: The interface order is important, do not
add or delete interfaces, only modify the existing
4 Interfaces to match the screenshot above
Note3: Do not use spaces in the interface name
95
Confidential

Cont. :
Service Instance Runtime Configuration

Modify the BIG-IP VE interfaces as follow cont. :
1. F5-Mgt (this is the BIG-IP VE management interface)
2. HQ-Uplink (this is the BIG-IP VE external interface)
3. Web-Tier01 (this is the BIG-IP VE interface where the load balanced servers are)
4. Mgt (this is the BIG-IP VE HA interface)
Note: BIG-IP VE HA is not currently supported. This interface is currently used for
mgt access.
Follow the order above precisely and edit interfaces to match the portgroup & IP
configuration with the screenshot on the previous page, rather than trying to
delete & adding new interfaces
96
Confidential

Cont. :
Required Service Configuration Parameter

Leave blank
97
Confidential

Cont. :
Typed Service Configuration Parameters

Modify the options as follow:
Make a new F5 BIG-IP VE?: yes
98
This is to deploy a new F5 BIG-IP VE. This should always be yes.

Fully qualified host name of BIG-IP VE?: big-ip-01a.corp.local
Name of BIG-IP node template: BIG-IP-VE-11.5.1
If not provided then one will be randomly selected.
HTTP URL of BIG-IP OVF file?: http://192.168.110.60/BIGIP-11.5.1.0.0.110-ide.ovf
Note: The first time its required, as you must specify where to find the BIG-IP-VE
OVF. If not specified it will use the last one specified.
Admin password of BIG-IP VE?: VMware1!
Confidential

Cont. :
Enable Acceleration: Unchecked

This option doesnt apply with Service Insertion.
Logging: Unchecked
This option doesnt apply with Service Insertion.
Log Level: Info

This option doesnt apply with Service Insertion
99
Confidential

Validation:
Validate the deployment of BIG-IP-VE

Few seconds later, the BIG-IP-VE should be deploying
From NSX Home, on the far right Recent Tasks, select All Users Tasks
100
Confidential

Validation cont. :
Validate the BIG-IP-VE gets its final Management IP configured via NSX
Once booted and the VMware Tools running, the F5 BIG-IP VE IP moves
from 127.3.0.0
to 192.168.1.245
to IP received by DHCP server
to final IP configured from NSX
Note: Each step can take a couple of minutes (especially the last step)
From vCenter Home -> Hosts and Clusters, click on BIG-IP VE
101
Confidential

Validation cont. :
Validate the BIG-IP-VE gets added in BIG-IQ

From BIG-IQ Cloud -> Devices
The state Pending lasts for approximately 20 minutes ! This will be improved in a
future BIG-IQ maintenance release
102
Confidential

Validation cont. :
Verify configuration is pushed to the BIG-IP VE

From BIG-IQ Cloud -> Devices:
Also verify the Service Insertion Status is:

In Service
via the vSphere Web Client
103
Confidential
[BIG-IQ] Create a BIG-IQ Catalog

Simple
From BIG-IQ Cloud ->Catalog, click on +
104
Confidential

From BIG-IQ Cloud ->Catalog, click on +
Advanced
105
Confidential

Validate F5 Catalogs are well created on NSX
From NSX Home -> Service Definitions, double-click on BIG-IQ Connector, Manage > Profile Configurations
106
Confidential

107
Confidential
[NSX] Configure Pool and VIP

.10
Control Center
192.168.110.0/24
.2
Mgmt_Edge_VDS-HQ_Uplink
192.168.100.0/24
.2
Dynamic Routing
(BGP)
.3
Perimeter NSX Edge
.1
(HA, FW, NAT, LB, VPN Services)

VIP .110/111
F5 BIG-IP
VE
(LB)
.106
.1
Dynamic Routing
(BGP)
Transit-Network-01
192.168.10.0/29
.6 (BGP)
.1
.106
Distributed Logical Router

.1
.1
Web-Tier-01
172.16.10.0/24
Pool-01
108
web-sv-01a
.11
web-sv-02a
.12
App-Tier-01
172.16.20.0/24
app-sv-01a
.11
Confidential
DB -Tier-01
172.16.30.0/24
db-sv-01a
.11
Distributed Fire
[NSX] Configure Pool

From NSX Home -> NSX Edges, double-click on Edge, go under Manage ->
Load Balancer -> Pools
Note: The fields Algorithm, Algorithm Parameters, Monitors, Transparent can be left as
default since they are not used (information is taken from BIG-IQ Catalog).
109
Confidential
[NSX] Configure VIP simple

Load Balancer -> Virtual Servers
Note: The fields Protocol, Port, Connection Limit, Connection Rate Limit can be left as
110
Confidential
[NSX] Configure VIP advanced

Load Balancer -> Virtual Servers
Note: The fields Protocol, Port, Connection Limit, Connection Rate Limit can be left as
111
Confidential

Validate the Applications creation in BIG-IQ:
From BIG-IQ Cloud -> Applications
112
Confidential

Validate access to the VIP:
From Control Center: http://192.168.100.110/finance/data.html
113
Confidential

NSX For Vsphere Advanced Training: Lab Exercises

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

NSX For Vsphere Advanced Training: Lab Exercises

Загружено:

Авторское право:

Доступные форматы

NSX for vSphere

NSX Distributed Firewall Lab Exercises

NSX vSphere Training Logical Topology and Security-Groups

NSX vSphere Training Allowed Traffic (Inter-Tier and Intra-Tier)

Default rule set to block action

Lab Exercise 10 NSX Distributed Firewall

Step 1: Logical Topology and Connectivity Check.

Lab Exercise 10 NSX Distributed Firewall Step 1

Check VMs are connected on the right logical switches:

Verify web-sv-01a can ping everything:

Lab Exercise 10 NSX Distributed Firewall Step 1

Verify web-sv-01a can SSH to all other VMs:

Verify web-sv-01a can send HTTP request to

Lab Exercise 10 NSX Distributed Firewall Step 1

Verify app-sv-01a can send SQL request to

Lab Exercise 10 NSX Distributed Firewall Step 1

At this point of time, everything should work

Lab Exercise 10 NSX Distributed Firewall Step 2

Create Security-Group SG-WEB using dynamic inclusion

Click on finish after configuring dynamic membership.

Lab Exercise 10 NSX Distributed Firewall Step 2

Create Security-Group SG-DB using dynamic

Lab Exercise 10 NSX Distributed Firewall Step 2

Clicking on the number (link) will show the VM name:

Lab Exercise 10 NSX Distributed Firewall Step 3

Create SG-TAG-WEB and associate it to web-sv-01a:

Lab Exercise 10 NSX Distributed Firewall Step 3

Create SG-TAG-WEB and associate it to web-sv-01a

Lab Exercise 10 NSX Distributed Firewall Step 3

Associate the same tag SG-TAB-WEB to web-sv-02a now:

Lab Exercise 10 NSX Distributed Firewall Step 3

Check Security-Group SG-WEB is now correctly populated:

Lab Exercise 10 NSX Distributed Firewall Step 4

Change default rule from Allow to Block:

Lab Exercise 10 NSX Distributed Firewall Step 4

Add the following policy rule in this new section:

Lab Exercise 10 NSX Distributed Firewall Step 4

Lab Exercise 10 NSX Distributed Firewall Step 4

Lab Exercise 10 NSX Distributed Firewall Step 4

Lab Exercise 10 NSX Distributed Firewall Step 4

Lab Exercise 10 NSX Distributed Firewall Step 4

Lab Exercise 10 NSX Distributed Firewall Step 5

Check DFW configuration for web-sv-01a:

Lab Exercise 10 NSX Distributed Firewall Step 5

Check DFW configuration for app-sv-01a and db-sv-01a:

Lab Exercise 10 NSX Distributed Firewall Step 5

Check DFW configuration for web-sv-02a:

Lab Exercise 10 NSX Distributed Firewall Step 6

Connectivity and application access check from web-sv-01a:

Lab Exercise 10 NSX Distributed Firewall Step 6

You should see a response from db-sv-01a as DFW

Lab Exercise 10 NSX Distributed Firewall Step 6

Lab Exercise 10 NSX Distributed Firewall Step 7

Change default rule action from Block to Reject:

You should have the same window as shown below:

Lab Exercise 10 NSX Distributed Firewall Step 7

Lab Exercise 10 NSX Distributed Firewall Step 7

You should obtain the following output:

Lab Exercise 10 NSX Distributed Firewall Step 7

You should obtain this type of output:

Lab Exercise 10 NSX Distributed Firewall Step 7

You should have the same window as shown below:

Lab Exercise 10 NSX Distributed Firewall Step 7