Cisco dCloud

Cisco Firepower Next-Generation Firewall 6.6, and 6.7 Features Lab

v1.7
dCloud: The Cisco Demo Cloud

Last Updated: 31-March-2021

IMPORTANT! This content is community developed and is not subject to standard dCloud verification or support. Please
contact dCloud Support for more information.

About This Guide

This guide for the preconfigured demonstration includes:
• Requirements
• About the 6.6 & 6.7 Release and this Lab

• Scenario Dependencies
• Topology
• Get Started

• 6.7 Scenarios
o Scenario 1. TLS Server Identity Discovery
o Scenario 2. FMC Device Health Monitoring
o Scenario 3. SNMP Device Health Monitoring
o Scenario 4. FMC Copying and Moving Rules
o Scenario 5. Route Based VTI Site-to Site VPN
o Scenario 6. Remote Deployments
o Scenario 7. FMC User Multi-Domain
o Scenario 8. FMC SAML 2.0 and RA-VPN

o Scenario 9. FDM Intrusion Policy/Snort 3

o Scenario 10. Interface Object Optimization
o Scenario 11. FMC Audit Enhancements, Selective Deployment, and Rollback

o Scenario 12. Device Level Filtering for User Awareness Sessions

o Scenario 13. PxGrid 2.0 remediation with ISE using ANC
o Scenario 14. Software Upgrade Enhancements on FMC

o Scenario 15. FMC High Availability

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 173
 Cisco dCloud

• 6.6 Scenarios
o Scenario 16. VRF Support in the FMC
dCloud: The Cisco Demo Cloud
o Scenario 17. VRF Support in the FDM
o Scenario 18. Explore Redistribution of Leaked Routes
o Scenario 19. Time Base Policy in the FMC

Requirements
The table below outlines the requirements for this preconfigured demonstration.

Table 1. Requirements

Required Optional
● Laptop ● Cisco AnyConnect®

About the 6.6, & 6.7 Release and this Lab

The purpose of this lab is to cover new features provided by the 6.6 and 6.7 releases. Because of limitations in the
pods and time constraints, only selected features are included.
Other new features, such as configuration backup and restore, can be performed but were left out of the lab for
practical purposes. The lab pods provide an FTD (NGFW3) that is not used in the scenarios, so students may try
configuring and testing features not covered in the lab without fear of interfering with the lab Scenarios.

Scenario Dependencies
6.7:
Scenario 14 Route Based VTI Site to Site VPN and Scenario 15 Remote Deployments are dependent on each
other. If you plan to do these Scenarios, you must perform Scenario 14 first. The other exercises are independent.

Topology
This content includes preconfigured users and components to illustrate the scripted scenarios and features of the
solution. Most components are fully configurable with predefined administrative user accounts. You can see the IP
address and user account credentials to use to access a component by clicking the component icon in the
Topology menu of your active dCloud session and in the scenario steps that require their use.

NOTE: For simplicity, not all IP addresses and VLANs are shown.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 2 of 173
 Cisco dCloud

Figure 1. Lab Topology

dCloud: The Cisco Demo Cloud

Credentials
Login credentials are provided in line in the guide steps as needed. However, for your convenience, the following
table lists the credentials used in these scenarios.

Table 2. Device Login Credentials

VM Login Password

FMC admin C1sco12345

All NGFWs admin C1sco12345
All Windows Workstations Administrator C1sco12345
Splunk admin C1sco12345
ISE and ISE PIC admin C1sco12345
Inside Linux Server root C1sco12345
Outside Linux Server root C1sco12345
CSR60, CSR61, CSR62, CSR63, CSR64 admin C1sco12345

There are also several users that have been created for purposes of passive authentication and RBAC.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 3 of 173
 Cisco dCloud

Table 3. User Credentials

Login Password Details

dilbert C1sco12345 Active Directory user in Engineering group dCloud: The Cisco Demo Cloud
harry C1sco12345 Active Directory user in HR group
ira C1sco12345 Active Directory user in Finance and Investment groups
rita C1sco12345 Active Directory user in IT group
alicia C1sco12345 ISE local user, FDM Admin user
oliver C1sco12345 ISE local user, FDM Read Only user
victoria C1sco12345 ISE local user, VPN user
william C1sco12345 ISE local user, FDM Read Write user

Get Started
BEFORE PRESENTING
Cisco dCloud strongly recommends that you perform the tasks in this document with an active session before
presenting in front of a live audience. This will allow you to become familiar with the structure of the document
and content.
It may be necessary to schedule a new session after following this guide in order to reset the environment to its
original configuration.

PREPARATION IS KEY TO A SUCCESSFUL PRESENTATION.

Follow the steps to schedule a session of the content and configure your presentation environment.
1. Initiate your dCloud session. [Show Me How]

NOTE: It may take up to 10 minutes for your session to become active.

2. It is assumed in this guide that you are connecting to all devices from the Jumpbox RDP session, using the
provided details.

NOTE: You can also connect to the workstation with Cisco AnyConnect VPN [Show Me How] and the local RDP
client on your laptop [Show Me How]
Jumpbox: 198.18.133.50, Username: administrator, Password: C1sco12345

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 4 of 173
 Cisco dCloud

Scenario 1 - TLS Server Identity Discovery

TLS server certificate details are encrypted in the TLS 1.3 compared to TLS 1.2 protocol version, where this
dCloud: The Cisco Demo Cloud
information was communicated using cleartext. With that in mind, the firewalls lose the ability to acquire a server
certificate for TLS sessions in plain text to implement the necessary policies efficiently. Therefore, access control
and SSL policy enforcement based on AppId or URL filtering within a TLS 1.3 connection combined with a spoofed
SNI can be circumvented by an intruder.
The Firepower 6.7 feature, TLS Server Identity Discovery, helps the Cisco next-generation firewall learn TLS
certificate details from servers that support TLS 1.3 and earlier versions of TLS protocol. As such, this helps the
firewall resolve the inherent difficulty of the TLS 1.3 encrypted server certificate, effectively implement the policies
(ACP/SSL), and allows it to determine definitively whether the TLS session should be decrypted or not.

NOTE: This feature is supported by Snort 2 (FMC), Snort 3 (FDM/FMC), is supported in true inline deployments on
all Cisco Firepower hardware platforms, and will also work in VRF’s. FTD inline tap or passive deployment mode is
not supported. FTD is deployable in routed, transparent, and inline-set mode.

Objectives
• Enable application detection and URL filtering for TLS 1.3 flows
• Investigate Default Behaviour (Access Control Policy Enabled Only)
• Access Control Policy with TLS Server Identity Discovery Enabled

• Detection of SNI Mismatch without SSL Policy

• Enable the TLS Server Identity Discovery feature
• Enable handling of TLS 1.3 sessions with TLS Probe

• Enable TLS Probe Logging for debugging purposes and visibility

• Certificate not found in local cache
• Certificate present in local cache

Application detection and URL filtering matching within TLS 1.3 flows
Firewall features such as URL filtering (categorization and reputation) and Application Detection (AppId) rely on the
information in the TLS certificates to enforce the policy (ACP / SSL), such as
1. Server Name Indication (SNI)
2. Common Name (CN)
3. Subject Alternative Names (SANs)
4. Organizational Unit (OU)

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 5 of 173
 Cisco dCloud

SNI information is extracted from the ClientHello handshake message, and CN, SAN, OU are obtained from the
server certificate.
dCloud: The Cisco Demo Cloud

With the adoption of the TLS 1.3 protocol, most of the useful information needed to enforce firewall rules effectively
is encrypted, and details kept in cleartext such as SNI can be spoofed. Hence it cannot be used as a reliable
mechanism to enforce the policy. In the steps below, we will demonstrate how an intruder can use the SNI to
bypass firewall policy and what configuration you can apply to validate the SNI further.

Task 1. Investigate Default Behaviour (Access Control Policy Only Enabled)

1. Create an Access Control Policy

In the jumpbox device, open the Firefox browser, which opens an automatic connection to FMC (fmc.dcloud.local)
Press “Log In” button to authenticate into the FMC (admin/C1sco12345 are prefilled credentials)
In FMC, navigate to the Policies > Access Control page.
Click on “New Policy”
• Enter name “TLS Policy Demo”
• Keep Default Action set to “Block all traffic”
• Select NGFW1 device under Targeted Devices and click “Add to Policy”
• Click Save and confirm with Yes the device reassignment to a new Access Control Policy (ACP)

2. Create an Access Control Rule

Click “Add Rule”
• Enter Name “Allow FB App”
• Keep action set to Allow traffic
• Click Applications tab- Under Available Applications, search for “facebook” > Select “All apps matching the filter” >
Add to Rule

• Under the Logging tab, enable “Log at End of Connection”

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 6 of 173
 Cisco dCloud

At the bottom of the ACP, click next to Default Action “Access Control: Block All Traffic” Logging button

dCloud: The Cisco Demo Cloud

• Enable checkbox for “Log at Beginning of Connection”

NOTE: Logging every event is valuable for this lab exercise, but in a production environment, it is not best practice
to enable logging for the default rule.

• Click OK

Click on “Default Prefilter Policy” from the drop-down menu, select “Demo Prefilter Policy”
Save Access Control Policy Settings
Navigate to Policies > Prefilter Policy
• Edit Demo Prefilter Policy
• Select “Add Prefilter Rule” - Enter Name: “Fastpath DNS traffic”
• Set action to “FastPath”
• Under Ports tab, add to Selected Destination Ports:
o TCP (6) 53 and click Add
o UDP (17) 53 and click Add
• Click Add.
• Click Save to confirm changes made to Prefilter Policy
.

3. Policy Deployment
• Navigate to Deploy > Deployment > select checkbox next to NGFW1 > Deploy > Deploy
• Wait for policy deployment to succeed.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 7 of 173
 Cisco dCloud

Task 2. TLS Server Identity Discovery Disabled and SNI not present

1. Open PuTTY application in jumpbox, search for “Inside Linux Server” under “Saved Sessions,” select found
dCloud: The Cisco Demo Cloud
server, and click Open
Enter credentials root/C1sco12345
Generate traffic to the https://walmart.com website using TLS1.3 protocol version with the following CLI command (it
might take a couple of seconds for the command output to show on the screen)

openssl s_client -connect walmart.com:443 -tls1_3

Navigate back to FMC under Analysis > Connections > Events, click on “Edit Search,” then under Networking, enter the
following value into Initiator IP “198.19.10.200” (Inside Linux Server) and click Search
Click on Table View of Connection Events
Click on any empty Connection Events Columns fields (on X button) and enable the following columns
• Select SSL Flow Flags
• Select SSL Flow Messages
• And click Apply

Observe connection event details

• Action = Block
• Reason = N/A
• SSL Flow Flags = N/A
• SSL Flow Messages = N/A
• Web Application = Walmart
• URL = https://walmart.com

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 8 of 173
 Cisco dCloud

Task 3. TLS Server Identity Discovery Disabled and with SNI present
1. Navigate back to the opened PuTTY session to the Inside Linux machine and execute this command
dCloud: The Cisco Demo Cloud

openssl s_client -connect walmart.com:443 -tls1_3 -servername facebook.com

Servername argument specify hostname / SNI

NOTE: This will set the SNI of the connection to facebook.com. When SNI is used, the hostname of the server is
included in the TLS handshake. SNI provides a solution for a shared IP address that hosts multiple web
servers/domains that allows unique certificates to be used for each domain. In TLS 1.3 flows, SNI also helps
intermediate devices determine where the client is going by providing this information in clear text. Other details
that indicate the website/application that client is accessing is in the server certificate (i.e., CN = Common Name) -
in TLS 1.3 that is encrypted compared to TLS 1.2 protocol. However, for security reasons, the firewall should not
make a decision purely on SNI information as that can be spoofed by an intruder.

In this task, the client is trying to access Walmart.com over HTTPs protocol. The website/Application will typically be
detected on NGFW based on the TLS handshake, and it will make the decision based on CN that is part of the
Server Certificate. However, since in the TLS 1.3 connection this information is encrypted, the device cannot see
where the client goes in the default state.

2. Navigate back to FMC, refresh connection events page through pause icon and resume button

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 9 of 173
 Cisco dCloud

3. Observe connections details

• Action = Allow
dCloud: The Cisco Demo Cloud
• Reason = N/A
• SSL Flow Flags = N/A
• SSL Flow Messages = N/A
• Web Application = Facebook
• URL = https://facebook.com

NOTE: The firewall can trust a session based on the SNI information before the certificate is learned. Therefore,
learning the certificate ahead of time is important to ensure the SNI is verified before the firewall makes its decision.
In the next steps of this exercise, we will look at how Cisco Firepower Threat Defense using the TLS Server Identity
Discovery feature makes a decision against TLS 1.3 flows based on more reputable information, as SNI on its own
is not reliable and can be easily spoofed. While processing TLS 1.3 traffic flows, FTD with TLS Server Identity
Discovery feature provides CN as the higher precedence over the SNI information.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 10 of 173
 Cisco dCloud

Task 4. Enable TLS Server Identity Discovery feature in Firepower Management Center

1. In FMC, navigate to the Policies > Access Control page. dCloud: The Cisco Demo Cloud
2. Edit the TLS Policy Demo.

You can enable the TLS Server Identity Discovery feature in two different ways:

Hover your mouse in ACP over the Advanced tab.

Click on the Toggle button to “Enable early application detection and URL categorization for encrypted connections with
active TLS certificate probes.”
Save the ACP.

OR

Click on the Advanced tab in Access Control Policy

Select the pencil button next to “TLS Server Identity Discovery” to edit the configuration
Mark checkbox to enable “Early application detection and URL categorization”
Read the description of the feature

Click OK
Save the “TLS Policy Demo”

3. Perform the ACP: Deploy > Deployment > Select NGFW1 > Deploy > Deploy
4. Wait for policy deployment to be successful.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 11 of 173
 Cisco dCloud

Task 5. TLS Server Identity Discovery Enabled and with SNI Mismatch Detection
1. Navigate back to the opened PuTTY session to the Inside Linux machine and execute this command
dCloud: The Cisco Demo Cloud
openssl s_client -connect walmart.com:443 -tls1_3 -servername facebook.com

2. Navigate back to FMC and refresh the connection events page using the pause icon and resume
3. Connections with Application Details:
• Action = Block
• Reason = N/A
• SSL Flow Messages = CLIENT_HELLO
• SSL Flow Flags: SERVER_NAME_MISMATCH
• Web Application = Walmart
• URL = https://walmart.com

As we have seen, SNI can be spoofed or not present. Therefore the CN/SAN/OU plays an important role in
determining the domain that the client is trying to access. The TLS Server Identity Discovery provides a method to
verify the SNI with creditable information. This exercise has demonstrated that the TLS Server Identity Discovery
can detect SNI mismatch even without implementing SSL Policy inspection - this is very important as not all
deployments use SSL Policy. Also, having SNI mismatch detection without SSL policy inspection enabled improves
performance benefits (when this new feature is enabled, both SNI information and the CN are used for AppID and
URL identification).

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 12 of 173
 Cisco dCloud

Summary

dCloud: The Cisco Demo Cloud

The TLS Server Identity Discovery enhance security aspects of traffic handling through the firewall along with some
other benefits such as:

• It helps an AC Policy to reach a valid verdict based on more creditable and comprehensive information

• Removes ambiguity in SSL Policy decision making whether the TLS connection should be decrypted or not

• Provide verification of SNI against a list of domains available in the SAN certificate extension

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 13 of 173
 Cisco dCloud

Task 6. TLS Server Identity Discovery Probe - Certificate not found in local cache
TLS probe helps the TLS Server Identity Discovery feature to learn about server certificates from TLS 1.3
sessions. This exercise aims to demonstrate that the TLS Server Identity Discovery probe dCloud:can discover
The Cisco a
Demo Cloud
server certificate, cache it, and use it to assist with the TLS 1.3 connections. After an effective probe
event, the traffic should hit the correct URL rule.

1. Navigate to FMC, Policies > Access Control. Click on the pencil button next to “TLS Policy Demo”
2. Click “Add Rule.”
Enter the name “Allow Finance.”
Set Action to “Allow.”
Click on the URLs tab
• Under “Categories and URLs” search for Finance, select found “Finance” URL category > Click Any > “Add to
Rule.” Repeat the same for the “Online Trading” URL category.
Navigate to the Logging tab.
• Mark checkbox “Log at End of Connection”
Click Add.
3. Validate that the TLS Server Identity Discovery feature is enabled in the Advanced tab.
4. Click Save.
5. Perform Policy Deployment
• Deploy > Deployment > Select ‘NGFW1’ Device > Deploy and confirm Deploy.

6. Open a new PuTTY application session, search for NGFW1 under Saved Sessions, select NGFW1, click Load,
and then Open.
Authenticate to the device using admin/C1sco12345 credentials
Issue the following command to enable TLS probe logging - this should be enabled for debugging purposes only or if
further visibility into TLS flows in connection events is required.

> system support ssl-probe-logging-enabled true

To make sure that the certificate cache is clean, execute the following command:

> system support ssl-cache-clear all

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 14 of 173
 Cisco dCloud

A specific certificate in the NGFW1 cache can be found by using its domain name / SNI or IP address information; use
the following command:

> system support ssl-cache-certificate-search dCloud: The Cisco Demo Cloud

7. From jumpbox, navigate to Desktop, open “Remote Desktops” folder, double-click on Wkst1 Remote Desktop
shortcut.

8. On Wkst1, launch Firefox browser and open any Financial TLS 1.3 capable website such as
https://americanexpress.com or https://schwab.com (it might take a couple of seconds for the page to load)
In the URI, click on the locker button.
• Click on “>” to expand details about Certificates issued for the website.

• Then click on “More information” and validate that the website’s connection has been established using TLS 1.3
protocol version.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 15 of 173
 Cisco dCloud

9. Navigate to the FMC, Analysis > Connections > Events

Click on “Edit Search”
Under Networking add “198.19.10.21” as Initiator IP and click Search. (Note, IP address can be different if the user has
dCloud: The Cisco Demo Cloud
already run through the User Identity related exercises. Issue in CMD on Wkst1 ipconfig command to review the current
IP address of the machine, default is 198.19.10.21.)
Select “Table View of Connection Events” and observe details of the connection event to americanexpress.com and
schwab.com websites. You will also see other blocked URLs.

• SSL Flow Flags = CERTIFICATE_CACHE_MISS and CERTIFICATE_CACHE_HIT

• SSL Flag Messages = CLIENT_HELLO

SSL Flow Flags field displays CERTIFICATE_CACHE_MISS on the website’s first visit because the certificate
information is not present in the local device cache. On subsequent visits, it displays CERTIFICATE_CACHE_HIT,
since the system triggered a TLS probe that has obtained certificate details and stored it into the cache. The
system further uses a certificate found in the cache to make policy enforcement decisions.

10. Close and reopen the Firefox browser in the Wkst1 machine.
11. Open again the same websites: https://schwab.com and https://americanexpress.com
12. Navigate back to FMC connection events Analysis > Connections > Events
13. Click on “Edit Search”
Enter Initiator IP: 198.19.10.21”
Enter URL: *americanexpress.com,*schwab.com

Review connection event details. Note that this time SSL Flow Flags reports only CERTIFICATE_CACHE_HIT and
that there is no TLS Server Identity Discovery probe session event displayed. This is because the TLS probe was
not needed to be engaged as the TLS certificate for the sites were cached locally - because we have visited the
website recently – so the system learned about necessary certificates and leveraged them on subsequent
requests.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 16 of 173
 Cisco dCloud

14. Navigate back to PuTTY of NGFW1 and review the content of the TLS certificate cache. It should be populated
with certificate details of americanexpress.com and schwab.com websites:

dCloud: The Cisco Demo Cloud

> system support ssl-cache-certificate-search

Choose search option 1

Enter the domain name to search “americanexpress.com”

Note: this time certificate cache for visited websites is populated and ready to be reused for the next connection.

15. Change the ACP of NGFW1 back to the Base ACP before you move on to the next exercise.
Policies > Access Control
Edit “Base_Policy”
Click on “Policy Assignments”
Select NGFW1 and click “Add to Policy”
Click OK and confirm with Yes device policy reassignment
Save ACP
Deploy changes: Deploy > Deployment

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 17 of 173
 Cisco dCloud

Scenario 2 - FMC Device Health Monitoring

In this scenario, we review the newly redesigned FMC health monitoring features. Version 6.7 FTD
dCloud: The Cisco Demo Cloud

devices have a completely redesigned graphical interface for displaying health information. While the
existing Perl-based health modules are still used, these are augmented by new processes on the device
and FMC to provide more dynamic updates for information such as CPU, memory, and interface metrics.

1. The new monitoring capabilities include enhanced CPU utilization graphs. However, the default health policy
does not enable these checks. The first step is to modify the health policy in use and enable CPU health
monitoring.
In the jumpbox device, launch the Firefox browser. It automatically launches the connection to the FMC at
fmc.dcloud.local and press the “Log In” button to authenticate to the device (credentials are prefilled).

Navigate to System > Health > Policy. Note that the System menu has been replaced with the icon in the new user
interface.

2. Click the pencil icon next to the Initial_Health_Policy to edit the policy settings. From the list on the left, click on
CPU Usage (per core). Enable this setting leaving the thresholds at their default values. Then click Save Policy
and Exit.

3. Click the green policy apply icon to apply the policy to your appliances.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 18 of 173
 Cisco dCloud

4. Check the group named Ungrouped to select all appliances and click the Apply button.

dCloud: The Cisco Demo Cloud

NOTE: There may be a delay of several minutes before CPU usage data appears in the health graphs.

5. Navigate to System > Health > Monitor. Note that the FMC and managed devices are listed under Monitoring
on the left side of the screen

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 19 of 173
 Cisco dCloud

6. Select Home from the list on the left. Notice you have an overview screen showing the health status of each of
the managed devices and the FMC.

dCloud: The Cisco Demo Cloud

A hexagon represents each device, and they are color-coded based on the health status of the device. Hovering
over any of the colored hexagons brings up a summary of the health modules and top 5 alerts. Click on the
NGFW1 hexagon. This brings up a dialog with the result of the most recent health checks. Note that some of the
checks include see more links to load additional details. You can also see these checks by clicking the > icon to
the left of a device in the list.

7. Select the FMC in the list on the left. The typical Health Monitor page is displayed. This page displays the same
data as in previous versions.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 20 of 173
 Cisco dCloud

8. Select the NGFW1 device. There is now a new health dashboard with multiple tabs.

dCloud: The Cisco Demo Cloud

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 21 of 173
 Cisco dCloud

9. Click the View System & Troubleshoot Details link located just under the device name at the top of the page.

dCloud: The Cisco Demo Cloud

This expands the System Details and Troubleshooting & Links sections, which provide a good way to find details
such as the FTD version, model, VDB/SRU, and Snort version for a device. The Troubleshooting & Links section is
where you can Generate Troubleshooting Files, perform packet trace/capture with Advanced Troubleshooting or
edit the Health Policy and Alerts.

This new dashboard page has several elements.

First, note that this is a static page with a 1-hour time window. This time window can be adjusted using the drop-down
menu in the upper right corner. Auto Refresh can also be enabled by clicking the icon next to the drop-down.

The CPU and Memory trend graphs show their respective device utilization metrics over the selected time window.
Notice each of these has a Warning and Critical threshold (dotted line) corresponding to the default values in the Health
Policy for CPU and Memory. Also, the numbers near the top of each graph display the average, minimum and maximum
values for the period. You can also hover your mouse over the graph to see the values at a given point in time.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 22 of 173
 Cisco dCloud

Under the Overview tab, the Throughput graph shows all interfaces by default. However, a drop-down menu allows
selecting a specific interface if desired.

dCloud: The Cisco Demo Cloud

The additional dashboard tabs: CPU, Memory, Interfaces, Connections, and Snort provide additional detailed data on
each of these items.
These graphs can be overlayed with deployment data by clicking the button located just below the time window drop-
down. Clicking this button overlays each of the graphs with information on policy deployments. This way, performance
impacts due to policy changes can be easily visualized. Clicking on the icon at the top of a deployment dotted line will
display deployment details.

10. Take some time to familiarize yourself with the dashboard and the various trend graphs. Try to locate the most
recent policy deployment and see if there is any correlation in the various statistics.

NOTE: you may have to expand your time window depending on how recently you deployed policy changes.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 23 of 173
 Cisco dCloud

11. In addition to the built-in dashboards, you can also add customized dashboard views. These can be helpful
when drilling down into additional details for a given area. Metrics can be added based on a Correlation Group.
There are five built-in groups plus a custom group.
dCloud: The Cisco Demo Cloud
• CPU – Data Plane
• CPU – Snort
• CPU – Others
• Memory – Data Plan
• Packet Drops
• Custom

To add a custom dashboard, click the + icon just below the time window drop-down. This brings up the Correlate
Metrics dialog, where you can select one of the groups above.

12. Select CPU – Data Plane from the list. Note you can stop there and accept the metrics already in the group, or
you can further customize. Click the Show Details link to expand the metrics details.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 24 of 173
 Cisco dCloud

13. Here you can remove or modify the built-in metrics or add additional metrics using the Add Metrics button at
the bottom. When adding metrics, you are not limited to a single group but can add metrics from any group as
desired. Use the Add Metrics button to add the Average Input Packet Size metric from the Interface group.
Your metrics selection should look like the screenshot below. When finished, click the AdddCloud:
button to add the
The Cisco Demo Cloud

dashboard tab.

14. You now have a new dashboard tab named Correlation-CPU-Dataplane. Clicking the three dots to the right of
this name allows further customization of the trend metrics, as well as renaming the tab if desired.

Customized tabs can be used to drill into metrics and trends related to specific performance concerns.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 25 of 173
 Cisco dCloud

Scenario 3 - SNMP Device Health Monitoring (Optional)

In this scenario, we will review the new unified SNMP monitoring capabilities in Firepower 6.7. This
dCloud: The Cisco Demo Cloud

feature extends SNMP monitoring to areas such as Snort CPU and memory as well as monitoring critical
processes, failover, and cluster status.

1. Login to the FMC at fmc.dcloud.local, you can use the FMC shortcut in the jumpbox browser. Navigate to
Devices > Platform Settings. Edit the NGFW1_Platform_Settings policy.

2. From the list on the left, select SNMP. Enter the information as follows:
Enable SNMP Servers: checked
Read Community String: cisco123
Confirm*: cisco123
System Administrator Name: Snorty
Location: Fulton, MD

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 26 of 173
 Cisco dCloud

3. Click the + Add button on the right to add an SNMP host. Enter the information below:
IP Address: 198.19.10.81
SNMP Version: 2c
dCloud: The Cisco Demo Cloud
Community String: cisco123
Confirm: cisco123
Reachable By: Device Management Interface

4. Click OK to save the new host.

5. Click on SNMP Traps

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 27 of 173
 Cisco dCloud

6. On the SNMP Traps screen, all of the trap settings below Nat Packet Discard are new in this version. Check
the CPU Rising Threshold and Memory Rising Threshold boxes. Change the Percentage under the Memory
Rising Threshold to 50.
dCloud: The Cisco Demo Cloud

7. When finished, click the Save button in the upper right to save the policy.
8. Navigate to Deploy > Deployment, check the NGFW1 device, and click the Deploy button to push the platform
settings changes. When prompted, confirm by clicking Deploy.
9. While the deployment job is running, we will start a PuTTY session to the NGFW1 device. From the jumphost,
click the PuTTY icon in the windows taskbar.

10. From the PuTTY Configuration window, scroll to the NGFW1 saved session. Select it, then click the Open
button to start the session.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 28 of 173
 Cisco dCloud

11. Login as admin with the password C1sco12345. At the > prompt, type expert to load the bash shell. You
should now have a $ prompt.

dCloud: The Cisco Demo Cloud

12. Next, we use snmpwalk to query the device using one of the new SNMP OIDs. This will demonstrate polling for
critical processes. Enter the following command in the PuTTY window and press Enter.

snmpwalk -v2c -c cisco123 198.19.10.81 1.3.6.1.4.1.9.9.109.1.2.1.

The parameters in this command are:

• -v2c – SNMP version 2
• -c cisco123 – the community string
• 198.19.10.81 – the management interface of the NGFW1 device
• 1.3.6.1.4.1.9.9.109.1.2.1.1 – the SNMP Object Identifier for the Cisco device process information

This polls the NGFW1 device for process information, similar to the screenshot below.

Notice the critical processes returned by the query:

• snort01
• java
• sftunnel
• sf_data_correlator

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 29 of 173
 Cisco dCloud

NOTE: The number and names of critical processes may change depending on the device hardware and policy
configuration.
dCloud: The Cisco Demo Cloud
Notice the numbers to the left of each process. These are the Linux process IDs.

You can check these with the ps command. For example, to verify the snort01 process, you can use the command:

ps -ef | grep 3144

This shows the Snort process is running under this process ID.

Try the command above using the process IDs from your PuTTY output.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 30 of 173
 Cisco dCloud

13. Next, we will use SNMP to poll memory information. Start a second PuTTY session to NGFW1. An easy way to
do this is to click in the upper left corner of the existing session then select Duplicate Session.

dCloud: The Cisco Demo Cloud

14. Login to this new session as admin. After logging in, execute the following command to load the system
diagnostic CLI:

system support diagnostic-cli

From the ngfw1> prompt, type en and then tap Enter twice to arrive at the ngfw1# prompt

You should now have one PuTTY window open to the bash prompt and one open to the Firepower CLI prompt.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 31 of 173
 Cisco dCloud

15. Now we will compare the data returned by the Firepower CLI and polling with SNMP.
From the Firepower CLI, execute the command: show snort statistics
From the bash prompt execute: snmpwalk -v2c -c cisco123 198.19.10.81 1.3.6.1.4.1.9.9.491.1.5.3.1
dCloud: The Cisco Demo Cloud
You should see output similar to below. If your counters do not match exactly, try running the commands again as close
together as possible. Snort statistics are constantly updating and will be different if they are not gathered at the same
time.

Notice the correlation between the packet counters gathered from both windows.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 32 of 173
 Cisco dCloud

16. Next, let’s look at one of the new SNMP traps available in this version. In this step, we will use tcpdump to view
the SNMP trap output. On a production network, this output would be directed to an SNMP network manager.
The commands below should be run in the PuTTY bash prompt window.
dCloud: The Cisco Demo Cloud

sudo su

(enter admin password: C1sco12345)

tcpdump -i lo udp and port 162

The tcpdump parameters are:

• -i lo – use the local loopback interface
• udp and port 162 – Berkeley Packet Filter (BPF) expression to select just udp traffic on port 162

This will begin the tcpdump session.

17. While you are waiting for the SNMP trap to occur, use the Firepower CLI PuTTY session to enter the show
memory all command. Check to see if the memory used by the various components exceeds the trap
threshold. Recall that we set this to 50% when we enabled this in the Platform Settings.

18. Back in the bash PuTTY window, your trap should appear within 60 seconds. Notice the messages indicating
the DP System memory exceeded the threshold. This SNMP trap should repeat every 60 seconds while the
memory threshold is exceeded.

19. When you are finished, exit and close the PuTTY sessions.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 33 of 173
 Cisco dCloud

Scenario 4 - FMC Copying and Moving Rules

dCloud: The Cisco Demo Cloud

Objectives:

1. Copy rules between access control policies

2. Move rules between access control policies and prefilter policies

Enhancements to copying and moving rules

The following table shows the rule copy and move enhancements introduced in the 6.7 release.

Available in 6.6 Added to 6.7

Access Control
Policies Copy to same policy Copy to another access control policy
Rule Copy
Access Control
Move to an associated (non-default)
Policies Not available
prefilter policy
Rule Move
Prefilter Policies
Copy to same policy No new functionality
Rule Copy
Prefilter Policies Move to an associated access control
Not available
Rule Move policy

When moving rules between access control policies and prefilter policies, the rule action is adjusted, as shown in
the following tables.

Original ACP rule Adjusted Prefilter Original Prefilter rule Adjusted ACP rule
action rule action action action
Allow Analyze Analyze Allow
Any block action Block Block Block
Trust Fastpath Fastpath Trust
Monitor [Cannot move]

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 34 of 173
 Cisco dCloud

Task 1: Perform prerequisite for this lab

To demonstrate the new features, it is better to have two access control policies share a prefilter policy and not use
the other prefilter policy. You will complete the following relationships:
dCloud: The Cisco Demo Cloud

Access Control Policy Prefilter Policy

Base Demo Prefilter Policy
Branch Access Control Policy Default Prefilter Policy
Minimal Access Control Policy Demo Prefilter Policy
TG Access Control Policy Default Prefilter Policy
[None] Dummy Prefilter Policy

3. From the Jumpbox, open Firefox and login to the FMC, navigate to Policies > Access Control.
4. Edit the Minimal Access Control Policy.
Click on the Default Prefilter Policy link.

Change the prefilter policy to the Demo Prefilter Policy. Click OK.

Click Save to confirm the policy change.

5. Navigate to Policies > Prefilter. Click New Policy
For Name, enter Dummy Prefilter Policy.
Click Save.

6. Once the new prefilter policy opens up for editing, click Cancel to exit. But notice that the new prefilter policy
has successfully been created.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 35 of 173
 Cisco dCloud

Task 2: Copy rules between access control policies

You will now copy two rules from the base access control policy to the minimal access control policy.
dCloud: The Cisco Demo Cloud

1. In the FMC, navigate to Policies > Access Control.

2. Edit the Base_Policy access control policy.
3. Hold down the Ctrl key. Click on the rule called Block SSH for HR and Block Extranet129. These should be the
second and third rules. Then right-click.
Select Copy to > Another policy.

For Access Policy, select Minimal Access Control Policy.

For Place Rules, select At the top (within the Mandatory section).
Click Copy

4. Near the top of the page, click on the link to pivot to the Minimal Access Control Policy.

Observe that the two rules have been copied.

Observe that the changes to the policy have already been saved.
Click Cancel to exit the Minimal Access Control Policy page.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 36 of 173
 Cisco dCloud

Task 3: Move rules from an access control policy to the associated prefilter policy

1. Edit the Branch Access Control Policy. dCloud: The Cisco Demo Cloud
2. Right-click on the rule called Allow Outbound. This should be the only rule in the policy. Select Move to another
policy. You will see the following error. Click OK.

NOTE: In case the OK button is not visible, refresh the page and repeat the step.

3. Click Cancel to exit the Branch Access Control Policy.

4. Edit the Base_Policy
5. Right-click on the rule called Block SSH for HR. This should be the second rule. Note that the rule has layer 7
matching criteria.
Select Move to another policy. Rule placement is not relevant. Note that you can only move the rule to the associated
prefilter policy. Click Move.

A warning will appear that states the rule has layer 7 matching criteria that the system would remove, and therefore the
rule would match all traffic. Click No.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 37 of 173
 Cisco dCloud

6. Right-click on the rule called Block Extranet129. This should be the third rule. Note that the rule has no layer 7
matching criteria.
Select Move to another policy. Leave rule placement set to At the top.
dCloud: The Cisco Demo Cloud
Click Move. This time no warning will appear.

Note that the changes to the access control policy have already been saved.

7. You will see the following message at the top of the screen.

Click on the Demo Prefilter Policy link to pivot to the prefilter policy.
Confirm that the Block Extranet129 rule is now a prefilter policy rule.

NOTE: Because you placed the rule on top, it will preempt the fastpath rule. Before moving the rule, the fastpath
rule preempted this rule (because prefilter rules preempt access control rules).

In practice, if you see such rule conflicts, there is most likely a configuration error.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 38 of 173
 Cisco dCloud

Task 4: Move rules from a prefilter policy to an associated access control policy

1. In the Demo Prefilter Policy, right-click on the rule called Block Extranet129. This should be the first rule.
dCloud: The Cisco Demo Cloud
Select Move to another policy.
For Access Policy, select Minimal Access Control Policy.

NOTE: You have a choice of two access control policies because the Demo Prefilter Policy is referenced in two
access control policies. If you want to move the rule to both policies, you should first copy the rule.

For Place Rules, select At the top (within the Mandatory section).
Click Move.

2. You will see the following message at the top of the screen.

Click on the Minimal Access Control Policy link to pivot to the access control policy.
Note the Block Extranet129 rule was moved and renamed Block Extranet129 (1) because a rule with that name already
exists in that policy.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 39 of 173
 Cisco dCloud

Scenario 5 - Route Based VTI Site-to-Site VPN

Firepower 6.7 added virtual tunnel interface (VTI) support to FTD. This allows the creation of a route-
dCloud: The Cisco Demo Cloud

based site-to-site VPN connection (this functionality already existed in the ASA).

NOTE: Unlike in routers, the VTI can only be used for site-to-site VPN. Other tunnel types are not supported.

Both the FMC and FDM support this feature. If you wish, you can create the tunnel using the FDM on NGFW2.
However, this exercise uses the FMC

Objectives

1. Configure, administer, and monitor a route-based site-to-site VPN connection between 2 FTDs.
2. Configure and test BGP between tunnel endpoints.

Policy based VPN versus route-based VPN

Both policy-based and route-based site-to-site VPN is now available with FTD.
Route-based VPNs are recommended over policy-based VPN because they are more flexible. However,
you may need policy-based VPNs for some third-party devices. Also, it may be easier to create multi-
point VPNs when using policy-based VPNs.

Policy based site-to-site VPN Route based site-to-site VPN

Specify traffic that Specify by route next hop (must be
Specify traffic in crypto map
will use VPN remote VTI IP address)
Specify in the tunnel interface
Specify in crypto map. Dynamic peering is
Specify peer configuration. Peer cannot be
achievable with dynamic crypto maps.
dynamic.
Point to point Point to point only. More complex
Supported
Hub and spoke topologies require multiple VTIs, which
topologies
Full mesh must be on different subnets.
Learn routes from BGP peering of VTIs on local and
Reverse route injection
remote endpoint remote endpoint.
Supported IKEv2
Tunnel mode or transport mode Tunnel mode only
modes

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 40 of 173
 Cisco dCloud

Task 1: Create a security zone for the VTI interfaces

The VTIs could be placed in an existing security zone. But for maximum flexibility in the access control
policy, it is best to create a separate security zone for them. dCloud: The Cisco Demo Cloud

1. In the FMC, navigate to Objects > Object Management.

2. Select Interface from the left navigation pane.
3. Click Add > Security Zones.
For Name, enter VTIZone.
Select Routed from the Interface Type drop-down.
Click Save.

Task 2: Modify the access policies on NGFW1 and NGFWBR1

For simplicity, you will allow all traffic between the corporate VLANs and branch VLANs.

1. In the FMC, navigate to Policies > Access Control.

2. Edit the Base_Policy access control policy.
Edit the rule called Allow East-West. It should be the rule 10
Under Zones, add VTIZone to both the source and destination.
Click Save to save the rule. Click Save to save the policy changes.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 41 of 173
 Cisco dCloud

3. In the FMC, navigate to Policies > Access Control.

4. Edit the Branch Access Control Policy.
Click Add Rule. dCloud: The Cisco Demo Cloud
Name the rule Allow East-West. Rule placement does not matter.
Under Zones, add InZone and VTIZone to both the source and destination.
Click Add to save the rule. Click Save to save the policy changes.

Task 3: Observe differences between policy-based and route-based VPN configuration

1. In the FMC, navigate to Devices > Site To Site. Click on the text, “Firepower Threat Defense Device.”
2. Note how the radio button, where you choose policy Based (Crypto Map) or Route Based (VTI), interacts with
the Network Topology choices. Confirm that only the point-to-point topology can be used with a VTI.
3. For Network Topology, chose Point to Point.
4. Navigate through the four sub-tabs: Endpoints, IKE, IPSec, and Advanced. For each sub-tab, toggle between
policy Based (Crypto Map) and Route Based (VTI). Note the following.
The Endpoints sub-tab varies significantly. In particular, you do not define protected networks with VTI. That is replaced
by routing.
The IKE sub-tab is identical.
There are three differences in the IPSec tab.
• The ability to configure a dynamic crypto map for policy-based VPNs.
• The choice of IKEv2 mode for policy-based VPNs.
• The choice to enable or disable reverse route injection for policy-based VPNs.
The Advanced sub-tab is identical.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 42 of 173
 Cisco dCloud

Task 4: Run the site-to-site VPN wizard

For expediency, you will use as many defaults as possible.
dCloud: The Cisco Demo Cloud
1. The site-to-site VPN wizard is already open.
For Topology Name, enter VTIDemo.
Select the Route Based (VTI) radio button.
For Network Topology, select Point to Point.
2. Select the Endpoints tab.
3. For Node A, enter the following.
For Device, select NGFW1.
Click the + to the right of the Virtual Tunnel Interface drop-down.
• For Name, enter vti1.
• For Security Zone, select VTIZone.
• For Tunnel ID, enter 1.
• For IP Address, enter 10.0.1.1/30.
• For Tunnel Source, select GigabitEthernet0/0 (outside).
• Click OK twice.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 43 of 173
 Cisco dCloud

4. For Node B, enter the following.

For Device, select NGFWBR1.
Click the + to the right of the Virtual Tunnel Interface drop-down.
dCloud: The Cisco Demo Cloud
• For Name, enter vti1.
• For Security Zone, select VTIZone.
• For Tunnel ID, enter 1.
• For IP Address, enter 10.0.1.2/30.
• This is the only value that is different from the Node A interface.
• For Tunnel Source, select GigabitEthernet0/0 (outside).
• Click OK twice.

5. Confirm that the screenshot matches the following.

6. Click Save. Then deploy the changes to NGFW1 and NGFWBR1: Deploy > Select NGFWBR1 and NGFW1
devices > Deploy > Deploy - Wait for the deployment to complete.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 44 of 173
 Cisco dCloud

Task 5: Configure BGP

1. In the FMC, navigate to Devices > Device Management. dCloud: The Cisco Demo Cloud
2. Edit NGFW1. Select the Routing sub-tab.
3. In the left navigation pane, near the bottom, under General Settings, select BGP.
Check the Enable BGP check box.
For AS Number, enter 65000.

4. In the left navigation pane, under BGP, select IPv4.

Check the Enable IPv4 check box.
Select the Neighbor sub-tab. Click +Add to add a neighbor.
• Check the Enabled address check box.
• For IP Address, enter 10.0.1.2.
• For Remote AS, enter 65001.
• Leave all other settings unchanged.
• Click OK.

Select the Redistribution sub-tab. Click +Add to add a redistribution.

• Confirm that the Source Protocol is set to Connected.
• For Metric, enter 0. This value is not relevant, but it must not be empty.
• Leave all other settings unchanged.
• Click OK.

Click Save to confirm the changes to NGFW1.

5. In the FMC, navigate to Devices > Device Management.

6. Edit NGFWBR1. Select the Routing sub-tab.
7. In the left navigation pane, near the bottom, under General Settings, select BGP.
Check the Enable BGP check box.
For AS Number, enter 65001.

8. In the left navigation pane, under BGP, select IPv4.

Check the Enable IPv4 check box.
Select the Neighbor sub-tab. Click +Add to add a neighbor.
• Check the Enabled address check box.
• For IP Address, enter 10.0.1.1.
• For Remote AS, enter 65000.
• Leave all other settings unchanged.
• Click OK.

Select the Redistribution sub-tab. Click +Add to add a redistribution.

• Confirm that the Source Protocol is set to Connected.
• For Metric, enter 0. This value is not relevant, but it must not be empty.
• Leave all other settings unchanged.
• Click OK.

Click Save to confirm the changes to NGFWBR1.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 45 of 173
 Cisco dCloud

Task 6: Test the site-to-site VPN connection

1. Deploy the changes to NGFW1 and NGFWBR: Deploy > Deployment > Select NGFWBR1 and NGFW1 devices
dCloud: The Cisco Demo Cloud
> Deploy > Deploy - Wait for the deployment to complete.

2. Wait an additional 30 seconds for the tunnel and BGP adjacency to come up.
3. Open PuTTY on the jumpbox desktop. Double click on the PuTTY session called NGFWBR1
Log in as admin, password C1sco12345.
Type show crypto ipsec sa. If you see There are no ipsec sas, you must troubleshoot your VPN configuration.
Type show run router. The output should look like the following.

> show running-config router

router bgp 65001

bgp log-neighbor-changes

bgp router-id vrf auto-assign

address-family ipv4 unicast

neighbor 10.0.1.1 remote-as 65000

neighbor 10.0.1.1 transport path-mtu-discovery disable

neighbor 10.0.1.1 activate

redistribute connected metric 0

no auto-summary

no synchronization

exit-address-family

>

Type show bgp summary. In the State/Pfxcd column, confirm that NGFWBR1 has learned 6 prefixes from NGFW1.
• If the State/Pfxcd column says Idle or Active, you must troubleshoot your BGP connection.
• If the State/Pfxcd column says 0, you must troubleshoot your BGP redistribution configuration.

Type show route bgp. You should see four BGP routes

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 46 of 173
 Cisco dCloud

4. (optional) If NGFWBR1 looks correct, NGFW1 is most likely also correct. However, if the connection you will
test in the above step fails, you may wish to look at NGFW1. Open PuTTY on the jump box desktop. Double
click on the predefined PuTTY session called NGFW1.
dCloud: The Cisco Demo Cloud
Log in as admin, password C1sco12345.
Type show run router. The output should look like the following.

> show running-config router

router bgp 65000
bgp log-neighbor-changes
bgp router-id vrf auto-assign
address-family ipv4 unicast
neighbor 10.0.1.2 remote-as 65001
neighbor 10.0.1.2 transport path-mtu-discovery disable
neighbor 10.0.1.2 activate
redistribute connected metric 0
no auto-summary
no synchronization
exit-address-family
!
>

Type show bgp summary. In the State/Pfxcd column, confirm that NGFW1 has learned 3 prefixes from NGFW1.
• If the State/Pfxcd column says Idle or Active, you must troubleshoot your BGP connection.
• If the State/Pfxcd column says 0, you must troubleshoot your BGP redistribution configuration.

Type show route bgp. You should see one BGP route.
In NGFW1 CLI (PuTTY) execute commands and observe outputs
• show interface ip brief - shows the GigabitEthernet0/1 interface in administratively down state and without IP
address configured
• show run nat - produces empty results

In NGFW1 CLI (PuTTY) execute commands and observe outputs

• show route bgp - does not show any routes
• show bgp summary - reports under State/PfxRcd only 2 prefixes instead of 3

5. If you performed the FMC Remote Deployment exercise prior VTI task, continue with the steps mentioned
below. Otherwise, move to step number 7.

Necessary corrective actions that need to be performed in FMC UI in Firefox browser from Jumpbox:

Navigate to Device > Device Management > Edit NGFWBR1

Move under the Interfaces tab
Edit GigabitEthernet 0/1 interface
• Add “inside” as a name
• Click checkbox for Enabled
• Add “InZone” as Security Zone
• Move under IPv4 tab
• Configure IP address “198.19.11.1/24”
• Click OK

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 47 of 173
 Cisco dCloud

Edit GigabitEthernet 0/0

• Add “OutZone” as Security Zone
• Click OK and Confirm Yes
• Save Device Settings dCloud: The Cisco Demo Cloud

Navigate to Devices > NAT > Edit “Branch NAT Policy”

• Select Policy Assignments
• add NGFWBR1 to targeted devices
• Click OK
• Save

6. Deploy configuration changes to devices

• Deploy > Deployment > Select NGFW1 and NGFWBR1 devices > Deploy
• Wait for policy deployment to be successful and proceed further.

7. Open PuTTY on the jump box desktop. Double click on the predefined PuTTY session called Inside Linux
Server.
Log in as root, password C1sco12345.

8. Type ping branch. The ping should succeed.

9. Open PuTTY on the jump box desktop. Double click on the predefined PuTTY session called Branch Linux
Server.
Log in as root, password C1sco12345.

10. Type ping inside. The ping should succeed

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 48 of 173
 Cisco dCloud

Scenario 6 - Remote Deployments

dCloud: The Cisco Demo Cloud

Objectives

1. Change the management interface to the outside data interface on NGFWBR1

2. Bootstrap NGFWBR1 and register using the outside data interface.

NOTE: If you wish to perform the VTI exercise, you should do it before this exercise. Otherwise, you will have to
perform additional configuration before you can perform the VTI exercise.

SSH access to the FTD

The configuration performed in this exercise only impacts how the FMC and FTD communicate. It does not change
SSH access to the FTD. If you wish to access FTD through a data interface using SSH, you must change the
platform settings on the FTD.

Task 1: Change the management interface to the outside data interface on NGFWBR1
This task can be performed entirely on the FMC. But in this task, you will also run show commands on the FTD to
learn more about this feature.

1. Open PuTTY on the jumpbox desktop. Double click on the predefined PuTTY session called NGFWBR1.
Log in as admin, password C1sco12345.

2. Type show network. Note that the output of this command has no reference to any data interface.
3. Type show running-config sftunnel. Confirm that the output is empty. This shows that the default sftunnel
configuration is being used. Sftunnel is the software component on the FTD responsible for communication with
the FMC.

> show running-config sftunnel

>

4. Type show nat. Confirm that there is only one NAT rule.

> show nat

Manual NAT Policies (Section 3)

1 (inside) to (outside) source dynamic any interface

translate_hits = 90882, untranslate_hits = 0

>

(Your hit count may vary)

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 49 of 173
 Cisco dCloud

5. Open the Firefox browser on the jumpbox device. It opens connection automatically to the FMC and login to the
device (credentials are prefilled). In the FMC, navigate to Devices > Device Management. Edit NGFWBR1.

dCloud: The Cisco Demo Cloud

Select the Device sub-tab. In the management section, click on the Management Interface link.

6. Select Data Interface from the Manage device by drop-down.

7. Click Save and then click OK. Click Close.

8. Select the Interfaces sub-tab. Edit GigabitEthernet0/0.

NOTE: In the upper right corner, you will see the following banner.

You can optionally click on View details…. The tabs on the resulting page will show the changes to be deployed
and the current management status of the device.

On the details page(under Connection Status sub-tab), you can see the output of the CLI command sftunnel-
status-brief. This command, along with the more verbose command sftunnel-status, can be useful when
troubleshooting sftunnel.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 50 of 173
 Cisco dCloud

9. Select the FMC Access tab of the Edit Physical Interface page.
10. Check the Enable management on this interface for the Firepower Management Center check box.
11. Click the + to the left of Available Networks. Create a host network object named FMC anddCloud:
IP address
The Cisco Demo Cloud
198.19.10.120.
12. Click the + to the left of Available Networks. Create a host network object named FMC2 and IP address
198.19.10.121. You will need FMC2 added for the FMC HA lab (in the OPTIONAL lab workbook) to work.

NOTE: Note that the FMC IP is NATed when it goes through NGFW1. But as with ACP rules, we use the un-NATed
“real IP” of the FMC.

13. Add FMC and FMC2 to Allowed Management Networks. Click OK and then click, Yes.

14. Click Save to save the changes made to NGFWBR1.

15. Deploy the changes to NGFWBR1: Deploy > Deployment > Select NGFWBR1 device > Deploy > Deploy. Read
the warning, but then ignore it and confirm again Deploy.

16. Navigate to Notifications (next to gear icon) > Deployments and validate that policy deployment has been
successful before continuing with the next steps.

NOTE: If you performed the VTI lab exercise, NGFW1 will look like it also has changes to deploy. Whenever the
outside interface on NGFWBR1 is modified, the VPN configuration on both devices is marked as needing
redeployment. Redeployment to NGFW1 is optional in the case of this exercise.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 51 of 173
 Cisco dCloud

17. Return to the PuTTY session to NGFWBR1.

Type show network. The output of this command includes the following line: dCloud: The Cisco Demo Cloud

===============[ GigabitEthernet0/0 ]===============

• This shows that the device is now manageable through this data interface.

18. Type show running-config sftunnel. Confirm that the output is empty. This shows that the outside interface is
being used for management.

> show running-config sftunnel

sftunnel interface outside 198.19.10.120 255.255.255.255

sftunnel port 8305

>

NOTE: when FMC is in HA, there will be an extra line above the CLI output, so that managed device understands
how to communicate over the data-interface to both FMC1 and FMC2 management devices:

sftunnel interface outside 198.19.10.121 255.255.255.255

19. Type show nat. Confirm that there are three additional NAT rules.

> show nat

Auto NAT Policies (Section 2)

1 (nlp_int_tap) to (outside) source static nlp_server_0_sftunnel_intf2 interface service tcp 8305 8305

translate_hits = 0, untranslate_hits = 0

2 (nlp_int_tap) to (outside) source dynamic nlp_client_0_intf2 interface

translate_hits = 0, untranslate_hits = 0

3 (nlp_int_tap) to (outside) source dynamic nlp_client_0_ipv6_intf2 interface ipv6

translate_hits = 0, untranslate_hits = 0

Manual NAT Policies (Section 3)

1 (inside) to (outside) source dynamic any interface

translate_hits = 91740, untranslate_hits = 0}

>

(Your hit count may vary)

NOTE: A detailed explanation of these implicit NAT rules is beyond the scope of this guide. But the existence
indicates that management traffic hitting the data interface is redirected to an internal interface.

These implicit NAT rules do not appear in the running configuration.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 52 of 173
 Cisco dCloud

Task 2: Restore NGFWBR1 to an unconfigured state

Before you can bootstrap NGFWBR1 to use a data interface in the next task, you needdCloud:
to return
The Cisco Demo Cloud
NGFWBR1 to a state that resembles a fresh system.

1. If you performed the VTI lab, you must first delete the VPN configuration. In the FMC, navigate to Devices > Site
To Site - Delete the VPN object. Click Yes when asked to confirm the deletion. Then click, OK.

2. Navigate to Devices > Device Management.

Warning: Before proceeding with the next step, please ensure that you select the correct device that will be
unregistered from the FMC.

3. Click on the three vertical dots on the right of NGFWBR1 and select Delete. Click Yes to confirm the deletion.
Wait for the deletion to complete.

4. Return to the PuTTY session to NGFWBR1.

Type show interface ip brief. Confirm that NGFWBR1 has retained data interface configuration.

NOTE: Even the tunnel interface on NGFWBR1 is up - because you did not commit the deletion of the VPN
configuration. NGFWBR1 is still functioning at this point.

5. You will now use a trick to unconfigure NGFWBR1: type the command configure firewall transparent, followed
by configure firewall routed. You will have to confirm these changes.

> configure firewall transparent

This will destroy the current interface configurations, are you sure that you want to proceed? [y/N] y

The firewall mode was changed successfully.

> configure firewall routed

This will destroy the current interface configurations, are you sure that you want to proceed? [y/N] y

The firewall mode was changed successfully.

>

6. Type show interface ip brief. Confirm NGFWBR1 data interface configuration has been cleared.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 53 of 173
 Cisco dCloud

Task 3: Bootstrap NGFWBR1 to use a data interface for management

1. On the NGFWBR1 CLI type, configure network management-data-interface. Enter the settings shown below.
dCloud: The Cisco Demo Cloud

> configure network management-data-interface

Note: The Management default route will change to route through the data interfaces. If connected to the
Management interface with SSH, your connection may drop. You must reconnect using the console port.

Data interface to use for management: GigabitEthernet0/0

Specify a name for the interface [outside]: <hit enter>

IP address (manual / dhcp) [dhcp]: manual

IPv4/IPv6 address: 198.18.128.81

Netmask/IPv6 Prefix: 255.255.192.0

Default Gateway: 198.18.128.1

Comma-separated list of DNS servers [198.19.10.100]: 208.67.222.222,208.67.220.220

DDNS server update URL [none]:

Configuration done with option to allow FMC access from any network, if you wish to change the FMC access
network use the ‘client’ option in the command ‘configure network management-data-interface’.

Setting IPv4 network configuration.

Network settings changed.

>

2. Run the CLI commands you ran in Task 1 to confirm the management configuration:
show network – confirm that GigabitEthernet0/0 is referenced.

3. show running-config sftunnel – confirm that sftunnel is using the outside data interface.
4. show nat – confirm the presence of implicit NAT rules not shown in the running configuration.

5. On the NGFWBR1 CLI type, configure manager add 198.19.10.120 C1sco12345. Wait for the command to
complete.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 54 of 173
 Cisco dCloud

Task 4: Register the NGFWBR1 with the FMC

1. In the FMC, navigate to Devices > Device Management. Click Add > Device. dCloud: The Cisco Demo Cloud
For Host, enter 198.18.128.81.
2. For Display Name, enter NGFWBR1.
3. For Registration Key, enter C1sco12345.
4. Leave Group set to None.
5. For Access Control Policy, select Branch Access Control Policy.
6. Enable all three licenses.

7. Click Register. Wait for the registration and device discovery to complete.
8. Edit the device NGFWBR1.
Select the Device sub-tab. In the management section, confirm that the device is being managed through a data
interface. You may view the configuration if you wish.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 55 of 173
 Cisco dCloud

9. Select the Interfaces sub-tab. Edit GigabitEthernet0/0.

• Select the FMC Access tab of the Edit Physical Interface page. dCloud: The Cisco Demo Cloud
• Confirm that Enable management on this interface for the Firepower Management Center is selected.
• Note that Allowed Management Networks is set to any. In a production environment, you might want to limit this.
But for this lab exercise, you may leave it unchanged.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 56 of 173
 Cisco dCloud

Scenario 7 - FMC User Multi-Domain

The Firepower software Version 6.7 release provides the ability to identify users and groups passively
dCloud: The Cisco Demo Cloud

from the multiple Active Directory / LDAP domains coming from a single network. This feature solves
business challenges typically for large enterprise environments where users from different domains come
from the same or overlapping network segment. For example, when employees move between
departments and branch offices in different regions.

Each Active Directory / LDAP Domain is represented by Realm. To lookup identities from multiple
domains, Version 6.7 introduces a new element on the web interfaces of FMC and FDM called Realm
Sequence. Realm Sequence allows one to add multiple Realms into one object and then reference that
in an identity rule.

The minimum supported version of ISE is Version 2.4 patch 12 and Version 2.6 patch 6. The dCloud lab
uses the ISE Version 2.7 patch 2. This feature is available in both management platforms — FMC and
FDM.

Objectives:

1. Configure multi-domain (Realm Sequence) User Identity solution

2. Change Realm orders in Realm Sequence object
3. Validate the multi-domain functionality with 2 users coming from overlapping subnet

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 57 of 173
 Cisco dCloud

Task 1. Configure Multi-domain (Realm Sequence) User Identity Solution

1. Login to Firepower Management Center (FMC) from the Jumpbox using the Firefox browser (connection opens
automatically).
dCloud: The Cisco Demo Cloud
2. Navigate to System (Gear Icon) > Integration > click the Realms tab in the new window.
3. Observe the two preconfigured realms representing two different domains:

dcloud.local (Active Directory 1) in “dCloudRealm” realm

dev.dcloud.local (Active Directory 2) in “DEVdCloudRealm” realm

4. Download the users/groups from both realms

Click the Download Now icon to the left of the Pencil icon for dCloudRealm.
5. Press Yes to confirm the download of users/groups in this realm.
6. Click OK, then repeat for DEVdCloudRealm.
7. To view the downloads progress, go to Notifications > Tasks.

8. Navigate to System (Gear Icon) > Integration > Realm Sequences

NOTE: This is a new element on the web interface designed to configure the Multi-Domain User Identity feature.
Click on Add Sequence.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 58 of 173
 Cisco dCloud

9. Enter Name “multi-domain demo”

10. Hit “+” button, select all available Realm Objects(dCloudRealm and DEVdCloudRealm), click OK > Save
dCloud: The Cisco Demo Cloud

NOTE: A Passive Identity Source is already pre-configured on the FMC and managed FTD devices to receive the
user to IP mappings - so we only need to validate that the connection between FMC and ISE, our passive identity
provider, is working.

11. Navigate to System (Gear Icon) > Integration > Identity Sources
Ensure that the Session Directory Topic is enabled, as this option allows the system to receive User-to-IP mappings
from ISE.
12. Click Test to check the connection to ISE - which should show a success status
13. Click OK

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 59 of 173
 Cisco dCloud

14. Next, edit the existing identity rule into the Identity Policy.

dCloud: The Cisco Demo Cloud

Policies > Identity > Edit (Pencil Icon) NGFWIdentityPolicy

15. Edit Identity Rule named “PassiveAuthRule”

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 60 of 173
 Cisco dCloud

16. Under the “Realm & Settings” tab, use the Realm dropdown list to choose “multi-domain demo (Sequence)”
and click Save.

dCloud: The Cisco Demo Cloud

17. Save the Identity Policy by clicking Save in the top right
18. Next, attach the Identity Policy to the Access Control Policy
Policies > Access Control > Base_Policy edit (Pencil Icon).

19. Confirm that the Identity Policy “NGFWIdentityPolicy” is attached to Access Control Policy

Once confirmed, we will add the access rules to block access to social media websites for specific employees from
the Active Directory domains dev.dcloud.local and dcloud.local.
Users that should be blocked from dev.dcloud.local are:
• Eric
• John

Users from dcloud.local are:

• Alicia
• Dilbert

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 61 of 173
 Cisco dCloud

20. Click the + Add Rule button in the top right.

dCloud: The Cisco Demo Cloud

21. Enter Name as “multi-domain demo” and Action as Block with Reset

22. Navigate to the Users tab and

Click the Users tab in the rule
23. Under Available Realms, select the DEVdCloudRealm
24. Search for eric in Available Users and click Add to Rule - Repeat for user john
25. Under Available Realms, select the dCloudRealm
26. Search for alicia in available users and click Add to Rule - Repeat for user dilbert
27. You should now have four users added to the rule, as shown below

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 62 of 173
 Cisco dCloud

28. Then, enable logging by clicking the Logging tab and select Log at Beginning of Connection

dCloud: The Cisco Demo Cloud

29. Next, ensure the rule is at the top of the firewall rule set – Insert > Above Rule > 1 click Add

30. Click on Policy Assignments and verify that the policy is assigned to NGFW1. Save the Access Control policy
and then deploy by clicking Deploy > Deployment, select NGFW1, then click Deploy > Deploy.

31. Save the policy, then Deploy the configuration changes Deploy > Deployment > NGFW1 > Deploy > Deploy

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 63 of 173
 Cisco dCloud

32. Monitor the policy deployment from Notifications > Tasks until it completes. Then we are ready to test the
configuration with real user traffic flows.
dCloud: The Cisco Demo Cloud

Important Note: Before proceeding, run the following user identity scripts to ensure they are working properly in the
lab. In Jumpbox Desktop open RADIUS Simulator folder > run RadiusListener and keep the CMD session opened in
background (minimize window), then run StartSessions > Terminate Sessions > Start Sessions.

33. In the FMC under Analysis > Users > Active Sessions and User Activity, validate that you see Eric and Dilbert
users with Passive Authentication type. Eric should come from the DEVdCloudRealm(dev.dcloud.local) and
Dilbert from dCloudRealm (dcloud.local).

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 64 of 173
 Cisco dCloud

34. Open a remote desktop session to the Wkst1 PC from the jumpbox by opening the Remote Desktops folder
and then the Wkst1 shortcut.

dCloud: The Cisco Demo Cloud

35. Once your session starts, open the Users folder on the desktop, then open the folder named “NGFW1 is your
gateway”
Run the script with Eric in the name – this simulates the user login/user to IP mappings for Eric from Active Directory 2 in
the dev.dcloud.local domain
36. Open Firefox and navigate to facebook.com, which is blocked by our Access Control rule.

NOTE: By entering facebook.com, the initial connection to the site is HTTP, which results in the FMC block page.
Entering https://facebook.com will result in a more generic Server Connection Failed message. Subsequent
connections to Facebook will probably use HTTPS, resulting in the generic browser failure page.

37. Repeat the steps above using the shortcut with Dilbert in the name. Verify the page is blocked.
38. Navigate back to FMC and review connection events
Navigate to Analysis > Connections > Events
39. Click Table View of Connection Events
40. Click Edit Search
41. In the Initiator User field, enter eric, dilbert
42. (optional) Under URL, enter *facebook.com to narrow the search results further. (in case no events show up, it
might be due to the enabled “DNS over HTTPS” option in the browser, either skip the URL field in the
connection event search or disable the “DNS over HTTPS” option in the used browser.)

NOTE: the * wildcard will return all URLs ending with facebook.com

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 65 of 173
 Cisco dCloud

dCloud: The Cisco Demo Cloud

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 66 of 173
 Cisco dCloud

Task 2. Change the Realm Sequence Order

1. Go to System (Gear Icon) > Integration > Realm Sequences. Click the pencil icon to edit the multi-domain
demo sequence
dCloud: The Cisco Demo Cloud

2. Drag the Realms listed to change the order of the sequence with DEVdCloudRealm (AD) first and dCloudRealm
(AD) second click Save and deploy changes (Deploy > Deployment > select NGFW1 > Deploy > Deploy).

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 67 of 173
 Cisco dCloud

Task 3. Validate the multi-domain functionality

1. Following the previous steps, send traffic from Wkst1 from the Eric and Dilbert users to Facebook web sites and
validate that the traffic is still blocked regardless of the AD/Realm sequence order.
dCloud: The Cisco Demo Cloud

2. Navigate back to connection events and review events following the previous steps.

Notice that the users are coming from different domains but from the same network segment.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 68 of 173
 Cisco dCloud

Scenario 8 - FMC: SAML 2.0 and RA-VPN

Starting Firepower release 6.7, FTD now supports Single Sign-On for Remote AccessdCloud:
VPNThe users with a
Cisco Demo Cloud

SAML 2.0 compliant Identity Provider (IDP).

• Security Assertion Markup Language (SAML) – an open standard for exchanging authentication and authorization
data between an identity provider and a service provider
• Identity Provider – a system that performs user authentication and issues assertions. Examples include DUO, OKTA,
Azure AD, etc.
• Service Provider – a service or server which requests and obtains an authentication assertion from the identity
provider. In this case, FTD is the Service Provider.
• VPN Client – The AnyConnect VPN Client, which prompts for SAML2.0 authentication via the embedded browser.

This feature is available for both FMC and FDM managed devices. In this lab exercise, we will use DUO
Single Sign-On as the IDP, which authenticates the users against Azure AD and provides MFA through
DUO. The FMC allows for configuring other SAML IDPs as well.

Objectives

1. Review the FTD and DUO Settings

2. Using FMC, configure Remote Access VPN with the SAML as an Authentication method
3. Verify the VPN Connection and test the SAML authentication

Understanding the DUO Integration

1. Here we are leveraging DUO SSO along with Azure AD. All the VPN users exist on the Azure AD, and the
Primary Authentication will be done on the Azure AD.
2. DUO provides Single Sign-On and the MFA for the VPN users upon successful authentication by Azure AD.

The DUO and the Azure AD Accounts used for this lab are shared by all the Lab users - the login to the DUO and
Azure account has not been shared. These accounts will be available for the duration of the SEVT Labs.

3. More information on how DUO SSO works and integrates with Azure AD as the SAML IDP is available here.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 69 of 173
 Cisco dCloud

Task 1. Preparing and Verifying the FTD Configuration

dCloud: The Cisco Demo Cloud

Apply VPN License on the NGFW1
1. In the FMC, navigate to System > Licenses > Universal Licenses

Click on Edit Licenses.

2. Select AnyConnect Plus.
3. Select NGFW1.
4. Click Add and then Apply.

Verify the Network Objects on the NGFW

1. In the FMC, navigate to Objects > Object Management. Click Network

2. Using the Filter search box, you can review the objects that were created in advance. Enter the names below to
verify that the objects have been created :

VPNPoolIPs - Confirm that it contains IP address range 198.19.10.57-198.19.10.62. This object will be used in NAT-
exemption and represents the IP addresses to be assigned to the AnyConnect VPN user. The following screen captures
show how the object was configured.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 70 of 173
 Cisco dCloud

3. LAN_Network - Confirm it contains IP address network 198.19.10.0/24. This is the internal corporate network
protected by the VPN headend. The following screen capture shows how the object was configured.

dCloud: The Cisco Demo Cloud

4. DNS_Server - Confirm that it contains IP address 198.19.10.100. The following screen captures show how the
object was configured.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 71 of 173
 Cisco dCloud

Task 2. Create the FMC Single Sign-on Server Object

1. You should be at the Object Management Page. Navigate to Objects > Object Management > AAA Server.
dCloud: The Cisco Demo Cloud

2. Click Single Sign-On-Server. Click

3. Open a new browser tab.
Click on the Aux link in the bookmark toolbar.
4. Click on the link November 2020 SEVT.
5. Click on the file SSO_Server.txt.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 72 of 173
 Cisco dCloud

dCloud: The Cisco Demo Cloud

6. Copy and paste the following information from the SSO_Server.txt file into the Sign-On-Server page in the
FMC.
Name: DUO_SSO_Azure_AD

7. Identity Provider Entity ID: https://sso-

e536f2c9.sso.duosecurity.com/saml2/sp/DIJVXBZTQQNVKQRXK5BA/metadata
8. SSO URL: https://sso-e536f2c9.sso.duosecurity.com/saml2/sp/DIJVXBZTQQNVKQRXK5BA/sso
9. Logout URL: https://sso-e536f2c9.sso.duosecurity.com/saml2/sp/DIJVXBZTQQNVKQRXK5BA/slo
10. Base URL: https://ngfw1-outside.dcloud.local

11. The Identity Provider Certificate is the certificate FTD uses to verify the messages signed by the IDP - DUO
SSO in this case. Since the DUO account has already been provisioned, this certificate has been pre-generated
for this lab exercise. If you wish, you can download and inspect the certificate DUO_Single_SignOn.crt from
the same folder as the SSO_Server.txt file. This certificate is also included in the SSO_Server.txt file.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 73 of 173
 Cisco dCloud

dCloud: The Cisco Demo Cloud

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 74 of 173
 Cisco dCloud

12. Click the + icon next to Identity Provider Certificate. Now add the Cert Enrollment for this certificate.
Name : DUO_Single_SignOn

dCloud: The Cisco Demo Cloud

13. Under CA Information, select Enrollment Type as Manual.

14. In the textbox named CA Certificate, copy and paste the contents of the certificate from SSO_Server.txt.

15. Click Save and select this certificate from the dropdown.
16. The service provider certificate is used by FTD to sign the requests and build a circle of trust with IdP. Click +
For Name, enter NGFW1_Outside.

17. Select PKCS12 File from the Enrollment Type drop-down menu.
18. Click Browse PKCS12 File and select ngfw-dcloud.pfx (the extension may be hidden) from the Certificates\Lab
Certificates\Other Certificates folder on the Jumpbox desktop. Click Open.
19. For Passphrase, enter C1sco12345.
20. Click Save and select NGFW1_Outside from the dropdown in the Single Sign-on Server object window.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 75 of 173
 Cisco dCloud

21. Verify the Single Sign-On Server Object settings, as shown below:

dCloud: The Cisco Demo Cloud

22. Save the performed configuration changes.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 76 of 173
 Cisco dCloud

Task 3. Run Remote Access VPN Wizard

In FMC, navigate to Devices > VPN > Remote Access. Click Add. This will launch the wizard.
dCloud: The Cisco Demo Cloud

Complete the Policy Assignment page of the wizard

1. For Name, enter RAVPN.
2. Uncheck IPsec-IKEv2.
3. From Target Devices, select NGFW1. Click Add.
4. Click Next in the bottom right corner.

Complete the Connection Profile page of the wizard

1. For Connection Profile Name, enter RAVPN (You must enter this name exactly as shown as this will be used to
match the DUO MFA account).
2. For the Authentication Method, please select SAML
3. For Authentication Server, please select the SSO object created earlier - DUO_SSO_Azure_AD.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 77 of 173
 Cisco dCloud

4. Under Client Address Assignment, we create and assign the IPv4 Address Pool to be assigned to the Remote
Access VPN users. Click on the Pencil icon. Click on the + icon to the right of the IPv4 Address Pools field.
Enter the details as below:
dCloud: The Cisco Demo Cloud
For Name, enter VPNPool.
5. For IPv4 Address Range, enter 198.19.10.57-198.19.10.62.
6. For Mask, enter 255.255.255.248.
7. Click Save.
8. From the Address Pools window, select VPNPool, then click Add to add it to the Selected IPv4 Pools column.
Click OK.

9. Under the Group Policy, verify that the group policy is set to DfltGrpPolicy. Click on Edit Group Policy.
Under General > VPN Protocols, uncheck IPsec-IKEv2.
10. Under General > DNS/Wins
• Select DNS_Server from the Primary DNS Server drop-down list.
• For Default Domain, enter dcloud.local.

NOTE: For better security, we recommend that split-tunneling not be used. However, because there is no console
access for the PC on which you will run AnyConnect, split tunneling must be used in this Scenario. Since there are
different ways to access the PC in dCloud, you need to create a standard ACL to bypass all these potential access
addresses. You will do this now.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 78 of 173
 Cisco dCloud

11. Under General > Split Tunneling

• Select Tunnel networks specified below from the IPv4 Split Tunneling drop-down list.
• For the Standard Access List drop-down list, click +.
• Create a standard access list called Split_Tunnel with the ACE that allows LAN_Network. dCloud: The Cisco Demo Cloud

o Search for LAN_Network in the Available Network and then click Add.
o Click Add at the bottom right.
o Click Save to save the access list.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 79 of 173
 Cisco dCloud

12. Under AnyConnect > Profile, click the + icon.

• Click Browse and select AnyConnectProfile.xml (the extension .xml may not be visible) from the RA VPN folder on
the Jumpbox desktop. The remaining fields will auto-populate.
• Click Save. dCloud: The Cisco Demo Cloud

13. Select AnyConnectProfile.xml from the Client Profile drop-down list.

14. Click Save to save the changes you made to DfltGrpPolicy.

15. Click Next.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 80 of 173
 Cisco dCloud

Complete the AnyConnect page of the wizard.

1. Click + to add a new AnyConnect Image.
2. Click Browse and select the AnyConnect-win-4.7.02036-webdeploy-k9.pkg from the RA VPN folder on the
dCloud: The Cisco Demo Cloud
Jumpbox desktop. Click Open. The remaining fields will auto-populate.

3. Click Save.
4. Enable the AnyConnect File Object Name checkbox and click Next

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 81 of 173
 Cisco dCloud

Complete the Access & Certificate page of the wizard

In this page of the wizard, we choose the NGFW interface, which will accept Incoming VPN connections. Also, we
select the Server-Side certificate the NGFW will present for the VPN connection.
dCloud: The Cisco Demo Cloud

1. For Interface group/Security Zone, select OutZone.

2. For Certificate Enrollment, select NGFW1_Outside from the drop-down menu.
3. Do not check the option Bypass Access Control policy for decrypted traffic (sysopt permit-vpn).

NOTE: For this lab, we are not selecting the option ‘Bypass Access Control Policy for decrypted traffic.’ If you
choose this option, you do not need to create specific rules in the Access Control Policy to allow the decrypted
VPN traffic.

4. Click Next.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 82 of 173
 Cisco dCloud

Review the configuration

1. Review the configuration on the Summary page. Click Finish.

dCloud: The Cisco Demo Cloud

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 83 of 173
 Cisco dCloud

Task 3. Allowing VPN Traffic through the NGFW

dCloud: The Cisco Demo Cloud

Modify the access control policy to allow decrypted VPN traffic

The access control policy configuration needs to be added if you did not Check the option Bypass Access Control
policy for decrypted traffic (sysopt permit-vpn).

1. In FMC, navigate to Policies > Access Control > Access Control.

2. Select and edit the access control policy Base_Policy. Click Add Rule.
For Name, enter AnyConnect-SSO-Permit.

3. Select into Default from the Insert drop-down list.

4. Keep the action as Allow.
5. The Zones tab should already be selected.
6. Select OutZone and click Add to Source.
7. Select InZone1 and click Add to Destination.

NOTE: The direction of the flow of the VPN traffic is from OutZone to InZone1 - as the VPN is terminating on the
outside interface, which is assigned zone OutZone

8. Select the Networks tab

Search and select VPNPoolIPs and click Add to Source Networks.
9. Search and select LAN_Network and click Add to Destination.
10. Select the Inspection tab
Select Demo Intrusion Policy from the Intrusion Policy drop-down list.
11. Select BP File Policy from the File Policy drop-down list.
12. Click Add to add the rule.
13. Click Save to confirm the changes to the access control policy changes.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 84 of 173
 Cisco dCloud

Configure a NAT exemption

1. In the FMC, navigate to Devices > NAT.

dCloud: The Cisco Demo Cloud
2. Select and edit the existing NAT policy called Default NAT Policy. Click Add Rule.
The Interface Objects tab should be selected.
3. Select InZone1 and click Add to Source.
4. Select OutZone and click Add to Destination.
5. Select the Translation tab
For Original Source, select LAN_Network.
6. For Original Destination, select Address in the first box and choose VPNPoolIPs in the second.
7. For Translated Source, select Address in the first box and choose LAN_Network in the second.
8. For Translated Destination, select VPNPoolIPs.
9. Select the Advanced tab and select Do not proxy ARP on Destination Interface.

NOTE: Enabling Do not proxy ARP on Destination Interface is critical in this lab exercise. If you miss this step, your
pod may have access issues since all devices are managed in band.

10. Click OK to save the NAT rule.

11. Click Save to confirm the changes to the NAT policy.

Deployment
Perform policy deployment changes to push the RA-VPN down to the FTD / NGFW1 device:

1. Click Deploy > Deployment.

2. Select NGFW1. Click Deploy. When asked to confirm, click Deploy. Wait until policy deployment is successful.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 85 of 173
 Cisco dCloud

Task 4. Connecting to Remote Access VPN

dCloud: The Cisco Demo Cloud

Login with AnyConnect Client
1. Connect to Wkst2 by one of the methods below. You will automatically log in as the administrator. You can
connect using one of two methods.

From the Jupmbox PC, on the Desktop, locate and open the Remote Desktop folder. Click on the Wkst2 (Outside PC)
shortcut in the Remote Desktops folder on the Jumpbox desktop. However, if you do this, you must allow local LAN
access in the AnyConnect client.

2. If you are connected to the pod via VPN, use an RDP client on your laptop to connect to 198.18.133.23. Log in
as Administrator using password C1sco12345.

3. From the desktop of Wkst2, open AnyConnect from the Start Menu. The Connect To field should have NGFW1
selected. Click on Connect.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 86 of 173
 Cisco dCloud

4. You will get the Microsoft login prompt within the embedded browser.

dCloud: The Cisco Demo Cloud

5. When prompted, login with the following details:

For your VPN username, please open the URL http://tmedemos.cisco.com/cgi-bin/get_username.py
• Use the username displayed as the output.

6. Password: C1sco12345
7. You will be asked to update your password upon the first successful login.

8. Upon successful login, the DUO setup screen will appear since this is a new login account.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 87 of 173
 Cisco dCloud

dCloud: The Cisco Demo Cloud

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 88 of 173
 Cisco dCloud

DUO MFA Setup

Now, at this point, the VPN user account you used was successfully authenticated by Azure AD and
redirected to DUO for MFA. Since this vpn user is not associated with the DUO SSO and there is no MFA
dCloud: The Cisco Demo Cloud
device associated with it, you will be prompted to setup the account.

1. Click on Start setup.

2. Choose Mobile phone (selected by default).

3. Click Continue.

NOTE: Before proceeding with the next step, please note that your mobile number will be mapped to the vpn user
you used to login to AnyConnect with and will be saved in the DUO Admin Account used for this Single Sign-On.
No other lab users have access to that account – only the author of this lab guide has access to this account.
Please reach out to the Lab Administrators if you have any issues setting up your number or wish to remove your
number after testing.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 89 of 173
 Cisco dCloud

4. Next, enter your mobile number along with the country code. Click Continue.

dCloud: The Cisco Demo Cloud

5. Enter the type of phone. Click Continue.

6. Now, a prompt to Install Duo Mobile will appear. If you already have the Duo App installed, click on I have Duo
Mobile installed. If not already installed, install the App from the App Store.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 90 of 173
 Cisco dCloud

7. After install, Activate Duo Mobile by following the on-screen instructions. Click Continue – the button will be
enabled once this account has been added to the Duo App.

dCloud: The Cisco Demo Cloud

8. DUO MFA will prompt you to choose the authentication method preference. Click Continue to Login.

9. Next, send a Push or a Passcode to complete a successful AnyConnect Login MFA.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 91 of 173
 Cisco dCloud

10. Approve the push notification from the phone, and the AnyConnect login will succeed.

dCloud: The Cisco Demo Cloud

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 92 of 173
 Cisco dCloud

Verifying VPN Access

1. Using the Firefox browser’s bookmarks on Wkst2, confirm that you can now access two internal websites that
are bookmarked: Inside, Alt Inside.
dCloud: The Cisco Demo Cloud
2. In any one of these internal servers, click on the Files link, then click on Zombies.pdf - which is considered
malware. Confirm that it is blocked. Then confirm that a benign file like ProjectX.pdf is not blocked.

NOTE: To ensure that a cloud lookup time out (which occasionally happens in these pods) does not break the
exercise, the file Zombies.pdf was added to the FMC custom detection list. If you want to perform a test that
requires the cloud lookup, try downloading the file named malware.exe from the file listing. You can then use the
FMC to look for the malware events and confirm the file policy is working.

3. Confirm that intrusions are being blocked by opening a command prompt on Wkst2 and masking an FTP
connection to inside.dcloud.local. The connection should be allowed. Log in as guest, password C1sco12345.
Once logged in, type cd ~root. The connection should be reset because Snort signature 336 has been
triggered.

4. (Optional) In the FMC window opened on the jumpbox, examine the malware event (Analyze > Files > Malware
Events) and intrusion event (Analyze > Intrusions > Events). You can also examine RA VPN user statistics by
navigating to Overview > Dashboards > Access Controlled User Statistics > VPN.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 93 of 173
 Cisco dCloud

5. On NGFW1 PUTTY Session, type the command: show vpn-sessiondb detail AnyConnect to view the details
and statistics.

dCloud: The Cisco Demo Cloud

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 94 of 173
 Cisco dCloud

Scenario 9 - FDM Intrusion Policy/Snort 3

Firepower 6.7 introduces some important improvements in FDM Intrusion policy management.
dCloud: The Cisco Demo Cloud

Noteworthy capabilities include:

• Custom Intrusion policies

• Enable/disable rules by rule group
• Set security level (base rule set) for each group
• Edit/delete default Intrusion policies

While the features above are related to rule/policy management, the new Snort 3 inspection engine must
be enabled to take advantage of them.

NOTE: Some features are not available in this release when Snort 3 inspection is enabled. These include virtual
routers and time-base Access Control rules.

Task 1. Review Snort 2 Intrusion policy configuration

Before we look at the new features with the Snort 3 engine, let’s review what Intrusion policy editing
looked like before version 6.7.

1. From the jumpbox desktop, open Firefox and click the hyperlink for the FTD device NGFW2 (FDM) at
https://ngfw2.dcloud.local and login as username: admin, password: C1sco12345 (prepopulated).
2. From the FDM management UI, click Policies > Intrusion.

NOTE: The four available policies correspond to a Cisco Talos rule set. There is no option to create a customized
Intrusion policy.

3. Click on the Balanced Security and Connectivity tab. Note that the Snort rules are sorted ascending by SID.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 95 of 173
 Cisco dCloud

4. Click on the Action cell in one of the rules. Note that individual rule states can be set to override Talos policy
settings (ALERT, DROP, DISABLED).

dCloud: The Cisco Demo Cloud

5. Click in the Search field, note that rule searches are limited to the GID, SID, and Action fields. Click Cancel.

6. Locate the 1:105 rule with the message MALWARE-BACKDOOR – Dagger_1.4.0. Click the Action field and set
it to DROP. We will confirm that this custom rule state is maintained after the upgrade to Snort 3.

7. Before proceeding, deploy your policy changes using the button and clicking Deploy Now.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 96 of 173
 Cisco dCloud

Task 2. Enable Snort 3

1. From the FDM management UI, click Device: ngfw2.dcloud.local. dCloud: The Cisco Demo Cloud
2. In the Updates section, click View Configuration.
3. In the Intrusion Rule section, note the current Inspection Engine is 2.9.x.

4. Click the Upgrade to 3.0 link. Note the warning dialog regarding features not currently available with the Snort 3
engine.

5. Confirm the upgrade by clicking Yes. Monitor the upgrade with the Task List.

NOTE: To upgrade the detection engine, your device cannot have any policy deployments pending. If you receive
an error regarding pending changes, exit the Enable Snort 3.0 dialog and deploy pending changes by clicking the

button. After the deployment completes, return and confirm the detection engine upgrade.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 97 of 173
 Cisco dCloud

6. When the upgrade is complete, return to the Device: <device_name> page and in the Updates section, click
View Configuration again.
dCloud: The Cisco Demo Cloud

NOTE: The inspection engine is now version 3.0. You can also see that the Intrusion Rule version has changed.
Instead of an SRU version similar to “2020-08-18-001-vrt” the version is now “20200921-1729” or similar. This is
because Snort 3 uses the new Lightweight Security Package (LSP) for rule updates.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 98 of 173
 Cisco dCloud

Task 3. Customize Intrusion Policies

With Snort 3 enabled, Intrusion policy management in version 6.7 provides greatly expanded
dCloud: Thecapabilities.
Cisco Demo Cloud

1. From the FDM management UI, click Policies > Intrusion. Notice that the same four policies are here as before.

2. Click the pencil icon under the ACTIONS column for the Balanced Security and Connectivity Policy. Note that
the 1:105 rule that was modified previously is still set to Drop.

3. Note the rule groups on the left. Expand the Browser group and expose the child groups.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 99 of 173
 Cisco dCloud

4. Select the Chrome child group. Note that the rules list now shows just BROWSER-CHROME rules.

dCloud: The Cisco Demo Cloud

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 100 of 173
 Cisco dCloud

5. Click on one of the links under the GID:SID column to load the rule’s snort.org documentation in a separate
browser tab. Review the rule documentation. When finished, close this tab.

dCloud: The Cisco Demo Cloud

NOTE: The Security Level for this group shows Level 2. Hover over the Security Level bar icon. The message
indicates that Level 2 corresponds to the Balanced Security and Connectivity policy. Note that all the Browser
groups currently have this same security level. Note the count of enabled and total rules next to the
Browser/Chrome group.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 101 of 173
 Cisco dCloud

6. Click the Edit link next to the Security Level.

dCloud: The Cisco Demo Cloud

7. The Edit Security Level dialog, allows you to select any of the four base Talos policies for this particular rule
group. Click Level 3.
8. Click the View description link to expand the description of this level. This is a description of the Talos Security
Over Connectivity policy. Click OK.

NOTE: That the number of enabled rules in the Browser / Chrome group has now increased. This allows users to
adjust the security level for specific rule groups without manually overriding rule states. Rule states for the selected
group will correspond with the selected Talos policy and automatically update with subsequent rule releases.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 102 of 173
 Cisco dCloud

dCloud: The Cisco Demo Cloud

9. Click the Browser top-level group to collapse the child groups. Then click on the Potentially Unwanted
Applications group. Note there are three child groups with rules enabled.

10. Click the icon next to the Filter at the top of the groups list. This displays the Add Rule Groups dialog.

NOTE: This dialog allows enabling additional rule groups. The icon by the top-level group indicates that all the
child groups are enabled, while the icon indicates that some of the child groups are disabled. Expand some of
the groups and note which child groups are enabled in this policy. Policies can be customized by enabling or
disabling child groups.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 103 of 173
 Cisco dCloud

11. Expand the Potentially Unwanted Applications group by clicking the > symbol to the left. Notice there are
additional PUA groups that can be enabled. You can also select a custom security level (Talos base policy) for
each group.
dCloud: The Cisco Demo Cloud

12. Enable the Application Detection group and leave the default at Security Level 2. Click OK to save changes.
Notice that your Potentially Unwanted Applications group now has an additional child group.

13. Click the Filter field above the rules list. Note the drop-down allowing you to search for GID, SID, or specific
rule actions.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 104 of 173
 Cisco dCloud

14. This Filter field now allows free form text searches. Enter the text CVE-2020-1380 and press Enter. Note that
rules written for this specific CVE are now displayed. This Filter field is a full-text search of the entire Snort
rule, including rule detection keywords. Search terms can also be combined for more specific searches.
dCloud: The Cisco Demo Cloud

15. Using the Filter field, search for rules designed to detect the Emotet malware with the Action set to Drop.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 105 of 173
 Cisco dCloud

16. To change the Name and Description of this policy, click the Edit link to the right of the Balanced Security and
Connectivity policy name. You can also modify the Intrusion Mode and Base Template here.

dCloud: The Cisco Demo Cloud

17. If you want to delete this built-in policy, click the trashcan icon (only if it is not in use by an Access Control rule).

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 106 of 173
 Cisco dCloud

Scenario 10 - Interface Object Optimization

dCloud: The Cisco Demo Cloud

Introduction

The Interface Object Optimization (IOO) feature minimizes Access Control (AC) and Pre-filter rule
expansion, in the LINA engine, upon policy deployment of the rule set from the Firepower Management
Center (FMC) to the managed device (FTD). Both, Pre-filter and Access Control policy rule sets can
contain the source/destination security zones or interface object groups that may consist of multiple
interfaces. When the FMC deploys such rules to the FTD, the FMC must expand the interface object
group to individual interfaces.

For example, suppose we take an Access Control Policy rule that includes two interfaces in the source
zone/interface group and two interfaces in the destination zone/interface group. This rule gets expanded
upon policy deployment into two by two, which equals to four Access Control Element entries in the LINA
engine (even though from the FMC perspective, this rule is written in one UI access control rule line).
With the growing number of interfaces in security zones/interface groups in the FMC rule set, there is an
effect on policy deployment time, performance, and memory utilization on the managed device.

To minimize the Rule Expansion, we have added a feature named Interface Object Optimization (IOO)
that natively supports “interface object-group” in the Advanced Access List in LINA as part of the Cisco
Firepower 6.7 release. This enhanced version of “interface object-group” helps us to represent multiple
interfaces within advanced ACL - resulting in a 1:1 mapping between FMC UI Access /Pre-filter Policy
Rule and FTD LINA access-list.

To summarize, the Interface Object Optimization (IOO) feature provides the following benefits:

• Reduction of policy deployment time

• A lower number of rules expanded in the LINA FTD engine for Access Control Rules or Prefilter rules that have
defined multiple interfaces within:
o Security Zones
o Interface Object Groups

NOTE: The IOO feature is designed for AC Policy and Pre-Filter Policy Rules on Cisco Firepower Threat Defense
(FTD) software.

Objectives:
Policy deployment time without Interface Object Optimization (IOO) Feature Disabled
Rule Expansion Explosion with IOO disabled
Policy deployment time with Interface Object Optimization Feature Enabled
Rule Expansion Explosion with IOO enabled
Verification of Object Group Search Usage (Enabled/Disabled)
ACL rule expansion for Interface Object Group in conjunction with Object Group Search Enabled

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 107 of 173
 Cisco dCloud

Task 1. Policy Deployment Time without IOO Feature

Review content of the preconfigured Security Zones and validate the number of interfaces allocated to
each zone. dCloud: The Cisco Demo Cloud

1. Navigate to the Jumpbox, open the Firefox browser, and log in to FMC WebUI with username admin, password
C1sco12345 (If not prefilled already).

Navigate to Objects > Object Management > Interface (from the page tree).
in-dummy
Expand “in_dummy_SZ” to confirm the security group has two interfaces (in_dummy_1, in_dummy_2)
out-dummy
Expand “out_dummy_SZ” to confirm the security group has two interfaces (out_dummy_1, out_dummy_2)

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 108 of 173
 Cisco dCloud

2. Navigate to Policies > Access Control

Click on “New Policy” dCloud: The Cisco Demo Cloud

Enter Name “Rule Expansion Demo” and Edit this policy
Leave Default action to “Block all traffic”
Assign NGFW1 into Targeted Devices, select NGFW1 and click “Add to Policy”
Save and confirm with Yes, the reassignment of policy
Click “+ Add Rule” to create a new Access Control Rule Named “Rule Expansion Demo Rule”
Add “in_dummy_SZ” to the Source Zones
Add “out_dummy_SZ” to the Destination Zones
Under the Logging tab, enable “Log at End of Connection”
Click “Add” to save the rule

3. Save the ACP changes

4. Perform Policy Deployment, click Deploy > Deployment, Select NGFW1 device pending changes, and Deploy

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 109 of 173
 Cisco dCloud

5. Monitor Policy Deployment Time under Notifications Task Menu > Deployments:

dCloud: The Cisco Demo Cloud

NOTE: Overall Policy Deployment Time was in this use case 1minute and 44 seconds

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 110 of 173
 Cisco dCloud

Task 2. Rule Expansion Explosion with IOO disabled

1. SSH to the NGFW1 using the PuTTY application located on the Jumpbox desk(username admin, password
dCloud: The Cisco Demo Cloud
C1sco12345)

“system support diagnostic-cli”

“enable”
Hit Enter as the enable password is not set – or needed.
Issue the following CLI commands and observe the output

show access-list

show access-list | i elements

show run all object-group interface

show object-group interface

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 111 of 173
 Cisco dCloud

Task 5. Enable Interface Object Optimization on FMC

Follow the steps below to enable the IOO feature on the FMC: dCloud: The Cisco Demo Cloud

1. Under Devices > Device Management

Choose managed sensor “NGFW1” from the device list and click the Edit button for the relevant device
Navigate to the Device tab
Under Advanced Settings, select Pencil/Edit button
Enable Interface Object Optimization checkbox
Accept the Warning and click the Save button

2. Deploy changes – Deploy > Deployment > NGFW1 checkbox > Deploy

3. Monitor the Policy Deployment Time

NOTE: You can now see the overall policy deployment with the same device configuration by having IOO enabled;
the policy deployment took only 36 seconds!

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 112 of 173
 Cisco dCloud

Task 6. Rule Expansion Explosion with IOO enabled

1. SSH to the NGFW1 using Putty application located on Jumphost – See Rule Expansion with IOO Disabled if you
dCloud: The Cisco Demo Cloud
logged off.

2. Issue the following CLI commands and observe the output

show access-list

show access-list | i elements

show run all object-group interface

show object-group interface

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 113 of 173
 Cisco dCloud

Verification of Object Group Search Usage (Enabled/Disabled)

1. Validate whether the OGS is enabled or disabled

dCloud: The Cisco Demo Cloud

show run all object-group-search

Rule Expansion with Interface Object Optimization and Object Group Search Usage Enabled

1. Enabled Object Group Search and Perform Policy Deployment:

Devices > Device management > Click Device Box NGFW1 > Edit Advance Settings > Mark Checkbox for Object Group
Search > OK > Save > Yes

Save and Deploy configuration from Deploy > Deployment > select device with pending changes and Deploy

Validate that the OGS is enabled

1. SSH to the NGFW1 using Putty application located on Jumphost – See Rule Expansion with IOO Disabled if you
logged off.

show run all object-group-search

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 114 of 173
 Cisco dCloud

Validate that the IOO is enabled

show run all object-group interface (or - show object-group interface)

dCloud: The Cisco Demo Cloud

show running-config object-group interface

Validate how does OGS in conjunction with the IOO feature affect ACL rule expansion

show run access-list

show access-list | i elements

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 115 of 173
 Cisco dCloud

show access-list

dCloud: The Cisco Demo Cloud

Reassign the Access control Policy back to Base_Policy.

Policies > Access Control > Edit Base_Policy

Click on “Policy Assignments” and select NGFW1 to “Add to Policy”
Click the “OK” button and confirm ACP reassignment for the NGFW1 device
Save Access Control Policy and perform policy deployment (Deploy > Deployment)

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 116 of 173
 Cisco dCloud

Scenario 11 - FMC Audit Enhancements, Selective Deployment, and

Rollback dCloud: The Cisco Demo Cloud

Introduction
This exercise introduces some of the new features related to auditing, policy deployment, and rollback.
Audit features are now expanded to include several new policies and object types. Selective
deployment allows teams with SecOps and NetOps components to selectively deploy Intrusion and
Access Control policies even if both policy types have been updated. Configuration rollback provides a
way to restore a previous device configuration in an emergency.

Task 1. Audit Improvements

First, we will make some changes to the Access Control and Intrusion policies.

1. Login to the FMC at fmc.dcloud.local, you can use the FMC shortcut in the jumphost browser. Navigate to
Policies > Access Control and edit the policy named Base_Policy.

2. From the Rules tab, click the pencil icon to edit rule #7, Web Server Access.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 117 of 173
 Cisco dCloud

3. Click the Inspection tab and select the Demo Intrusion Policy to inspect traffic matching this rule

dCloud: The Cisco Demo Cloud

4. Click Save to update the rule, then click the Save button in the top right to save the policy changes.

5. Navigate to Policies > Intrusion and edit the Demo Intrusion Policy.

6. Under Policy Information, click the Rules link. Then in the Filter bar, search for rules related to the GoldenSpy
trojan

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 118 of 173
 Cisco dCloud

7. Check the boxes to select any rules not already enabled. Then click Rule State and set these to Drop and
Generate Events.

dCloud: The Cisco Demo Cloud

8. Click Policy Information in the upper left corner, then click the Commit Changes button to save your policy
changes.

9. When prompted, type “Enabled GoldenSpy rules” in the Description of Changes field and click OK.

10. Navigate to Objects > Object Management

11. Select Network from the list on the left, then click the Add Network drop-down and choose Add Object.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 119 of 173
 Cisco dCloud

12. Add a network object with the attributes below:

Name: ISE-PIC
IP: 198.19.10.131
dCloud: The Cisco Demo Cloud

13. Click Save

14. Now, let’s view the Audit Log to see how the changes have been tracked.

15. Navigate to System > Monitoring > Audit (Note in the new Light UI theme the System menu is now a gear icon)

16. The default expanding time window should show the most recent audit events, including the changes made
above. Notice creating the Network Object and the Access Control policy update both have a comparison

report icon ( ). Click the comparison report icon by the network object creation event.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 120 of 173
 Cisco dCloud

17. This loads the report for the ISE-PIC network object in a new browser tab.

dCloud: The Cisco Demo Cloud

18. Notice the left column is blank since this is a new object. Review the information and close the browser tab
when finished.

19. Version 6.7 adds comparison reports for the following policies/objects:

Routing policy
FTD Platform Settings
VPN policy
DHCP server settings
DDNS settings
Pre-filter policy
QoS policy
Network, Port, URL, and VLAN tag objects

20. Review the other audit events.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 121 of 173
 Cisco dCloud

Task 2. Selective Deployment

Next, we will use the selective deployment feature. This feature allows the deployment of specific
policies even if they are not the only policies that have been modified. However, somedCloud:
conditions, such
The Cisco Demo Cloud
as changing global objects, may require the deployment of all policies.

We have made changes to multiple policies already but let’s deploy changes to just the Intrusion policy.
Navigate to Deploy > Deployment

1. There are pending deployments for all our devices. However, we only want to deploy Intrusion policy changes
to NGFW1.

2. Click the > arrow to the left of the NGFW1 device to expand the deployment information.

3. Click the icon to reveal the selection checkboxes for each policy.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 122 of 173
 Cisco dCloud

4. Check the box by the Intrusion Policy and then click the Deploy button.

5. Click the Deploy button in the confirmation dialog dCloud: The Cisco Demo Cloud

6. Wait for the policy to deploy. You can track the deployment in the task list if desired.

7. Return to the Deploy > Deployment page and note that the NGFW1 device now shows a pending deployment
for the Access Control Policy only.

8. To prepare for the next steps, deploy all the pending policy updates to all devices. When the Deployment
finishes, proceed to the next step.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 123 of 173
 Cisco dCloud

Task 3. Configuration Rollback

Next, we will look at the configuration rollback feature. This feature allows returning to a known good
state if an unknown change has impacted the device(s); This feature can roll back changes to Cisco
dCloud: The a single
Demo Cloud
device or multiple devices.

NOTE: The configuration rollback feature returns the device(s) to the last successfully deployed configuration. This
feature clears all configurations on the FTD device, causing existing connections to be dropped. Because of this, it
is best to fix policy configurations and re-deploy if possible. Meaning, rollback should only come into play in
extreme circumstances due to the potential to disrupt existing traffic.

1. Navigate to Deploy > Deployment History. There are several jobs listed. The newest job should be your
deployment to three devices. Expand this job by clicking the > arrow on the left.

2. Notice there are several Rollback icons on the screen. There is a Rollback icon for each device and one on the
top for the entire deployment job. This allows you to selectively rollback the configuration on a device or roll it
back on multiple devices.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 124 of 173
 Cisco dCloud

3. Click the Rollback icon for the job name. This allows rolling back all of the deployments to all three devices. This
displays a dialog similar to the one shown below.

dCloud: The Cisco Demo Cloud

4. To initiate the operation, click the Rollback button. A final warning dialog is displayed.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 125 of 173
 Cisco dCloud

5. When you’re positive this is what you want to do, click the Proceed button. The history page will update,
indicating that a rollback is in progress.

dCloud: The Cisco Demo Cloud

6. Monitor the Rollback operation with the task list and confirm success.

7. Return to the Deployment page (Deploy > Deployment) and note that all devices have pending deployments.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 126 of 173
 Cisco dCloud

8. If you expand any of the devices and click the icon, you will receive a message that a full deployment is
required due to the rollback operation. In an actual situation, you would correct the issue which led to the
rollback and re-deploy to your devices. dCloud: The Cisco Demo Cloud

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 127 of 173
 Cisco dCloud

Scenario 12 - Device Level Filtering for User Awareness Sessions

dCloud: The Cisco Demo Cloud

Introduction
In Firepower 6.7 Release, we have added a new functionality on FTD, Device-level identity mappings
filtering. This has been implemented because the user sessions and SXP mappings obtained from
ISE/ISE-PIC are broadcasted to all managed devices registered by the FMC.
Depending on the managed Firepower Appliance, each device has its own memory user identity limits.
Therefore they can scale up to a different number of user sessions / SXP mappings. The maximum
number of concurrent user logins/sessions per device platform is documented in:
https://www.cisco.com/c/en/us/td/docs/security/firepower/660/configuration/guide/fpmc-config-guide-
v66/introduction_to_network_discovery_and_identity.html?bookSearch=true#ID-2240-00000269

Objectives
• Filtering SXP mappings from Identity Services Engine (ISE)
• Filtering Passive Identity User Sessions from Identity Services Engine (ISE/ISE-PIC)

Task 1. Device Level Filtering for User Awareness Sessions

1. Log in to Cisco Firepower Management Center (FMC) UI from Jumphost Firefox browser (FMC bookmark)

2. Download Users from Active Directory 1 and 2

System > Integration > Realms > Download Now Users from both Realms
dCloudRealm
DEVdCloudRealm

3. Verify that FMC is integrated with ISE to obtain both User-IP mappings and SXP mappings.

Go to System > Integration > Identity Sources > Identity Services Engine
Note that the following options are checked:
• Session Directory Topic – option to obtain User-IP mappings from ISE to FMC
• SXP Topic - option to obtain SXP mappings from ISE to FMC

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 128 of 173
 Cisco dCloud

4. Validate that connectivity between FMC and ISE is successful. Click the Test button.

dCloud: The Cisco Demo Cloud

5. Apply the ISE network filter on the FMC to obtain and store sessions from ISE only from the 198.19.10.0/24
subnet. This allows us to limit the number of unnecessary user sessions / SXP mappings to come down from
ISE to FMC and then further to managed devices. This option is FMC-based sessions/mapping filtering based
on network subnets/hosts.

NOTE: Before the 6.7 release (6.6 and earlier), the ISE Network Filter was designed for only session directory / IP-
User Mappings because the filter was done in pxGrid 1.0. Since pxGrid 2 doesn’t support native filtering, we added
the capability on the FMC, and we filter all sessions coming in.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 129 of 173
 Cisco dCloud

In previous exercises, we have already configured User Identity Rules (Identity and Access Control
Policy).
dCloud: The Cisco Demo Cloud
NOTE: Before proceeding, you need to run two scripts for user identities to work properly in this simulated lab. To
run the scripts, go to the Jumphost Desktop, open the RADIUS Simulator folder, and then execute the script named
RadiusListener. Keep the CMD session opened in the background by minimizing the window and then start the
other script called StartSessions, run TerminateSessions, and again StartSessions.

6. Under Analysis > Users > User Activity, in the FMC, validate that you see John and Dilbert users with Passive
Authentication type. User John should be coming from the DEVdCloudRealm(dev.dcloud.local) and Dilbert from
dCloudRealm(dcloud.local)

7. Login to FTD CLI via Putty application located on Jumphost, use NGFW1 using saved session details with the
admin/C1sco12345 as credentials to the device.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 130 of 173
 Cisco dCloud

8. Add 198.19.10.35/32 - host IP address that belongs to Dilbert User by using the following command:

> configure identity-subnet-filter add 198.19.10.35/32

dCloud: The Cisco Demo Cloud

NOTE: Configuration of the identity subnet filter does persist after policy deployment and a reboot of the FTD
device.

9. The IP address in the identity filter belongs to Dilbert User Session, as already mentioned. Adding this host to
the identity subnet filter means that this is the only address eligible for User Awareness functions on this device.

10. Validate what IP subnet/hosts have been configured properly by using the following verification command:

> show identity-subnet-filter

NOTE: If the above command does not print out any networks, then there is no filter active for any networks, and all
networks are accepted for user identity functionalities.

11. Go to Workstation 1., On the Desktop of Workstation 1, click on the Users folder. You will find two subfolders.
Click on the “NGFW 1 is your gateway” sub-folder.

12. Run script that includes Dilbert name

Dilbert is associated to 198.19.10.35 IP address
Generate some traffic that will pass through NGFW1. For example, launch the Firefox browser and access Twitter.

13. Run script that includes Eric name

Eric is associated to 198.19.10.40 IP address
Generate some traffic that will pass through NGFW1. For example, launch the Firefox browser and access Twitter.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 131 of 173
 Cisco dCloud

14. Navigate to FMC Connections > Events and review event details for the Dilbert (198.19.10.35) and
Eric(198.19.10.39) user-generated traffic flows

dCloud: The Cisco Demo Cloud

Pay attention to the “Initiator User” column field in the connection events
The only recognized Initiator User for the NGFW1 device is Dilbert, as his IP address host is the only one accepted on
the device level that was previously configured via the identity-subnet-filter CLI command.

15. Now, let’s remove Device Filtering on the NGFW1. For that, issue the following CLI commands:

> configure identity-subnet-filter remove 198.19.10.35/32

> show identity-subnet-filter

16. Send traffic again from Workstation 1 originated from Dilbert and Eric users, for example, access
https://twitter.com.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 132 of 173
 Cisco dCloud

17. Go to the FMC and validate the FMC connection events one more time. Notice that now the user
identity/initiator user field should be populated for both traffic flows:

dCloud: The Cisco Demo Cloud

The Identity device-level filtering feature helps to filter what type of user-ip mappings or SXP mappings
should be processed by Snort on the device level basis to make sure that in environments where the
FMC is managing low and high-end appliances, none of the lower end appliances get overwhelmed by
the high number of sessions.

Before continuing with the next task, disable the “multi-domain” rule in “Base_Policy” Access Control
Policy:
Policies > Access Control
Edit “Base_Policy”
Right-click on the “multi-domain” rule and select State > Disable.
Save Access Control Policy

And perform policy deployment (Deploy > Deployment).

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 133 of 173
 Cisco dCloud

Scenario 13 - PxGrid 2.0 remediation with ISE using ANC

dCloud: The Cisco Demo Cloud

Introduction
Cisco’s Firepower Management Center (FMC) uses PxGrid 1.0 protocol for integration with Identity
Services Engine (ISE). FMC obtains identity information from ISE, such as User-IP mappings, User-
SGT/IP-SGT mappings, SXP mappings, and endpoint profiles using this communication channel.
Starting from Cisco Firepower 6.7 release, we have updated the communication protocol for this
integration from PxGrid 1.0 to 2.0, as the older version is being deprecated from ISE. PxGrid 2.0 offers
additional scale benefits for ISE, and more importantly, from the Firepower perspective, it enhances
High-Availability (HA) connectivity to ISE and now supports active/active HA connectivity.
Also, PxGrid 2.0 supports Adaptive Network Control (ANC) remediation. ANC now replaces Endpoint
Protection Services (EPS), which is used for controlling and monitoring network access of endpoints.

Objectives
• Validate that PxGrid 1.0 protocol is updated to PxGrid 2.0 version
• Reconfigure EPS remediation to ANC
• Quarantine endpoint through FMC and ISE integration using ANC and PxGrid 2.0

Task 1. Integration of FMC and ISE using PxGrid 2.0 Protocol

The upgrade of communication protocols between FMC/FDM and ISE is mostly invisible to the system
users; however, in the steps below, we showcase how to confirm the protocol changes and how they
change the configuration workflow for using remediation modules on FMC with ISE.

1. Navigate to the Jumpbox, open the Firefox browser, and log in to FMC WebUI with username admin, password
C1sco12345 (If not prefilled already).
2. Go to System (Gear Icon) > Integration > Identity Sources > Identity Services Engine and select the Test button
to validate connectivity to the ISE system. Next, expand Additional Logs to see details of the FMC and ISE’s
connectivity results (In the logs’ output, we can confirm that the FMC 6.7 release is using PxGrid version 2).

NOTE: The ISE Network Filter applies to mappings obtained from both Session Directory Topic and SXP Topic.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 134 of 173
 Cisco dCloud

3. Open a new tab in Firefox. Click the ISE bookmark from the bookmarks ribbon. The credentials
(admin/C1sco12345) are prepopulated. Press Login to enter ISE.

dCloud: The Cisco Demo Cloud

4. Navigate to Administration > PxGrid Services > All Clients. Here we notice that the FMC Client is in Offline
status.

NOTE: PxGrid 2.0 is using the REST and WebSocket protocols. Therefore, connections from PxGrid 2.0 appear
under Administration > PxGrid Services > Web Clients section.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 135 of 173
 Cisco dCloud

5. On ISE, create an Adaptive Network Control (ANC) policy for assignment to an endpoint programmatically from
Firepower.

dCloud: The Cisco Demo Cloud

Navigate to Operations > Adaptive Network Control > Policy List
Click Add
Enter a Name “quarantine_anc_policy” for the ANC policy
Select the Action “QUARANTINE,” for the ANC policy.
Click Submit

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 136 of 173
 Cisco dCloud

Task 2. FMC ISE Connection Status Health Monitor

1. In the FMC UI, navigate to the Notification Button (left of the Settings gear) > Health tab, where you can see a
health warning presented to the Administrator, which informs you about an EPS configuration that needs to be
dCloud: The Cisco Demo Cloud
replaced by ANC.

Task 3. Configure ANC instance and assign to Correlation Policy on FMC

2. In the FMC UI, navigate to Policies > Actions > Instances and review the existing configuration with an EPS
instance configured.

NOTE: The module’s name is “pxgrid-mitigation,” which is using PxGrid 1.0. Therefore, it needs adjustment to ANC,
which leverages PxGrid 2.0.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 137 of 173
 Cisco dCloud

3. To add a New Instance, Select module type “PxGrid Adaptive Network Control (ANC) Policy Assignment (v1.0)”

Click Add dCloud: The Cisco Demo Cloud

Provide Instance Name “quarantine_anc_instance”
Select Create
Under Configured Remediations, add a new remediation of type “ANC Policy for Source” – click Add
Add Remediation Name “quarantine_source_anc”
Select ANC Policy “quarantine_anc_policy”
Click “Create” and subsequently “Save”
Click the Done button to finish the configuration. Then return to the previous Instance creation page, where you will find
the newly configured remediations in this instance.

4. Navigate to Policies > Correlation > Policy Management

Edit existing “CorrelationPolicy – Malware Detection” using the Pencil button

In the section under Policy Rules, select the Responses button

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 138 of 173
 Cisco dCloud

Change Assigned Responses from “pxgrid1_quarantine” to “quarantine_source_anc” using the arrows.

Click on the Update button

dCloud: The Cisco Demo Cloud

Save the changes

5. Notice that the ISE Connection Health Monitor is enabled in this release by default. To review the settings,
navigate in FMC UI to System > Health > Policy > Then Edit Health Policy named “Initial_Health_Policy” – using
the pencil.

On the left panel, select “ISE Connection Status Monitor”

Review that the Enabled radio button is marked On – then exit.

NOTE: Now that we have reconfigured the EPS module to ANC, the health monitoring alert should disappear.

To review, navigate to System > Health > Monitor, select FMC device and ensure that the Health Module with the
name “ISE Connection Status Monitor” shows a healthy/green state. If it is not green, rerun the health module
(scroll to the far right of the Alert Detail window) as it updates every 5 minutes. If the Health Monitor is still showing
an error, it may be necessary to disable and re-enable the correlation policy (Policies > Correlation >
Disable/Enable Slide Button).

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 139 of 173
 Cisco dCloud

Task 4. Testing the Configuration

1. On the Jumphost PC, navigate to Desktop > RADIUS Simulator folder and run the following two scripts and let
them run in the background:
dCloud: The Cisco Demo Cloud

RadiusListener
StartSessions

2. From the Jumphost desktop, open the Remote Desktops folder and launch the Wkst1 shortcut (machine with IP
address 198.19.12.21 and admin/C1sco12345 credentials).

3. From the Wkst1 Desktop, find the Users folder, open it, choose the NGFW1 is your gateway folder, and
subsequently run the script Dilbert (Engineering). This simulates a user logging into the Network.

4. From the Wkst1 Desktop, open a Firefox browser, which should immediately launch the outside web server
(198.18.133.200) web page. In the web server, navigate to the Files hyperlink and attempt to download the
malware file Zombies.pdf. The connection should reset as this action has triggered a malware event that FTD
caught. You can confirm that FTD has blocked this connection in FMC UI under Analysis > Malware Events:

NOTE: This network activity should also trigger a correlation event and quarantine the host. To ensure that the FMC
triggered quarantine to ISE successfully, navigate to FMC UI Analysis > Correlation > Status.

5. From the ISE perspective, we can review that the PC of Dilbert is quarantined, to check this navigate to:
Operations > Adaptive Network Control > Endpoint Assignment in the ISE UI.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 140 of 173
 Cisco dCloud

Scenario 14 - Software Upgrade Enhancements on FMC

dCloud: The Cisco Demo Cloud

Introduction
The Firepower software Version 6.7 introduces several enhancements regarding upgrade functionality on
a Firepower Management Center (FMC). For example, readiness check, upgrade time estimation,
upgrade status check, viewing detail upgrade log, upgrade cancelation, etc.
This exercise highlights these enhancements by going through a complete upgrade process. As part of
this exercise, an FMC is used to update an FTD from Version 6.6 to Version 6.7.

Prerequisites
Before beginning an upgrade, you should review the following items to sure a successful upgrade:
The upgrade file is downloaded from the Cisco software download site. The file to upgrade an FTD to software Version
6.7 is Cisco_FTD_Upgrade-6.7.0-XX.sh.REL.tar, where XX is the software build number.
Upgrade packages are with sh.REL.tar extension. They are signed tar archives (.tar). Do not untar an upgrade file.
Complete any other update processes or scheduled tasks before running an upgrade.

Task 1. Software Upgrade

To upgrade your FMC to software version 6.7, follow the steps below:

1. Login to the GUI of the FMC.

2. Under the Settings section, select Updates. The Updates page appears. By default, the Product Updates tab is
displayed.

3. On the Products Update page, click the Upload Update button, then browse your local filesystem to select the
upgrade package.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 141 of 173
 Cisco dCloud

4. Select the Upload button to begin the file upload.

dCloud: The Cisco Demo Cloud

5. Once the software upgrade file is uploaded, it appears under the Available Updates tab. Click the Push or Stage
update icon next to the desired upgrade package.

6. At this stage, device readiness can be checked before installing the package on it. Choose a destination device
and select the Check Readiness button. When the system prompts to confirm, click OK to continue the
readiness check.

7. Once the readiness check is complete and successful, the Success status should appear.

NOTE: The Automatically cancel or upgrade failure and roll back to the previous version option.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 142 of 173
 Cisco dCloud

8. Now, let’s begin the upgrade. Click on the Install button to start the installation of the upgrade package on the
desired FTD device.
dCloud: The Cisco Demo Cloud

9. Software Version 6.7 introduces a new feature where an FMC user can view the upgrade status and detail logs
directly from the GUI. To view the upgrade status, go to the Devices > Device Management page and select the
Upgrade tab. The current upgrade status is shown under the Upgrade Status column.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 143 of 173
 Cisco dCloud

10. Click the In Progress (..%) link. It opens a popup window. This window displays an overall picture of the
upgrade, including the remaining time to complete the upgrade.

dCloud: The Cisco Demo Cloud

11. On the popup window, expand the Log Details section. It shows the name of the current script that is being
executed during the upgrade process.

NOTE: The Cancel Upgrade button allows an administrator to cancel the upgrade process.

12. Once the upgrade is complete, the Completed status appears.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 144 of 173
 Cisco dCloud

Scenario 15 - FMC High Availability

dCloud: The Cisco Demo Cloud

Objectives
To configure, administer and test FMC HA

Roles Versus Status

Primary/Secondary Roles
When setting up Firepower Management Centers in a high availability pair, you configure one Firepower
Management Center to be primary and the other as secondary. During configuration, the primary unit’s
policies are synchronized to the secondary unit. After synchronization, the primary Firepower
Management Center becomes the active peer, while the secondary Firepower Management Center
becomes the standby peer, and the two units act as a single appliance for managed device and policy
configuration.

Active/Standby Status
The main difference between the two Firepower Management Centers in a high availability pair are which
peer is active and which peer is standby. The active Firepower Management Center remains fully
functional, where you can manage devices and policies. On the standby Firepower Management Center,
functionality is hidden; you cannot make any configuration changes.

Event Processing on Firepower Management Center High Availability Pairs

Since both Firepower Management Centers in a high availability pair receive events from managed
devices, the management IP addresses for the appliances are not shared. This means that you do not
need to intervene to ensure continuous processing of events if a Firepower Management Center fails.

Task 1. Confirm Software Prerequisites for FMC HA

The following are the documented software requirements.

The two Firepower Management Centers in a high availability configuration must have the same major (first number),
minor (second number), and maintenance (third number) software version.
In a high availability configuration, the two Firepower Management Centers must have the same version of the intrusion
rule update installed.
In a high availability configuration, the two Firepower Management Centers must have the same version of the
vulnerability database update installed.

It is also recommended that the geolocation database is at the same version.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 145 of 173
 Cisco dCloud

In this task, you will confirm these prerequisites.

1. Open two browser tabs. In one, log into the FMC. In the other, log into FMC2. Use the shortcuts on the
browser bookmarks bar. The credentials will prepopulate. dCloud: The Cisco Demo Cloud

2. Click on the question mark in the upper right of the UI and select “About.” The versions in your pod may differ
from the versions in the following figure

3. Confirm that the following three versions agree between FMC and FMC2.

The same major (first number), minor (second number), and maintenance (third number) software version
The intrusion rule update version
The geolocation update version
The vulnerability database version

NOTE: If you need to upgrade any of these, click on the gear in the UI’s upper right corner and select Updates.

• For the software version, select the Product Updates tab.

• For the intrusion rule update version, select the Rule Updates tab.

• For the geolocation update version, select the Geolocation Updates tab.

• For the vulnerability database version, select the Product Updates tab.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 146 of 173
 Cisco dCloud

Task 2. Disable PLR on FMC2

Currently, both FMC and FMC2 have permanent license reservations (PLR). You cannot form an HA pair
between two FMCs with PLR enabled. The HA pair can only consume one PLR license.dCloud: The Cisco Demo Cloud

1. In the FMC2 UI, click on the gear icon in the upper right corner and select Universal Licenses

2. On the resulting page, click on the red circle.

3. Click Yes. As soon as you do this, FMC2 will no longer be licensed.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 147 of 173
 Cisco dCloud

4. Scroll down to the bottom of the page and note the return code.

dCloud: The Cisco Demo Cloud

NOTE: If this were an actual deployment, you would save this return code. You need this code to delete the device
from your smart license account. This would retrieve the PLR entitlement, which you could then apply to another
device.

5. Open PuTTY on the jump box desktop. Double click on the predefined PuTTY session called FMC-2.

Log in as admin, password C1sco12345.

Type expert and then type the following:
sudo /var/sf/bin/manage_plr.pl
When prompted for a password, enter C1sco12345.
Enter 3 to disable PLR.
Enter 0 to exit the wizard.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 148 of 173
 Cisco dCloud

Task 3. Configure FMC2 as the Secondary FMC

1. Refresh the FMC2 UI page.
dCloud: The Cisco Demo Cloud

2. In the FMC2 UI, click on the gear icon in the upper right corner and select Integration.

3. Select the High Availability sub-tab.

Select the Secondary radio button

For Primary FMC Host, enter fmc.dcloud.local.
For Registration Key, enter C1sco12345.
Click Register. Click Yes on the two warning dialog boxes.

NOTE: That the high availability FMC page now says Pending Registration.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 149 of 173
 Cisco dCloud

Task 4. Configure FMC as the Primary FMC

1. In the FMC UI, click on the gear icon in the upper right corner and select Integration.
dCloud: The Cisco Demo Cloud

2. Select the High Availability sub-tab.

Select the Primary radio button
For Secondary FMC Host, enter fmc2.dcloud.local.
For Registration Key, enter C1sco12345.
Click Register. Click Yes on the two warning dialog boxes.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 150 of 173
 Cisco dCloud

Task 5. Confirm the FMC HA Configuration

1. The HA configuration takes 5 to 10 minutes to complete. During this time, observe the changes to the high
availability pages. At certain points, you will not be able to load this page. Don’t worry about warnings such as
dCloud: The Cisco Demo Cloud
synchronization failure and the number of registered devices not matching. These messages should eventually
go away.
2. Wait until the Task tab on both FMCs says the task is complete.

3. In the High Availability sub-tab on each FMC, confirm that the Status is Healthy and the Synchronization is OK.
You may have to navigate away and back to this page for it to update.

4. Navigate the FMC2 UI and confirm that the secondary has very little functionality available.
Navigate to Devices. Confirm that you can view but not configure the managed devices.

NOTE: There is no Analysis tab. Therefore, you cannot view events. However, events are being sent to both FMCs.
Click on the gear icon in the upper right corner and select Integration. Note that three sub-tabs are missing: Realms,
Realm Sequences, and Identity Sources.

5. Open PuTTY on the jump box desktop. Double click on the predefined PuTTY session called NGFW1.
Log in as admin, password C1sco12345.
Type show managers and confirm that both FMC and FMC2 are listed as managers.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 151 of 173
 Cisco dCloud

Task 6. Switch the role of the two FMCs

1. In the High Availability sub-tab on FMC2, click Switch Peer Roles. Click Yes and then OK when prompted.
dCloud: The Cisco Demo Cloud

NOTE: You can also switch roles from the primary FMC. However, this is done more often from the secondary
because of failure of the primary FMC

2. Wait a couple of minutes for the page to become available again

.
3. Confirm that FMC2 now has full functionality, including viewing events, editing devices, and modifying realm
and identity source integrations.

4. Confirm that FMC is no longer the active unit by observing the limit in functionality.

Task 7. Break FMC HA

1. In the High Availability sub-tab on FMC2, click Break HA. Select Yes when asked to confirm the break.

NOTE: You can also switch roles from the primary FMC.

2. Select Manage registered devices from peer console radio button.

3. Wait a few minutes and confirm that two standalone FMCs have replaced the HA pair.

NOTE: The database on FMC2 will not be purged, so you will still see events and data in the dashboard. But if you
navigate to Device, you will find that FMC2 is no longer managing devices.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 152 of 173
 Cisco dCloud

Scenario 16 - VRF Support in the FMC

VRF support was added in Firepower 6.6. In this scenario, the FMC is used to configure multiple VRFs.
dCloud: The Cisco Demo Cloud
The objectives of this scenario are:
• Create VRFs using the FMC
• Configure dynamic routing in VRFs
• Configure route leaking between VRFs
Once the configuration is done, it will correspond to the following diagram. At the end of this scenario, you will also
add a leaked route between VRF A and VRF B.

All routers have 11.11.6x.1 loopback address. The 11.11.6x.0/24 network simulates remote networks.
All routers are running both OSPF and BGP, and are connected to multiple VLANs, in case you wish to go beyond
the exercises in this lab.

NOTE: Chrome loads pages faster than Firefox (particularly for the FMC). However, Chrome will generate more
security warnings and doesn’t cache credentials for NGFW2 and NGFW3. Either or both browsers can be used.
In Chrome, the bookmarks where imported from Firefox, so they are in a subfolder on the bookmark bar, as shown
below.

Choose between Chrome and Firefox based on your own preferences.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 153 of 173
 Cisco dCloud

Create user defined VRFs

1. Before creating VRFs, confirm connectivity between the inside and outside of NGFW1.
dCloud: The Cisco Demo Cloud
a. The ACP for NGFW1 allows outbound connections. On the Jumpbox, open the predefined PuTTY
session to the Inside Linux Server. Log in as root, password C1sco12345. Type wget outside to
confirm outbound connectivity.
b. The ACP for NGFW1 allows inbound connections to an internal server using static NAT. On the
Jumpbox, open the predefined PuTTY session to the Outside Linux Server. Log in as root, password
C1sco12345. Type wget wwwout to confirm inside to outside connectivity.
2. Leave these PuTTY sessions open.
3. Open Firefox. The FMC UI is the home page and the credentials (admin/C1sco12345) auto-populate. Log in to
the FMC and navigate to Devices > Device Management. Edit the device NGFW1.
4. Notice there are four inside interfaces: in10, in20, in30, and in40. You will use these to create two user defined
VRFs.
5. Click the Routing sub-tab. Click Manage Virtual Routers. Observe that there is, by default, a global VRF
containing all the interfaces.
6. Click + Add Virtual Router.
a. Name the VRF vrfA. Click OK.
b. Add the interfaces in10 and in20 to this VRF.

7. You do not have to click Save.

8. Click Manage Virtual Routers. Click + Add Virtual Router.
a. Name the VRF vrfB. Click OK.
b. Add the interfaces in30 and in40 to this VRF.
9. Click Save.
10. Deploy the changes and note the warnings but deploy anyway. Wait for the deployment to complete.

11. Since the interfaces in10 and outside are now in different VRFs, confirm the connectivity between the inside
and outside of NGFW1 is broken.
a. In the PuTTY session to the Inside Linux Server, type wget outside. This should fail, because vrfA is
missing a route to the outside and there is no destination NAT involved.
b. In the PuTTY session to the Outside Linux Server, type wget wwwout. This should succeed, because
of the destination NAT.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 154 of 173
 Cisco dCloud

Configure route leaking

1. In the FMC, navigate to Devices > Device Management. Edit the device NGFW1. Click the Routing sub-tab.
dCloud: The Cisco Demo Cloud
2. In the global VRF, select Static Route and note that the global VRF has two static routes: a default route and a
more specific route to the network 11.11.60.0/24.
3. Select vrfA from the drop-down list. Select Static Route.
4. Click Add Route.
a. Select outside ( Global ) from the Interface drop-down list. The word Global indicates the VRF the
route is leaked from.
b. Select any-ipv4 from the Available Network list. Click Add to add the network to the Selected Network
list.
c. Leave the Gateway field blank. You cannot specify a gateway for a leaked route.

d. Click OK.

5. Click Save.
6. Deploy the changes. The same warnings appear. Wait for the deployment to complete.
7. Confirm connectivity between the inside and outside of NGFW1 has be restored.
a. In the PuTTY session to the Inside Linux Server, type wget outside. This should now succeed.
b. In the PuTTY session to the Outside Linux Server, type wget wwwout. This should still succeed.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 155 of 173
 Cisco dCloud

8. In the PuTTY session to the Inside Linux Server, type ping 11.11.60.1 to confirm connectivity to the
11.11.60.0/24 network from vrfA.
dCloud: The Cisco Demo Cloud
NOTE: You did not have to leak the static route to 11.11.60.0/24 from the global VRF to vrfA. You just created a
default route. The default route in vrfA now forwards the 11.11.60.0/24 traffic to the outside interface in the global
VRF. The correct static route will then be applied in the global VRF.
Also, you did not have to leak return routes from vrfA to the global VRF. This is explored in more depth during
the task Explore the relationship between inspection state and routing below.

9. On the Jumpbox, open the predefined PuTTY session to the NGFW1. Log in as admin, password C1sco12345
a. Type show vrf and confirm the interface assignments to the user defined VRFs are correct.
b. Type show route and observe the connected and static routes of the global VRF.

c. Type show route vrf vrfA and observe the connected and static routes of vrfA. Note that the default
route does not have a gateway, but instead says directly connected, outside. The SI stands for static
interVRF (that is leaked) route.

Configure OSPF on vrfA

1. In the FMC, navigate to Devices > Device Management. Edit the device NGFW1. Click the Routing sub-tab.
2. Select vrfA from the drop-down list. Under Manage Virtual Routers select OSPF.
3. Click on the Process 1 checkbox. Notice that the process id is set to 3 and cannot be changed.

NOTE: There is a maximum of 2 OSPF processes per VRF. Process IDs 1 and 2 are reserved for the global VRF.
Process IDs 3 and 4 are reserved for the first user defined VRF that enables OSPF. Process IDs 5 and 6 are
reserved for the second user defined VRF that enables OSPF, and so on.

4. The Area sub-tab should be selected. Click + Add.

a. Set the Area ID to 0.
b. Select 198.19.0.0-16 in Available Networks and click Add to add the network to the Selected Network
list.
c. Click OK.

NOTE: Increasing the cost of the OSPF interfaces ensures that NGFW2 takes precedence when you add it to the
OSPF configuration in the next scenario.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 156 of 173
 Cisco dCloud

5. Click the Interface sub-tab. Click + Add.

a. Select in10 from the Interface drop-down list.
dCloud: The Cisco Demo Cloud
b. Change the Default Cost to 100.
c. Click OK.
6. Click + Add.
a. Select in20 from the Interface drop-down list.
b. Change the Default Cost to 100.
c. Click OK.
7. Do not save or deploy the changes. You will save and deploy these changes after you configure BGP on vrfB.

Configure BGP on vrfB

NOTE: All VRFs share a single BGP process. Each VRF is an address family within that process. That is why there
are global settings (called General Settings in the FMC) and per-VRF settings.

1. Under General Settings select BGP.

2. Check the Enable BGP checkbox. Set the AS Number to 1.
3. Select vrfB from the drop-down list.
4. Under Manage Virtual Routers select BGP. Note that you cannot uncheck the checkbox or change the AS
number.
5. Under Manage Virtual Routers select BGP > IPv4.
6. Check the Enable IPv4 checkbox.
7. Select the Neighbor sub-tab. Click + Add.
a. Set the IP Address to 198.19.30.63. For Remote AS, enter 63. Check the Enable address checkbox.
b. Under Outgoing, to the right of the Route Map drop-down list, click +.

NOTE: Now create a route map to prepend the AS list to ensure that NGFW2 takes precedence when you add it to
the BGP configuration in the next scenario.

c. For Name, enter BGPRouteMap.

d. Click Add.
e. For Sequence No enter 10.
f. Click the Set Clauses tab. There are no match clauses. Select BGP Clauses. Set Prepend AS Path to 1.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 157 of 173
 Cisco dCloud

dCloud: The Cisco Demo Cloud

g. Click Add to add the route map entry. Click Save to save the route map.
h. Under Outgoing, select BGPRouteMap from the Route Map drop-down list. Click OK.

8. Click + Add to add another neighbor.

a. Set the IP Address to 198.19.40.64. For Remote AS, enter 64. Check the Enable address checkbox.

b. Under Outgoing, select BGPRouteMap from the Route Map drop-down list. Click OK.
c. Click Save.

9. Deploy the changes. Wait for the deployment to complete.

Test dynamic routing

1. On the NGFW1 CLI, enter the following commands:

a. show ospf vrf vrfA neighbor – confirm that the adjacencies are fully established.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 158 of 173
 Cisco dCloud

b. show route vrf vrfA – confirm that there are OSPF E1 routes with metric 120.
dCloud: The Cisco Demo Cloud

c. show bgp vrf vrfB summary – confirm that 5 prefixes were receive from each neighbor.

d. show route vrf vrfB – confirm that there are BGP routes.

2. On the Jumpbox, open the predefined PuTTY session to the CSR61. Log in as admin, password C1sco12345.
a. Type show ip route ospf – confirm that there are OSPF E1 routes with metric 121 and NGFW1 as the
next hop.

b. Type ping 11.11.62.1 source 11.11.61.1. This should succeed.

3. Type show ip route ospf and ping 11.11.61.1 source 11.11.62.1 on CSR62. You should see similar results.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 159 of 173
 Cisco dCloud

4. On the Jumpbox, open the predefined PuTTY session to the CSR63. Log in as admin, password C1sco12345.
a. Type show ip route bgp – confirm that there are BGP routes, with NGFW1 as the next hop.
dCloud: The Cisco Demo Cloud

b. Type ping 11.11.64.1 source 11.11.63.1. This should succeed.

c. Type show ip bgp – confirm that the AS paths for routes from AS 64 contain two 1s.

5. Type show ip route bgp, show ip bgp and ping 11.11.63.1 source 11.11.64.1 on CSR64. You should see
similar results.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 160 of 173
 Cisco dCloud

Explore the relationship between inspection state and routing

Routing behaves differently on an NGFW (or an ASA) than on routers, because of inspection state. You will explore
dCloud: The Cisco Demo Cloud
this difference in this task by leaking routes between vrfA and vrfB. Note that there is no NAT or non-allow access
policy rules that apply to this traffic.

1. In the FMC, navigate to Devices > Device Management. Edit the device NGFW1. Click the Routing sub-tab.
2. Select vrfA from the drop-down list. Select Static Route.
3. Click Add Route.
a. Select in30 ( vrfB ) from the Interface drop-down list.
b. Select 11.11.63.0-24 in Available Networks and click Add to add the network to the Selected Network
list.
c. Leave the Gateway field blank. You cannot specify a gateway for a leaked route. Click OK.
4. Click Save.
5. Deploy the changes and wait for the deployment to complete.
6. In the PuTTY session to CSR63, type ping 11.11.61.1 source 11.11.63.1. This should fail. There is no route in
vrfB to direct the echo request to vrfA.
7. In the PuTTY session to CSR61, type ping 11.11.63.1 source 11.11.61.1. This should succeed, even though
that there is no route in vrfB to direct the echo response back to vrfA. The NGFW relies on ICMP inspection to
determine how to route the echo response.
8. On the NGFW1 CLI, type the command configure inspection icmp disable to make the NGFW route the echo
request and echo response independently.
9. Confirm that the both pings tried above now fail. This is because there are not routes in both directions, and
there is not ICMP inspection to facilitate the routing.
10. Now add the reverse route. In the FMC, navigate to Devices > Device Management. Edit the device NGFW1.
Click the Routing sub-tab
11. Select vrfB from the drop-down list. Select Static Route.

12. Click Add Route.

a. Select in10 ( vrfA ) from the Interface drop-down list.

b. Select 11.11.61.0-24 in Available Networks and click Add to add to the Selected Network list.
c. Leave the Gateway field blank. You cannot specify a gateway for a leaked route. Click OK.
13. Click Save. Deploy the changes and wait for the deployment to complete.

14. Confirm that the both pings tried above now succeed.

15. On the NGFW1 CLI, type the command configure inspection icmp enable to restore the NGFW1 inspection
configuration.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 161 of 173
 Cisco dCloud

Scenario 17 - VRF Support in the FDM

The objectives of this scenario are:
dCloud: The Cisco Demo Cloud
• Create VRFs using the FDM
• Configure route leaking between VRFs
• Configure Dynamic routing in VRFs
• This Scenario is essentially an abbreviated version of Scenario 1, performed on the FDM instead of the FMC.

Create user defined VRFs

1. On the Jumpbox, in Firefox, open a new tab. Click on the NGFW2 (FDM) bookmark. The credentials (login
admin, password C1sco12345) auto-populate.
2. Log into the FDM. Under Interfaces click View All Interfaces.
3. Observe the four inside interfaces: in10, in20, in30, in40. These are used to create two user defined VRFs.
4. Return to the Device page. Under Routing click View Configuration.
5. Click down arrow to the right of the text Add Multiple Virtual Routers.
a. Click CREATE FIRST CUSTOM VIRTUAL ROUTER.
b. For Name, enter vrfA. Add in10 and in20 to vrfA. Click OK twice.

6. You will be sent to the Virtual Routers page.

a. Click + to add another VRF.

b. For Name, enter vrfB. Add in30 and in40 to vrfB. Click OK twice.
7. Do not deploy these changes. Move on to the next task.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 162 of 173
 Cisco dCloud

Configure route leaking

1. To edit vrfA, mouse over the area to the right of vfrA and click on the blue eye icon when it appears.
dCloud: The Cisco Demo Cloud

2. Click CREATE STATIC ROUTE.

a. Give the object any reasonable name.
b. Select outside (GigabitEthenet0/0) from the Interface drop-down list. Read the warning about the
leaked route.
c. For Networks add any-pv4.
d. Leave the Gateway field blank. You cannot specify a gateway for a leaked route.

e. Click OK twice,
3. Do not deploy these changes. Move on to the next task.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 163 of 173
 Cisco dCloud

Configure OSPF on vrfA

1. Select the OSPF sub-tab.

dCloud: The Cisco Demo Cloud
2. Click CREATE OSPF OBJECT and select OSFP. This is the Smart CLI interface. Give the object any reasonable
name.
3. Click on Show disabled.
4. Create the configuration shown below. To enable and edit certain lines, click the + on the left.

5. Click OK.
6. Do not deploy these changes. Move on to the next task.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 164 of 173
 Cisco dCloud

Configure BGP on vrfB

1. Select vrfB from the drop-down list. Select the BGP sub-tab.
dCloud: The Cisco Demo Cloud
2. Click CREATE BGP OBJECT. Give the object any reasonable name.
3. Click on Show disabled.
4. Create the configuration shown below. To enable and edit certain lines, click the + on the left.

NOTE: To create the second neighbor, you will have to duplicate the configure neighbor line.

5. Click OK.
6. Deploy the changes. Wait for the deployment to complete.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 165 of 173
 Cisco dCloud

Test dynamic routing

1. On the Jumpbox, open the predefined PuTTY session to the NGFW2. Log in as admin, password C1sco12345.
dCloud: The Cisco Demo Cloud
2. On the NGFW2 CLI, enter the following commands.
a. show vrf – confirm that the interface assignments to the user defined VRFs are correct
b. show ospf vrf vrfA neighbor – confirm that the adjacencies with the CSRs and NGFW1 are fully
established.

c. show route vrf vrfA -- observe the connected and static routes of vrfA. Note that the default route does
not have a gateway, and says directly connected, outside. Confirm that there are OSPF E1 routes with
metric 30.

d. show bgp vrf vrfB summary – confirm that 5 prefixes were receive from each neighbor.

e. show route vrf vrfB – confirm that there are BGP routes.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 166 of 173
 Cisco dCloud

3. In the PuTTY session to the CSR61 (Login admin, password C1sco12345).

a. Type show ip route ospf – confirm that there are OSPF E1 routes with metric 31 and NGFW2 as the
next hop. dCloud: The Cisco Demo Cloud

b. Type ping 11.11.62.1 source 11.11.61.1. This should succeed.

4. Type show ip route ospf and ping 11.11.61.1 source 11.11.62.1 on CSR62. You should see similar results.
5. On the Jumpbox, open the predefined PuTTY session to the CSR63 (Login admin, password C1sco12345).
a. Type show ip route bgp – confirm that there are BGP routes, with NGFW2 as the next hop.

b. Type ping 11.11.64.1 source 11.11.63.1. This should succeed.

c. Type show ip bgp – show the optimal path through NGFW2 and suboptimal path through NGFW1.

6. Type show ip route bgp, show ip bgp and ping 11.11.63.1 source 11.11.64.1 on CSR64. You should see
similar results.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 167 of 173
 Cisco dCloud

Scenario 18 - Explore Redistribution of Leaked Routes

Now that you have a rich routing environment, you can perform interesting configurations. This task suggests one
dCloud: The Cisco Demo Cloud
such configuration. The objectives of this scenario are:
• Redistribute leaked routes into OSPF and BGP on NGFW1.
• Confirm that NGFW2 receives the routes. This is confirmed by seeing two routes on NGFW2.
• Route from NGFW2 vfrA to 11.11.63.1 (CSR63) with next hop in NGFW1 vfrA
• Route from NGFW2 vfrB to 11.11.61.1 (CSR61) with next hop in NGFW1 vfrB

Perform preliminary configuration and testing

1. Configure CSR61 and CSR63 to route the return traffic.

a. Configure route from CSR61 to 198.19.30.2 (NGFW2 vrfB) with next hop 198.19.10.1 (NGFW1 vrfA).
For simplicity, just create a default route: ip route 0.0.0.0 0.0.0.0 198.19.10.1 on CSR61.
b. Configure route from CSR63 to 198.19.10.2 (NGFW2 vrfA) with next hop 198.19.30.1 (NGFW1 vrfB).
For simplicity, just create a default route: ip route 0.0.0.0 0.0.0.0 198.19.30.1 on CSR63.

2. Confirm that desired connectivity is not available. On the NGFW2 CLI, type the following commands.
a. show route vrf vrfA – confirm that there is no route to 11.11.63.1 (except the default route).
b. ping vrf vrfA 11.11.63.1 – confirm that the ping fails.
c. show route vrf vrfB – confirm that there is no route to 11.11.61.1.
d. ping vrf vrfB 11.11.61.1 – confirm that the ping fails.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 168 of 173
 Cisco dCloud

Redistribute leaked routes on NGFW1

1. In the FMC, navigate to Devices > Device Management. Edit the device NGFW1. Click the Routing sub-tab.
dCloud: The Cisco Demo Cloud
2. Select vrfA from the drop-down list. Under Manage Virtual Routers select OSPF.
a. Select ASBR from the OSPF Role drop-down list.
b. Select the Redistribution sub-tab and click + Add.
c. Select Static from the Route Type drop-down list. Check the Use Subnets checkbox. Leave the other
fields set to their defaults. Click OK.

3. Select vrfB from the drop-down list. Under Manage Virtual Routers select BGP > IPv4.
a. Select the Redistribution sub-tab and click + Add.
b. Select Static from the Source Protocol drop-down list. Leave the other fields set to their defaults. Click
OK.

4. Save and deploy the changes. Wait for the deployment to complete.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 169 of 173
 Cisco dCloud

Test route distribution on NGFW2

1. Confirm that desired connectivity is available. On the NGFW2 CLI, type the following commands.
dCloud: The Cisco Demo Cloud
a. show route vrf vrfA – confirm that there is an OSPF route to 11.11.63.1 with next hop in NGFW1 vrfA.
b. ping vrf vrfA 11.11.63.1 – confirm that the ping succeeds.
c. show route vrf vrfB – confirm that there is a BGP route to 11.11.61.1 with next hop in NGFW1 vrfB.
d. ping vrf vrfB 11.11.61.1 – confirm that the ping succeeds.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 170 of 173
 Cisco dCloud

Scenario 19 - Time Based Policy in the FMC

Firepower 6.6 introduces time-based access control, prefilter policy rules. Note that time-ranges were already
dCloud: The Cisco Demo Cloud
available before 6.6 for VPN group policies.
The objectives of this scenario are the following for devices managed by an FMC.
• Create time zone and time range objects.
• Deploy a time zone object to NGFW1.
• Create time-based access control policy rules.
• Create time-based prefilter rules.
• Deploy and test the policy configuration.

Create time-zone and time-range objects

1. In the FMC, navigate to Object > Object Management.

2. Select Time Zone from the left navigation pane. Click Add Time Zone. Create a time zone object using a
convenient time zone, for example, the time zone you are in. Click Save.
3. Select Time Range from the left navigation pane. Click Add Time Range. Create a time range object called Past
that ends sometime in the past. Click Save.
4. Click Add Time Range. Create a time range object called Present that includes the current time and the next
hour or more. Click Save.
5. Click Add Time Range. Create a time range object called Future that does not start for at least an hour. Click
Save.

Edit the platform settings for NGFW1

1. Navigate to Devices > Platform Settings. Edit NGFW1_Platform_Settings.

2. Select Time Zone from the left navigation pane. From the Time Zone drop-down list, select the time zone
object you created. Click Save.

Edit the prefilter policy

1. Navigate to Policies > Prefilter. Edit the Demo Prefilter Policy.

2. Click Add Prefilter Rule. Placement of the rule in the policy table is not relevant.
a. For Name, enter Block201.
b. For the Action, select Block.

c. Select Present from the Time Range drop-down list.

d. Select the Interface Objects sub-tab.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 171 of 173
 Cisco dCloud

i. Select OutZone and add it to the Source Interface Objects.

ii. Select InGroup10 and add it to the Destination Interface Objects.
dCloud: The Cisco Demo Cloud
e. Select the Networks sub-tab.
i. Under the Source Network box, enter 198.18.133.201 and click Add.
ii. Select wwwin and add it to the Destination Networks. Note that wwwin is the un-NATed
destination.
f. Select the Logging sub-tab. Check the Log at Beginning of Session check box.
g. Click Add to add the new prefilter rule.
3. Click Add Prefilter Rule. Placement of the rule in the policy table is not relevant.
a. For Name, enter Block202.
b. For the Action, select Block.
c. Select Future from the Time Range drop-down list.
d. Select the Interface Objects sub-tab.
i. Select OutZone and add it to the Source Interface Objects.
ii. Select InGroup10 and add it to the Destination Interface Objects.
e. Select the Networks sub-tab.
i. Under the Source Network box, enter 198.18.133.202 and click Add.

ii. Select wwwin and add it to the Destination Networks.

f. Select the Logging sub-tab. Check the Log at Beginning of Session check box.
g. Click Add to add the new prefilter rule.
4. Click Save to save the changes to the prefilter policy.

Edit the access control policy

1. Navigate to Policies > Access Control. Edit the Base_Policy.

2. Edit the 6th rule called Web Server Access. Select the Ports sub-tab and add
a. Change the Name to Web Server Access HTTPS.
b. Select Past from the Time Range drop-down list.
c. Select the Ports sub-tab and add HTTPS to the Destination Ports list.
d. Click Save to save the changes to the rule.
3. Add a new rule.
a. For Name, enter Web Server Access HTTP.

b. Select below rule from the Insert drop-down list and enter 6.

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 172 of 173
 Cisco dCloud

c. For the Action, select Allow.

d. Select Present from the Time Range drop-down list.
dCloud: The Cisco Demo Cloud
e. Select the Zones sub-tab.
i. Select OutZone and add it to the Source Zones.
ii. Select InZone and add it to the Destination Zones.
f. Select the Networks sub-tab. Select wwwin and add it to the Destination Networks.
g. Select the Ports sub-tab and add HTTP to the Destination Ports list.
h. Select the Inspection sub-tab.
i. Select Demo Intrusion Policy from the Intrusion Policy drop-down list.
ii. Select Demo File Policy from the File Policy drop-down list.
i. Select the Logging sub-tab.
i. Check the Log at Beginning of Connection check box.
ii. Check the Log at End of Connection check box.
j. Click Add to add the new access control rule.
4. Click Save to save the changes to the prefilter policy.

Deploy and test the policy configuration

1. Deploy the changes. Wait for the deployment to complete.

2. In the PuTTY session to NGFW1, type the following commands into the CLI.
a. show time-range timezone – observe that the time zone you configured is being used.
b. show time-range – observe that only Present and Future are used in ACLs in the data plane. These are
the time ranges used in the prefilter policy rules.
3. In the Outside Linux Server PuTTY session, rule the following commands.
a. wget --bind-address=198.18.133.201 wwwout
Observe that this connection hangs because the prefilter rule Block201 is active.
b. wget --bind-address=198.18.133.202 wwwout
Observe that this connection is not blocked because the rule Block202 is not active.
c. wget --no-check-certificate https://wwwout
Observe that this connection hangs because the rule Web Server Access HTTPS is not active.
d. wget wwwout
Observe that this connection is allowed because the rule Web Server Access HTTP is active

© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 173 of 173