Firepower NGFW Labpdf PDF

Cisco dCloud
Cisco Firepower Next-Generation Firewall 6.2 Advanced

Lab v2
Last Updated: 10-APRIL-2018
About This Demonstration

This guide for this preconfigured demonstration includes:
• Requirements
• About This Solution
• Topology
• Get Started
• Scenario 1: Integrated Routing and Bridging (IRB)
• Scenario 2: High Availability Configuration
• Scenario 3: AnyConnect Remote Access VPN
• Scenario 4: AnyConnect with RADIUS Attributes
• Scenario 5: Site-to-Site VPN
• Scenario 6: Monitoring and Troubleshooting
• Scenario 7: Cisco Threat Intelligence Director (CTID)
• Scenario 8: ASA to NGFW Migration (Optional)
• Scenario 9: ASA to NGFW Migration (Optional)
• Appendix A: FMC Pre-configuration
• Appendix B: REST API Scripts
• Appendix C: ISE RA VPN Configuration
Requirements
The table below outlines the requirements for this preconfigured demonstration.
Table 1. Requirements
Required Optional
● Laptop ● Cisco AnyConnect®
© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 119
Cisco dCloud
About This Solution

IT teams have been asked to manage security using a patchwork of siloed point products, starting with legacy next-generation
firewalls (NGFW), which were created with a focus on application and bolted on best effort threat protection. As such, these legacy
NGFWs are unable to provide an enterprise with the contextual information, automation, and prioritization that they need to handle
today's modern threats.
Cisco Firepower is an integrated suite of network security and traffic management products, deployed either on purpose-built
platforms or as a software solution. The system is designed to help you handle network traffic in a way that complies with your
organization’s security policy-your guidelines for protecting your network.
This allows the Cisco Firepower NGFW to evolve with a focus on enabling enterprises to stop, prioritize, understand, and automate
responses to modern threats in real-time. Firepower NGFW is unique in its threat-focus, with a foundation of comprehensive
network visibility, best-of-breed threat intelligence and highly-effective threat prevention to address both known and unknown
threats. Firepower NGFW also enables retrospective security, through Advanced Malware Protection, that can “go back in time” to
quickly find and remediate sophisticated attacks that may have slipped through defenses. This has led to a significant reduction in
time-to-detection (TTD) for Cisco customers compared to industry averages.
In this lab you will build a multi-site network Next Generation Firewall (NGFW) solution at between a corporate and two branch
sites. Using the Firepower Management Console (FMC) you will build High Availability NGFWs at the corporate site, and manage
a branch. In this lab you will also configure a NGFW using the FDM (Firepower Device Manager). You will also configure remote
access and site to site VPNs. You will also configure Cisco Threat Intelligence Director to accept and implement third party
updates to your NGFW devices.
Cisco dCloud
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 session and in the
scenario steps that require their use.
Figure 1. dCloud Topology
Cisco dCloud
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. For best performance, connect to the workstation with Cisco AnyConnect VPN [Show Me How] and the local RDP client on
your laptop [Show Me How]
• Workstation 1: 198.18.133.36, Username: administrator, Password: C1sco12345
NOTE: You can also connect to the workstation using the Cisco dCloud Remote Desktop client [Show Me How]. The dCloud
Remote Desktop client works best for accessing an active session with minimal interaction. However, many users experience
connection and performance issues with this method.
Cisco dCloud
Scenario 1. Integrated Routing and Bridging (IRB)

This exercise consists of the following tasks.
• Create the objects needed for this lab exercise
• Modify the NGFW interface configuration
• Modify the NAT policy
• Modify the access control policy
• Deploy and test the configuration
In the lab, there is a Linux server on separate VLAN that is connected to GigabitEthernet0/2. The FQDN for this server
isolated.dcloud.local, and it has the IP address of 198.19.10.220/24. Note that this is address is in the same subnet as the inside
network.
The objective is to join these VLANs using a bridge-group on the NGFW. Traffic between these VLANs will be inspected.
NOTE: In this exercise, both interfaces in the bridge group are put in the same security zone. However this is not required. A
bridge group can contain interfaces in different security zones. This allows more granular control of traffic between interfaces in the
same bridge group.
Steps
Create the Object
Create the object needed for this lab exercise:
1. Open Firefox and open the Firepower Management Center (labeled FMC) on the Jump desktop. The login name and
password will prepopulate.
2. Click Log In.
3. Navigate to Objects > Object Management > Interface. Select Interface from the left navigation panel.
a. Click Add > Security Zone.
b. For Name, enter BViZone. Select Switched from the Interface Type drop-down menu.
c. Click Save.
Cisco dCloud
Modify the NGFW interface configuration
1. Navigate to Devices > Device Management.
a. Click on the pencil icon to edit the NGFW device configuration, and select the Interfaces tab.
b. Click on the pencil icon to edit the GigabitEthernet0/1 interface.
c. Remove the IPv4 address and click OK. This IP must be removed, so it can be used on another interface.
d. Click Add Interfaces, and select Bridge Group Interface.
e. For Name enter insideBVi.
f. For Bridge Group ID, enter 1.
g. Select GigabitEthernet0/1 and GigabitEthernet0/2, and click Add.
h. Select the IPv4 tab, and enter the IP address 198.19.10.1/24.
i. Click OK.
Cisco dCloud
2. Click on the pencil icon to edit the GigabitEthernet0/1 interface.
a. For Name enter inside1.
b. Confirm that the Enabled checkbox is checked.
c. Select BVIZone from the Security Zone drop-down list.
d. Click OK.
3. Click on the pencil icon to edit the GigabitEthernet0/2 interface.
a. For Name enter inside2.
b. Check the Enabled checkbox.
c. Select BVIZone from the Security Zone drop-down list.
d. Click OK.
4. Click Save to save the device configuration.
Modify the NAT policy
NOTE: If you performed the routing scenario, and you want the static NAT rule to work with the BVI interfaces, you must include
this step. This is because object NAT does not allow zones with more than one interface.
1. Navigate to Objects > Object Management. Select Interface from the left navigation panel.
a. Click Add > Interface Group.
b. For NAME, enter inZone1.
c. For Interface Type, select Switched.
d. Select the interface inside1, and click Add.
e. Click Save.
2. Navigate to Devices > NAT.
3. Edit the Default PAT policy.
a. If you did routing scenario , replace InZone with InZone1 in the auto NAT rule.
b. Replace InZone with BVIZone in every other rule.
c. Click Save to save the NAT policy.
Cisco dCloud
Modify the access control policy
1. Navigate to Policies > Access Control > Access Control.
2. Select Base_Policy and edit the access control policy.
3. Click on the pencil icon to edit the NGFW device configuration, and select the Interfaces tab.
a. Replace InZone with BVIZone in every rule.
b. Add an access control rule to allow (but inspect) traffic between interfaces in BVIZone.
c. For Name, enter Allow Internal Traffic.
d. Select into Default rule from the Insert drop-down list
e. The Zones tab should already be selected.
f. Select BVIZone, and click Add to Source.
g. Select BVIZone, and click Add to Destination.
h. Select the Inspection tab.
i. Select Demo Intrusion Policy from the Intrusion Policy drop-down list.
j. Select Demo File Policy from the File Policy drop-down list.
k. Click Add to add the rule.
4. Click Save to save the changes to the access control policy.
5. Deploy and test the configuration
NOTE: Deploy the configuration changes, and wait for the deployment to complete.
6. From the Inside Linux Server CLI, test connectivity by typing ping isolated. This should succeed.
7. From the Inside Linux Server CLI, test the IPS capabilities.
a. Run the following command from the Inside Linux server CLI. ftp isolated
b. Login as guest, password C1sco12345.
i. Type cd ~root. You should see the following message:
ii. 421 Service not available, remote server has closed connection
Cisco dCloud
c. From the Inside Linux server CLI, test the file and malware blocking capabilities.
i. As a control test, use WGET to download a file that is not blocked. wget -t 1 isolated/files/ProjectX.pdf
ii. This should succeed.
iii. Next use WGET to attempt to download the file blocked by type. wget -t 1 isolated/files/test3.avi
NOTE: Very little of the file is downloaded. This is because the NGFW can detect the file type when it sees the first block of data.
The Demo File Policy is configured to block AVI files.
iv. Finally use WGET to attempt to download malware. wget -t 1 isolated/files/Zombies.pdf
NOTE: About 99% of the file is downloaded. This is because the NGFW needs the entire file to calculate the SHA. The NGFW
holds onto the last block of data until the hash is calculated and looked up. The Demo File Policy is configured to block malware
detected in PDF files.
Cisco dCloud
Scenario 2. High Availability Configuration

• Configure and Deploy Backup NGFW
• Create High Availability Pair of Firewalls
• Configure Active/Standby with Virtual Mac Address
• Test the configuration
The objective of this exercise is to understand and configure High Availability for NGFW. You will configure the second firewall and
then add it to the High Availability group.
Steps
Remove IRB Lab components
NOTE: Do to current Lab limitations we will need to remove the IRB configurations from the NGFW1 we will be using
GigabitEthernet 0/2 for the Failover HA Link
1. Devices > Device Management > click the pencil icon on the NGFW1 line
2. Click Remove Icon from the BVI1 Interface
3. Go to GigiabitEthernet 0/1 and click the pencil icon
a. Name LAN-Side
b. Click Enabled
c. Security Zone InZone
d. IPv4 198.19.10.1/24
e. Click OK
f. Click Save
4. Go to Device NAT Default PAT
a. Replace inZone1 with InZone for all NAT Rules
b. Replace the BVIZone with InZone
c. Click Save
5. Go to Policies > Access Control > Base_Policy
a. Click the pencil icon
b. Replace ALL BVIZone with InZone
c. You can delete the line with BViZone to BViZone used for the Allow Internal Traffic
d. Click Save
6. Click Deploy
Cisco dCloud
7. Test the Network

a. From Inside Linux Server
i. Ping Outside
b. From Outside Linux Server
i. Ping 198.18.133.120 (Outside NAT Address of FMC)

ii. Ping 198.18.128.202 (Outside NAT Address of Inside Linux Server)
c. Go to the Jump PC and open up the Remote Desktop Folder click on Wkstbr1
i. Username: Administrator Password: C1sco12345
ii. Open the Command Prompt
1. Ping 198.18.133.120 (Outside NAT Address of FMC)
2. Ping 198.18.128.202 (Outside NAT Address of Inside Linux Server)
Run the REST API script to configure NGFW2
1. Go to the Jump PC and Open the PUTTY Session
a. Select NGFW2 Select Load Select Open
b. Username: admin password: C1sco12345
c. Type the following: configure manager add fmc.dcloud.local C1sco12345 select yes (must type yes in full)
d. When command prompt returns type: show managers make sure fmc.dcoud.local says status pending
Cisco dCloud
NOTE: The following information is communicated over the failover link:
The unit state (active or standby)

Hello messages (keep-alives)
Network link status
MAC address exchange
Configuration replication and synchronization
Creating or breaking a Firepower Threat Defense high availability pair immediately restarts the Snort process on the primary and
secondary devices, temporarily interrupting traffic inspection on both devices. Whether traffic drops during this interruption or
passes without further inspection depends on the model of the managed device and how it handles traffic. See Snort® Restart
Traffic Behavior for more information. The system warns you that continuing to create a high availability pair restarts the Snort
process on the primary and secondary devices and allows you to cancel.
NOTE: If you are completing the Basic lab starting from Scenario 1, proceed to Step 2.
If you are completing the Advanced Lab starting from Scenario 6, complete the steps below [Modifying REST API script to register
and configure the NGFWs]. Then complete the rest of the lab starting with Step 2.
Modify REST API script to register and configure the NGFWs
1. On the Jump PC Firefox Browser Click on the + Tab to open a new tab
2. Tab for FMC API (API Explorer) The unsername/password will prepopulate (restapiuser/C1sco12345)
Cisco dCloud
3. Click on Policy
4. Go to Policy and then the first Policy which is accesspolicies and the GET Icon
5. Go to the Get Button under API CONSOLE
6. Copy the Access Policy ID # that matches the name of the Access Control Policy you created
Cisco dCloud
7. Copy the Access Policy ID # in notepad on the Jump PC
8. Go to the folder API_Scripts on the Jump PC Desktop and select NGFW2 folder
9. Select and Open runapiscript2 from the scripts folder with Notepad++
Cisco dCloud
10. Go to line 37 paste the Access Policy ID into the quotes marked ID
11. Click save from the Notepad++ menu
NOTE: Just use the Save Function and not the Save As. This will keep the same file type as referenced in the script. Repeat for
the Register_Config2.py.
12. When the registration completes go back to the PUTTY session of the inside server and continue the script.
NOTE: The script will not ask you to choose an access policy name. You modified the script to use the id of the script name you
configured as part of NGFW1 setup.
Cisco dCloud
Copy Files to Inside Linux server
1. On the Jump PC,open up the Filezilla program.
2. In the hostname field type inside.dcloud.local or 198.19.10.200.
3. Log in with username: guest and password: C1sco12345 port: 21.
4. Navigate to the folder home/guest/API and copy the files (ngfw_config2) from the Jump PC to Inside Linux Server.
5. Right click on the files you just copied and select File Permissions.
Cisco dCloud
6. Click on all the File Attributes so that the Numeric value is 777.
NOTE: This enables all attributes to allow you to run the scripts on the Linux server. This is for this lab testing only. Consult with
your IT team to see which file permissions they want to enable).
7. On the Jump PC, open Putty.
8. Open a SSH session to the Inside Linux Server.
Cisco dCloud
9. Log in using the userid root and password: C1sco12345.
10. Enter cd /home/guest/API.
11. Enter ls (This will show contents of the directory).
12. Enter mv *(x)* /usr/local/bin (This will move any file that has an “x” to the usr/local/bin directory. The “x” is used to signify the
script number) If you are prompted to overwrite files select [y].
13. Enter ls /usr/local/bin (Shows the contents of the directory /usr/local/bin).
NOTE: You can also copy and move the all the files from the Jump PC in bulk. The above steps were to show the process of
moving the scripts to the host server.
14. Open a PUTTY Session to inside server
a. Login username: root password: C1sco12345
b. Type runapiscript2 wait for the prompt and type y
Cisco dCloud
15. Go back to Firefox and check the registration status of NGFW2 on the FMC
16. When the registration completes go back to the PUTTY session of the inside server and continue the script
NOTE: The script will not ask you to choose an access policy name. You modified the script to use the id of the script name you
configured as part of NGFW1 setup.
Configure High Availability Pair
1. Go to Devices > Device Management> Add > Add High Availability
NOTE: The NGFW2 Management Interface (198.19.10.81) was preconfigured during initial setup. Interfaces G0/0 and G0/1 were
configured by the script. They do not have security zones listed on the interface, but they will inherit the security zones and the
interface IP Address’ from NGFW1 when the HA process is run.
2. Name: HA_Test Device Type: Firepower Threat Defense Primary Peer: NGFW1 Secondary Peer: NGFW2 Then Continue
Cisco dCloud
NOTE: If you have done configuration tasks on either of the HA Peers and have not deployed then you will get the following
message:
3. Select Interface: GigabitEtherent0/2 Name: Failover_Link Primary IP: 198.19.254.1 Secondary IP: 198.19.254.2 Subnet
Mask: 255.255.255.0 State Link: Interface Same as LAN Failover IPsec Encryption: Enabled (OPTIONAL)
NOTE: If Interfaces do not show up go back to Devices > Device Manager > Click on the Pencil Icon for each firewall click on the
Interfaces to make sure they are enabled.
Cisco dCloud
4. Click on OK to add the High Availability Pair
NOTE: The configuration of the HA will take some time you will see status updates from time to time if you watch the Tasks next to
the deployment button.
5. When complete you will see the following:
6. Go to Devices > Device Management Click on the pencil icon next to the HA Policy
7. Select the “+” icon next to the Interface MAC Address
Cisco dCloud
8. Physical Interface: GigabitEthernet0/0 Active Interface MAC Address: student choice (IP Address of interface used in
example) Standby Interface Mac Address: Student Choice Click Ok Repeat for Interface GigabitEthernet0/1
9. Configure Monitored Interfaces Go to the pencil icon next to Monitored Interfaces
NOTE: MAC Addresses and IP Addresses in Failover.
When you configure your interfaces, you can specify an active IP address and a standby IP address on the same network.
Although recommended, the standby address is not required. Without a standby IP address, the active unit cannot perform network
tests to check the standby interface health; it can only track the link state. You also cannot connect to the standby unit on that
interface for management purposes.
When the primary unit or failover group fails over, the secondary unit assumes the IP addresses and MAC addresses of the
primary unit and begins passing traffic.
The unit that is now in standby state takes over the standby IP addresses and MAC addresses.
Because network devices see no change in the MAC to IP address pairing, no ARP entries change or time out anywhere on the
network.
If the secondary unit boots without detecting the primary unit, the secondary unit becomes the active unit and uses its own MAC
addresses, because it does not know the primary unit MAC addresses. However, when the primary unit becomes available, the
secondary (active) unit changes the MAC addresses to those of the primary unit, which can cause an interruption in your network
traffic. Similarly, if you swap out the primary unit with new hardware, a new MAC address is used.
Virtual MAC addresses guard against this disruption because the active MAC addresses are known to the secondary unit at
startup, and remain the same in the case of new primary unit hardware. In multiple context mode, you can configure the ASA to
generate virtual active and standby MAC addresses automatically. In single context mode, you can manually configure virtual MAC
addresses.
Cisco dCloud
If you do not configure virtual MAC addresses, you might need to clear the ARP tables on connected routers to restore traffic flow.
The ASA does not send gratuitous ARPs for static NAT addresses when the MAC address changes, so connected routers do not
learn of the MAC address change for these addresses.
The IP address and MAC address for the state link do not change at failover; the only exception is if the state link is configured on
a regular data interface.
10. Select LAN-Side and enter the Standby IP Address: 198.19.10.2 Repeat for the ISP-Side Interface
11. Click Save and then deploy Select HA_Test and then Deploy
Looking at the configuration of NGFW2.
1. Let’s look at some of the configuration parameters that NGFW2 received during the HA setup
Cisco dCloud
2. Go to the Jump PC open PUTTY and select NGFW2
3. Login into the NGFW Username: admin Password: C1sco12345 Type: Show running-config
NOTE: Interface G0/0 and G0/1 have assumed the IP Address of NGFW1. Also Interface G0/2 is shown as a failover interface
Cisco dCloud
Testing Failover
1. On the Jump PC go to PUTTY and open up a session to the Inside Linux Server
2. Login: root Password: C1sco12345 Type: ping outside and let continue to run
Cisco dCloud
3. Go to the web interface of the FMC Devices > Device Management Click on the Switch Peers icon and click Yes
4. Resize the Firefox window so you can also see the results of the pinging from the Inside Linux Server.
Cisco dCloud
Scenario 3. AnyConnect Remote Access VPN

• Enable AnyConnect Smart license
• Create AnyConnect RA VPN objects
• Modify the default group policy
• Run the RA VPN wizard
• Configure the device certificate
• Modify the access control policy to permit inbound AnyConnect access
• Configure a NAT exemption
• Deploy and verify the NGFW RA VPN configuration
• Test the configuration
The objective of this exercise is to understand and configure AnyConnect remote access VPN feature available on the Cisco
Firepower NGFW.
Steps
Enable AnyConnect Smart license
1. In the FMC, navigate to System > Licenses > Smart Licenses
2. Click Edit Licenses.
Cisco dCloud
3. In the Edit Licenses window, select the AnyConnect Apex tab.
a. Select the HA_Test device. Click Add and Apply.
Create AnyConnect RA VPN objects
1. Create an AnyConnect image object for Windows.
a. In the FMC, navigate to Objects > Object Management > VPN > AnyConnect File.
b. Click Add AnyConnect File.
c. For Name, enter AnyConnect-Win-Img.
d. Click Browse and navigate to the RA VPN folder on the Jump desktop.
e. Select the anyconnect-win-4.4.01054-webdeploy-k9.pkg file.
f. Click Open. Note that the File Type text field prepopulates with the correct value.
g. Click Save.
Cisco dCloud
2. Create another AnyConnect image object for MAC OS.
a. Click Add AnyConnect File.
b. For Name, enter AnyConnect-MAC-img.
c. Click Browse and select the anyconnect-macos-4.4.01054-webdeploy-k9.pkg file from the RA VPN folder on the
Jump desktop.
d. Click Open. Note that the File Type text field prepopulates with the correct value.
e. Click Save.
3. Create an AnyConnect client profile object.
a. Click Add AnyConnect File.
b. For Name, enter AnyConnect-Profile1.
c. Click Browse and select the AC-Profile1.xml file from the RA VPN folder on the Jump desktop.
d. Click Open. Note that the File Type text field prepopulates with the correct value.
e. Click Save.
Cisco dCloud
NOTE: AnyConnect client profiles can be create using the VPN Profile Editor tool, which is available on cisco.com. The VPN
Profile Editor tool is also available in the Jump. It can be access as Start > All Programs > Cisco > Cisco AnyConnect profile editor
> VPN Profile Editor.
4. Create an IP pool.
a. In the FMC, navigate to Objects > Object Management > Address Pools > IPv4 Pools.
b. Click Add IPv4 Pools.
c. For Name, enter AC-IP-Pool1.
d. For IPv4 Address Range, enter 198.19.13.10-198.19.13.50.
e. For Mask, enter 255.255.255.0.
f. Click Save.
Cisco dCloud
5. Create a network object corresponding to the IPv4 pool.
a. In the FMC, navigate to Object > Object Management > Network.
b. Click Add Network and select Add Group.
c. For Name: enter AC-NW
d. Under Selected Networks, in the bottom text field, enter 198.19.13.0/24 and click Add.
e. Click Save.
6. Create a network object for inside network.
a. Click Add Network and select Add Group.
b. For Name, enter Inside-NW.
c. Under Selected Networks, in the bottom text field, enter 198.19.10.0/24 and click Add.
d. Click Save.
NOTE: There is a reason you are asked to use network object groups instead of network objects. In the next lab exercise you will
add another subnet. Since you are using a network group, all you will have to do is modify this object. You will not have to directly
modify the access control and NAT policies.
Cisco dCloud
7. Create an ACL for the RA VPN split-tunnel configuration.
a. In the FMC, navigate to Objects > Object Management > Access List > Extended.
b. Click Add Extended Access List.
c. For Name, enter AC-SplitTunnel1. Click Add.
d. Select Inside-NW from the Available Networks and click Add to Source.
e. Click Add.
f. Click Save.
8. Create a device certificate object.
a. In the FMC, navigate to Objects > Object Management > PKI > Cert Enrollment.
b. Click Add Cert Enrollment.
c. For Name, enter NGFW-Cert.
d. For Enrollment Type, select PKCS12 File.
e. Click Save.
Cisco dCloud
9. Create the object for ISE RADIUS server.
a. In the FMC, navigate to Object > Object Management > RADIUS Server Group.
b. Click Add RADIUS Server Group.
c. For Name, enter ISE-AAA.
d. Click the (+) icon the RADIUS Servers section.
e. For IP Address, enter 198.19.10.130.
f. For Key and Conform Key, enter C1sco12345.
g. Click Save on the New RADIUS Server page.
h. Click Save on the Add RADIUS Server Group page.
NOTE: In order to save time, ISE has been pre-configured with all required configuration for all of the lab exercises. If you want to
inspect the ISE configuration, see Appendix 3.
Modify the default group policy
1. In FMC, navigate to Objects > Object Management > VPN > Group Policy.
a. Select and edit DfltGrpPolicy.
b. In the General tab select Split Tunneling.
c. For IPv4 Split Tunneling, select Tunnel networks specified below.
d. Select the Extended Access List radio button.
e. For Access List, select AC-SplitTunnel1.
Cisco dCloud
2. In the General tab select DNS/WINS.
a. For Primary DNS Server, click the (+) icon.
b. For Name, enter Inside-DNS.
c. For Network, enter 198.19.10.100.
d. Click Save.
3. Select the AnyConnect tab. For Client Profile, select AnyConnect-Profile1
4. Click Save to save the changes to the group policy
Cisco dCloud
Run the RA VPN wizard
1. In FMC, navigate to Devices > VPN > Remote Access. Click Add. This will launch the wizard.
a. Complete the Policy Assignment page of the wizard.
b. For Name, enter AnyConnect-VPN.
c. From Target Devices, select HA_Test. Click Add.
d. Click Next
2. Complete the Connection Profile page of the wizard.
a. For Connection Profile Name, enter AC-Default-Profile.
b. Confirm that for Authentication Method, AAA Only is selected.
c. For Authentication Server, select ISE-AAA.
d. For Use IP Address Pools IPv4 Address Pools: Select AC-IP-Pool1
Cisco dCloud
3. Under Address Pools, edit IPv4 Address Pools.
4. Select AC-IP Pool1 from IPv4 Address Pools.
5. Click Add and click OK.
Cisco dCloud
6. Confirm that Group Policy is step to DfltGrpPolicy. Click Next. Remote Access VPN Policy Wizard
7. Complete the AnyConnect page of the wizard.
a. Check both file object checkboxes.
b. Click Next.
Cisco dCloud
8. Complete the Access & Certificate page of the wizard.
a. For Interface group/Security Zone, select OutZone.
b. For Certificate Enrollment, select NGFW-Cert.
c. Click Next.
9. Review the Summary page of the wizard.
a. Review the configured presented in this page.
b. Click Finish.
Cisco dCloud
Configure the device certificate
1. In the FMC, navigate to Devices > Certificates.
a. Click Add and select PKCS12 File.
b. For Device, select HA_Test.
c. For Cert Enrollment, select NGFW-Cert.
d. For PKCS12 File, click Browse PKCS12 File. Navigate to the Certificates folder on the Jump desktop and select
ngfw-outside. Click Open.
e. For Passphrase, enter C1sco12345.
f. Click Add.
Cisco dCloud
Modify the access control policy to permit inbound AnyConnect access
1. In FMC, navigate to Policies > Access Control > Access Control.
2. Select and edit the access control policy (Base_Policy). Click Add Rule.
a. For Name, enter AnyConnect VPN Default Permit.
b. Select into Default from the Insert drop-down list
c. The Zones tab should already be selected.
d. Select OutZone and click Add to Source.
e. Select InZone, and click Add to Destination.
3. Select the Networks tab.
Cisco dCloud
a. Select AC-NW and click Add to Source.
b. Select Inside-NW, and click Add to Destination.
4. Select the Inspection tab.
a. Select Demo Intrusion Policy from the Intrusion Policy drop-down list.
b. Select Demo File Policy from the File Policy drop-down list.
c. Click Add to add the rule.
d. Click Save to save the changes to the access control policy changes.
Cisco dCloud
Configure a NAT exemption
NOTE: NAT exemptions are used so that the IP Address’s used in VPN connectivity are not translated by NAT. This rule will need
to be put in NAT Rules Before in order to make sure these networks are not translated.
1. In the FMC, navigate to Devices > NAT.
2. Select and edit the existing NAT policy (Default PAT). Click Add Rule.
a. You will be at the Interface Objects tab.
b. Select InZone and click Add to Source.
c. Select OutZone, and click Add to Destination.
3. Select the Translation tab.
4. For Original Source, select Inside-NW.
5. For Original Destination, select AC-NW.
6. For Translated Source, select Inside-NW.
7. For Translated Destination, select AC-NW.
Cisco dCloud
8. 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.
9. Click OK to save the NAT rule
10. Click Save to save the changes to the NAT policy.
Cisco dCloud
Deploy and verify the NGFW RA VPN configuration
1. Deploy policy to device.
2. In FMC, click the Deploy button.
3. Select HA_Test and Click Deploy.
4. Wait for the deployment to complete.
5. You should still have an open PuTTY session to the NGFW1 CLI. Run some or all of the following commands.
a. show running-config tunnel-group
b. show running-config group-policy
c. show running-config crypto
d. show running-config ip local pool
e. show running-config nat
6. Test AAA by running the following command on the NGFW1 CLI.

test aaa-server authentication ISE-AAA host 198.19.10.130 username ira password 'C1sco12345'
7. You can cut and paste this command from the Strings to cut and paste.txt text file on the Jump desktop.
test aaa-server authentication ISE-AAA host 198.19.10.130 username ira password 'C1sco12345’
IHFO: Attempting Authentication test to IE address (198.19.10.130) (timeout: 32 seconds)
IHFO: Authentication Successful
Test the configuration
1. Open the Remote Desktops folder on the Jump desktop, and double click on Outside-PC.
2. Login: Administrator Password: C1sco12345
3. Open up Internet Explorer click on NGFW-outside on the favorites bar. (If presented choose Continue to this website)
Cisco dCloud
4. For Username, enter ira. For Password, enter C1sco12345. Click Logon.
5. Click the Install button at the bottom of the page. When prompted, click Install again.
6. After successful installation, AnyConnect will automatically connected.
7. Open the AnyConnect client UI from the bottom right of the Outside-PC, as shown below.
8. Open the Advance Window of the AnyConnect client UI, by clicking on the gear icon, as shown below.
9. Select the Statistics tab to confirm the client and server IP addresses.
a. Select the Route Details tab to confirm the split tunneling: only traffic to 198.19.10.0/24 is considered a secure route.
In other words, only traffic to 198.19.10.0/24 is tunneled through the VPN. Note that 198.19.10.100/32 is also listed
as a secure route. This is because the VPN group policy assigns 198.19.10.100 to the client as the DNS server.
10. Verify this session by running

show vpn-sessiondb detail anyconnect on the NGFW1 CLI.
Cisco dCloud
11. On the Outside-PC open the command prompt.
a. Run nslookup inside.dcloud.local. Confirm that PC-outside is using the internal DNS server with IP address
198.19.10.100.
b. Run the following command. ftp inside.dcloud.local
c. Login as guest, password C1sco12345. This confirms access to the internal server.
d. Type cd ~root. You should see the following message: Connection closed by remote host.
This confirms that intrusion protection is working.
12. In Internet Explorer, click on Inside Linux Server click on the favorites bar.
13. Click on the Files link,
14. Click on the ProjectX.pdf link, and click on the Open button at the bottom of the web page, to confirm that you can download
PDFs.
15. Click on the Zombies.pdf link, and click on the Open button at the bottom of the web page You will see the following message
at the bottom of the web page. This is because the file was blocked by AMP for Networks.
16. In the FMC, navigate to Analysis > Intrusions > Events.
17. Observe that Snort rule 336 was triggered.
Cisco dCloud
18. Drill down to the Table View of Events to confirm that the source IP address was from the VPN pool.
19. In the FMC, navigate to Analysis > Files > Malware Events.
20. Observe that Zombies.pdf was blocked
21. Drill down to the Table View of Malware Events to confirm that the source address was from the VPN pool.
22. Disconnect the AnyConnect VPN before you to onto the next lab exercise.
Cisco dCloud
Scenario 4. AnyConnect with RADIUS Attributes

• Create a new group policy
• Create a new IP pool
• Modify the access control and NAT policies
• Modify the connection profile
• Deploy and test the configuration
In this exercise, we will use ISE RADIUS attributes to dynamically allocate group policy, IP pool and downloadable ACL (DACL)
based on the AD group of the user.
The objectives of this exercise are the following:
• If the RA VPN user is a member of the IT group, they should have full access to any device on the internal network
(198.19.10/24).
• If the RA VPN user is not a member of the IT group, they should only be able to access two internal devices.
The domain controller, ad1.dcloud.local (198.19.10.100). The inside Linux server, inside.dcloud.local (198.19.10.200).
Users that are members of the IT group should be given IP addresses from a separate IP pool.
NOTE: In order to save time, ISE is pre-configured with all required configuration for all the lab exercises. This includes the
selection of group policy and IP pool based on AD group membership. Because of this, the name of the new group policy and
IP pool must be exactly the names given in the instructions. If you want to review the ISE configuration, see Appendix 3.
Steps
Create a new group policy
1. In the FMC, navigate to Object > Object Management > VPN > Group Policy.
2. Click Add Group Policy.
3. For Name, enter ITGP. This must be the exact group name, because of the ISE configuration.
Cisco dCloud
4. In the General tab select Split Tunneling.
a. For IPv4 Split Tunneling, select Tunnel networks specified below.
b. Select the Extended Access List radio button.
c. For Access List, select AC-SplitTunnel1.
d. In the General tab select DNS/WINS. For Primary DNS Server, select Inside-DNS click Save
Cisco dCloud
Create a new IP pool
1. In the FMC, navigate to Objects > Object Management > Address Pools > IPv4 Pools.
a. Click Add IPv4 Pools.
b. For Name, enter AC-IP-Pool-IT. This must be the exact group name, because of the ISE configuration.
c. For IPv4 Address Range, enter 198.19.14.10-198.19.14.50.
d. For Mask, enter 255.255.255.0.
e. Click Save.
Modify the access control and NAT policies
To modify both the access control and NAT policies, all you have to do is modify the AC-NW network group object.
1. In the FMC, navigate to Object > Object Management > Network.
a. Select and edit the network group AC-NW.
b. Under Selected Networks, in the bottom text field, enter 198.19.14.0/24 and click Add.
c. Click Save.
Cisco dCloud
Modify the connection profile
1. In FMC, navigate to Devices > VPN > Remote Access.
a. Edit AnyConnect-VPN. Then select and edit the AC-Default-Profile connection profile.
b. Add the newly created IP pool.
c. The client Address Assignment tab should already be selected.
d. Under Address Pools, click the (+) icon and select IPv4.
e. Select AC-IP-Pool-IT and click Add.
f. Click Save on the Edit Connection Profile window.
Cisco dCloud
2. Add the newly create group policy.
a. Select the Advanced tab of the AnyConnect-VPN page, and select Group Policies from the left navigation pane.
b. Click the (+) icon.
c. Select ITGP and click Add.
d. Click OK and then click Save.
Deploy and test the configuration
1. Deploy the changes to the NGFW. Wait for the deployment to complete.
2. Return to the Outside-PC remote desktop session.
a. Click Connect on AnyConnect client.
b. Log in as harry, password C1sco12345. Harry is not a member of the IT group.
Cisco dCloud
3. Once AnyConnect is connected run the following two commands from the Outside-PC command prompt.
a. ping inside.dcloud.local. This should succeed.
b. ping NGFW1.dcloud.local . This should fail. The DACL that ISE assigns by default only allows access to the domain
controller and inside Linux server.
c. On the NFGW1 CLI, run the following command. show vpn-sessiondb detail anyconnect Observe below values on
the output.
i. Username: harry
ii. Assigned IP: 198.19.13.x
iii. Group Policy: DfltGrpPolicy
iv. Filter Name: #ACSACL#-IP-AC-DACL- Default-x
4. Return to the Outside-PC remote desktop session.
Cisco dCloud
5. Disconnect AnyConnect VPN session
6. Start a new the AnyConnect VPN session.
7. Log in as rita, password C1sco12345. Rita is a member of the IT group.
8. Once AnyConnect is connected run the following two commands from the Outside-PC command prompt.
a. ping inside.dcloud.local. This should succeed.
b. ping NGFW1.dcloud.local. This should also succeed. The DACL that ISE assigns to the IT group allows access to
any internal device.
9. On the NFGW CLI, run the following command. show vpn-sessiondb detail anyconnect. Observe below values on the output.
a. Username: rita
b. Assigned IP: 198.18.14.x
c. Group Policy: ITGP
d. Filter Name: #ACSACL#-IP-AC-DACL-IT-x
10. Disconnect the AnyConnect VPN client.
Cisco dCloud
Scenario 5. Site-to-Site VPN

• Create objects needed for this lab exercise
• Configure site-to-site VPN
• Create NAT exemption
• Create site-to-site VPN with Extranet (Branch 2 Managed by FDM)
• Modify the access control policy and deploy changes
• Deploy the changes and test the configuration
The objective of this exercise is to configure a site-to-site VPN tunnel between the NGFW and an ASA.
Steps
Create objects needed for this lab exercise
1. Navigate to Objects > Object Management. The Network object page will be selected.
a. Click Add Network > Add Object.
b. For Name, enter MainOfficeNetwork.
c. For Network, enter 198.19.10.0/24.
d. Click Save.
2. Click Add Network > Add Object.
a. For Name, enter Branch1OfficeNetwork.
b. For Network, enter 198.19.11.0/24.
c. Click Save.
Configure site-to-site VPN
1. Navigate to Devices > VPN> Site To Site. Click Add VPN > Firepower Threat Defense Device.
NOTE: The other VPN choice, Firepower Device, is for configuring secure tunnels between Firepower devices.
Cisco dCloud
2. For Name enter S2S_Branch1.
a. Confirm that for Network Topology, Point to Point is selected. Confirm that for IKE Version, IKEvI is not checked, and
IKEv2 is checked.
3. Click the green plus to the right of Node A. Fill out as in the figure below, and then click OK.
Cisco dCloud
4. Click the green plus to the right of Node B. Fill out as in the figure below, and then click OK.
5. Select the IKE tab.
6. Under IKEv2 Settings, for Policy, select DES-SHA-SHA.
7. Under IKEv2 Settings, for Authentication Type, select Pre-shared Automatic Key.
NOTE: The Automatic setting can only be used if the FMC is managing both endpoints. In this case, the FMC can generate a
random shared key.
Cisco dCloud
8. Select the IPsec tab, change the IKEv2 IPsec Proposal to DES_SHA-1.
9. Click on the pencil (Edit) icon by IKEv2 IPSec Proposal
10. Click on DES_SHA-1 and Click Add
11. Delete AES-GCM
12. Click OK and Save
Cisco dCloud
Create NAT exemption at HQ
NOTE: NAT exemption is used so that the addresses are not translated by NAT. To do this you have to have the packets
translated by the NAT process back to their original addresses. This must be done before any other NAT statements so you will
put the rule in the NAT Rules Before Category.
2. Click the pencil icon to edit the Default PAT policy.
3. Click Add Rule.
a. Leave In Category and NAT Rules Before from the NAT Rule drop-down list selected.
b. You will be at the Interface Objects tab.
Cisco dCloud
c. Select InZone and click Add to Source.
d. Select OutZone, and click Add to Destination.
4. Select the Translation tab.
a. Select MainOfficeNetwork from the Original Source drop-down list.
b. Select MainOfficeNetwork from the Translated Source drop-down list.
c. Select Branch1OfficeNetwork from the Original Destination drop-down list.
d. Select Branch1OfficeNetwork from the Translated Destination drop-down list.
Cisco dCloud
5. Go To Advanced and Check Do not proxy ARP on Destination Interface click OK
6. Click Save
Create NAT exemption for Branch1
1. Go to Devices > NAT > Branch1 NAT > click the pencil icon to edit the NAT policy
2. Click Add Rule
a. Interface Objects
i. Click Branch1_InZone and Add to Source
ii. Click Branch1_OutZone and Add to Destination
Cisco dCloud
b. Translation
i. Original Packet
1. Original Source Branch1_OfficeNetwork
2. Original Destination MainOfficenetwork
ii. Translated Packet
1. Translated Source Branch1OfficeNetwork
2. Translated Destination MainOfficenetwork
c. Advanced
Cisco dCloud
i. Click Do not proxy ARP on Destination Interface
3. OK
4. Click OK to save NAT Rule
5. Click Save to save the NAT policy.
Modify the access control policy and deploy changes
You will now create a rule to allow traffic between the Branch office and Main office.
1. Navigate to Policies > Access Control > Access Control. Edit the Base_Policy Access Control Policy.
2. Click Add Rule.
a. Call the rule S2S_Branch1_VPN_Access.
3. Select into Default from the Insert drop-down list. This will become the last rule in the access control policy.
4. Leave the action to Allow.
5. The Zones tab should already be selected.
6. Select OutZone, and click Add to Source.
7. Select InZone and click Add to Destination.
Cisco dCloud
8. Select the Networks tab, select Branch1OfficeNetwork, and click Add to Source.
9. Select the Networks tab, select MainOfficeNetwork, and click Add to Destination.
10. Select the Inspection tab.
11. Select Demo Intrusion Policy from the Intrusion Policy drop-down list.
12. Select Demo File Policy from the File Policy drop-down list.
13. Click Add to add this rule to the access control policy.
14. Click Save to save the access control policy.
15. Now Modify the Branch1 Access Policy to allow inbound connections
Cisco dCloud
Configure FMC to Branch2 Site to Site
NOTE: If you are starting this lab from Scenario 6 you MUST go to Configuring Branch 2 Management Using Firepower Device
Manager (FDM ON BOX) section of Scenario 2 if you want to complete this section. This is due to a licensing limitation.
NOTE: In this configuration Branch 2 is controlled by the FDM (On Box Manager). The setting for the Site to Site VPN will be
Extranet and you will have to manually configure the IKEv2 keys.
1. Go to Devices > VPN > Site to Site > Add VPN > Firepower Threat Defense
2. Topology Name Branch2_S2S
3. For Node A follow steps 2 and 3 from Node A configuration changing the Connection Name to whatever you want.
4. Node B
a. Device NGFWBR1
b. Choose Extranet (Not managed by FMC)
c. On Protected Networks click the “+” sign and create a network Object called Branch2Officenetwork with the
network: 192.168.45.0/24
5. Under IKE Policy Select DES-SHA-SHA
6. Authentication Type: Pre-shared Manual Key
Cisco dCloud
7. Key: C1sco12345 Confirm Key: C1sco12345
8. Click OK and then Click Save
9. Build a NAT Exemption Policy for S2S_Branch2
10. Build and Access Policy for S2S_Branch2
Branch 2 Site to Site Configuration
1. On the Jump PC go to Remote Desktops Folder Double Click Wkstbr2
2. Username: Administrator Password: C1sco12345
3. Open the browser to https://192.168.45.45
4. Username: admin Password: C1sco12345!
5. Go to Device scroll down to Site to Site VPN and View Configuration
Cisco dCloud
6. Click Create Site-To-Site Connection
7. Name Branch2-HQ
8. Local VPN Access Interface outside
Cisco dCloud
9. Local Network click the “+” and select Create New Network
a. Add Network Object
i. Name: Branch2Network
ii. Type Network: 192.168.45.0/24
b. Click Ok
Cisco dCloud
10. Click on newly created network and then click OK
11. For Remote IP Address type: 198.18.133.2 (Outside Address of NGFW1)
12. For Remote Network build a Network Object click the “+” sign and Create New Network
13. Name: HQ-Network
14. Type: Network 198.19.10.0/24 (Inside Corporate Network)
Cisco dCloud
15. Select the HQ-Network and click OK
16. Connection Profile should look like below
17. IKE Policies click on Edit
18. Select DES-SHA-SHA and the OK
Cisco dCloud
19. Click EDIT on IPSec Proposal
20. Click the “+” Icon
21. Select DES-SHA-1 in Default Set and click OK
22. Under Additional Options
a. Local Pre-shared Key
i. C1sco12345
Cisco dCloud
b. Remote Peer Pre-shared Key
i. C1sco12345
c. Click NAT Exempt and select Inside Interface
d. Select Next
e. Review and Finish
Deploy the changes and test the configuration
1. Deploy the changes on the FMC and wait for the deployment to complete.
2. Go to the Jump PC Open PUTTY Connect to NGFW1 NGFWBR1 Login: admin Password: C1sco12345
3. From the NGFW1 CLI, type show crypto ipsec sa peer 198.18.133.142. There should be no IPSec security associations.
Cisco dCloud
4. Go to NGFWBR1 and type: show crypto ipsec sa peer 198.18.133.2 There should be no connections
5. Open a PUTTY Session to Inside Linux Server Login: root Password: C1sco12345
6. From the Inside Linux server CLI, type ping branch. Wait a few seconds, and the ping should succeed.
Cisco dCloud
7. From the NGFW1 CLI, type show crypto ipsec sa. There should now be an IPSec security association.
8. On the Jump desktop, open the PUTTY link. Double click on the preconfigured session called Branch Linux Server.
9. Login as root, password C1sco12345.
10. Type curl inside. This should succeed.
11. Go Back to the Inside Linux Server and type: ping 192.168.45.225 this should succeed.
12. Go back to NGFW1 CLI and type show ipsec sa peer 198.18.3.2
Cisco dCloud
13. Do not disconnect the AnyConnect VPN. Continue immediately to the next lab exercise.
Cisco dCloud
Scenario 6. Monitoring and Troubleshooting

• Monitoring AnyConnect user activity
• Troubleshooting
You will use the FMC for Monitoring AnyConnect User activity and troubleshooting.
Steps
Monitoring AnyConnect user activity
In this section, you can monitor all active users who have logged in through AnyConnect.
1. In the FMC, navigate to Overview > Dashboards > Access Controlled User Statistics
2. Select the VPN tab. Note that there are 7 widgets dedicated to VPN traffic.
3. Navigate to Analysis > Users > Active Sessions.
a. Notice that you see Rita's VPN session.
b. Check the checkbox to the left of Rita's session and click Logout. When prompted, click Continue.
NOTE: You may also see other active sessions discovered with network discovery. For example, you may see guest discovered
through an FTP session. For brevity, those sessions were left out of the figure above. If you want more details about users and
how they were discovered, navigate to Analysis > Users > Users.
4. On Outside-PC, confirm that Rita has been logged out.
5. In the FMC, navigate to Analysis > Users > User Activity. In this window you will see details of current and past user
sessions. Spend a couple minutes reviewing the information on this page.
Troubleshooting
In this section, you will modify the Syslog level for VPN events on the NGFW. You will also run some basic troubleshooting
commands from the NGFW1 CLI.
1. In the FMC, navigate to Device > VPN > Troubleshooting. Note that no records are displayed.
2. In the FMC, navigate to Devices > Platform Settings.
a. Click on the blue text Threat Defense Settings Policy.
b. Name the policy HA_Test Settings Policy.
c. Select the HA_Test device, and click Add to Policy.
d. Click SAVE
Cisco dCloud
3. Click Save. Wait for the policy to open for editing.
4. In the left navigation pane, select Syslog.
a. Under VPN Logging Settings change the logging level to informational. Note that in a production environment, it is
recommended that you set this to errors or alerts.
b. Click Save.
5. Deploy the changes to the HA_Test
6. On the Outside-PC, generate some VPN activity. For example, connect and disconnect a VPN session.
Cisco dCloud
7. In the FMC, return to Device > VPN > Troubleshooting. You should see records. If you do not, try adjusting the time window
on this page.
8. On the NGFW1 CLI run some of the following commands to get a rough scope of the troubleshooting capabilities. These are
useful when troubleshooting RA VPN. They are primarily included for your reference.
a. show vpn-sessiondb ?
b. test aaa-server ?
c. debug crypto ca ? (good for trouble-shooting certificate issues)
d. debug crypto ipsec ?
e. debug ldap ?
f. debug aaa ?
Pigtail Registration Troubleshooting
1. Go to Jump PC and Open a PUTTY session to NGFW3
a. Login: admin Password C1sco12345
b. Enter show managers
i. You should see the manager registration status as pending
2. Go to the FMC webpage.
a. Go To Devices > Device Management > Click Add and Add Device
3. Add Device
a. Host: 198.19.10.83
b. Display Name: NGFW3
Cisco dCloud
c. Registration Key: cisco123
d. Access Control Policy: Base_Policy
e. Licensing
i. Check Malware
ii. Check Threat
iii. Check URL Filtering
f. Click Register
g. Registration will fail
4. On NGFW3 type Pigtail
a. You will see Registration failed
b. Check IP address via ping system fmc.dcloud.local (198.19.10.120)
c. Type Pigtail then hit enter a few times
d. Hit the register button again
e. Check the output from the NGFW3
NOTE: You can read the output from the PUTTY session or you can copy the output to Jump PC Notepad++.
5. Check for the error message (Hint the output will state an authentication error)
6. Use Ctrl C to go back to the prompt
7. Type sftunnel-status
a. You will see also see that no tunnel was build
NOTE: If you cannot find the authentication error *hint check password* then you can do the following on the NGFW3 from the
command prompt type expert then type sudo su you will be in the /home/admin#
Cisco dCloud
8. Type cat /etc/sf/sftunnel.conf
9. Type exit and exit
10. Type show managers and you will see that the registration is still pending
11. Go back to the FMC web page and click OK on the Error
12. Change the Registration Key to C1sco12345 and click Register
NOTE: You can turn pigtail on again by typing pigtail to watch the registration process.
Pigtail Registration Troubleshooting
1. If you did not do this in the previous lab in the FDM (Branch 2) go to Device Routing View Configuration
2. Click on Line #1 the pencil icon
3. Click on the Arrow by Gateway
4. Select Create New Network
a. Name: tsroute
b. Host: 198.18.133.4/18 click OK
5. For Gateway select the newly created gateway: tsroute
6. For Interface select: outside
7. Click OK
8. Click Deploy
9. Wait for the Deployment to finish
10. You will see a Status of Failed
11. Do not click the see details
12. Open PUTTY on the Desktop and Login to the FDM (192.168.45.45:22)
Cisco dCloud
a. Username: admin Password: C1sco12345!
13. At the prompt type pigtail deploy
NOTE: This will limit the messages to deployment messages.
14. Right click on the PUTTY session at the top next to the FDM and select Copy All to Clipboard
15. Open the Notepad ++ and Paste the contents into Notepad ++
16. In Notepad ++ Select Search Find and search for ERROR select Match case
17. You will see an error that references the next hop address
a. Go back to the FDM and fix the issue
NOTE: As of 6.2 you can also select See Details under the Failed Status. This does not catch every error so it is still
recommended to run pigtail on both the FTD and FMC and copy the output for TAC calls.
Other Pigtail Commands
1. Pigtail Commands
a. Pigtail –help
b. Pigtail all
c. Pigtail ui
Troubleshooting with Packet Tracer Packet Capture
1. When to use Packet-Tracer
a. Verify if traffic to a specific port is allowed by the Lina Data path and Snort
i. Security Intelligence (IP Reputation)
ii. L3/L4 IPS Intrusion Rules
b. Packet Tracer Does Not currently work with: (Because it cannot emulate a L7 packet)
i. Identity-based rules
ii. L7-related (SI DNS/URL, App ID, File Policy, L7 Intrusion Rules)
Packet-Tracer Lab
1. Go Policies > Access Control > Edit the Base_Policy
2. Click Add New Rule
a. Name: Packet-Trace Rule
b. Set the Rule ABOVE rule 1
c. Under Action Block or Block with reset
Cisco dCloud
d. Zones: Source Zone InZone, Destination Zone Outzone
e. Networks: Source: MainOfficenetwork Destination Networks: any-ipv4
f. Applications: Available Applications type ICMP and Select All apps matching the filter click Add to Rule
g. Available Applications type: FTP select All apps matching the filter and click Add to Rule
h. Click Logging
i. Click Log at Beginning of Connections
i. Click Save
j. Click Save and Deploy
NOTE: We selected all the applications related to ICMP and FTP in a production environment you would be more specific with
what particular applications you are blocking.
3. Go to the Jump PC and open a PUTTY session to the Inside Linux Server Username: root Password: C1sco12345
4. Open a PUTTY Session to NGFW1 Username: admin Password C1sco12345
5. Type the following packet-tracer input LAN-Side icmp 198.19.10.200 8 8 198.18.133.200
a. Look at Phase 2 you will notice that the packet has been handed off to SNORT for further processing
b. Look at Phase 12 You will see that SNORT used block w/reset a rule id to order a drop of the packet.
6. Now look at the Packet-Trace command in the FMC
7. Go to Devices > Device Management.> NGFW1 click on the Trouble shooting Icon
8. Click on Advanced Troubleshooting
9. Choose Packet Tracer
a. Packet Type: ICMP
b. Interface: LAN-Side
c. Source: 198.19.10.200
d. Type: 8 (Echo Request) Code 8
e. Destination: 198.18.133.42
Cisco dCloud
f. Click Start
NOTE: You will get the same results that you saw in the Command Line of the NGFW1 it is just shown in the window. Check
phase 2 and phase 12.
10. Set up the Packet Tracer for FTP
a. Packet Type: TCP
b. Source: 198.19.10.200
c. Source Port: 1111
d. Destination 198.18.133.200 (Outside Linux Server)
e. Destination Port: FTP
f. Click Clear
g. Click Start
NOTE: Phase 2 is still checking the rule you created Look at Phase 14 you will see that SNORT looked at the rule and the verdict
was to pass the packet. The first part of the packet is passed but not the next packets. To test this go to the Jump PC and open
the inside linux server session and type ftp outside you will be prompted: login: guest you will receive a message that
states No Control connection for command Transport endpoint is not connected. You can go to Analysis Connection Events and
see that FTD was Blocked with reset.
Capture w/Trace Lab
NOTE: There are two types of Traffic Captures the Lina based and the Snort based.
1. Lina Level capture
2. SNORT Level capture-traffic
Cisco dCloud
3. Go to Devices > Device Management > click on the Troubleshooting Icon for NGFW1
4. Click on Advanced Troubleshooting
5. Click on Capture w/Trace
6. Click Add Capture
a. Name: Capturewtrace
b. Interface: LAN-Side
c. Protocol: ICMP
d. Source Host: 198.19.10.200 (Inside Linux Server)
e. Destination Host: any
f. Buffer Size: 33554432 (32 MB)
g. Trace Count 100
h. Save
NOTE: We have not removed the access policy denying ICMP so the pings will fail, but you will be able to see the packet shown.
Also you will export the file in PCAP format to Wireshark in this lab.
7. Go to the Jump PC and on the Inside Linux Server type ping outside
8. If you don’t see information in the Packets Shown in about 10 seconds hit the refresh.
9. Once you see packets you can stop the ping
Cisco dCloud
10. Click on the Save icon for the packet capture you created
a. Save the file as PCAP
11. When Prompted Save File and click OK
12. Go to the downloads arrow of Google Chrome and select the file just downloaded
13. Minimize the Browser and you will see the file opened in Wireshark.
14. Notice that the messages have been administratively filtered.
Cisco dCloud
Scenario 7. Cisco Threat Intelligence Director (CTID)

• Retrieve a STIX file from a web server
• Analyze a complex indicator and its associated observables
• Upload a list of URLs to CTID that will trigger an Incident
• Subscribe CTID to a TAXII feed
• Generate CTID incidents
The CTID is a component of the FMC that can consume third party cyber threat intelligence indicators; CTID parses these
indicators to produce observables that can be detected by the NGFW. The NGFW reports detection of the observables to CTID.
Then CTID determines whether the observations constitute an incident.
Two file formats are supported.
• Flat files - Lists of simple indictors such as IP addresses, URLs or SHA256 hashes
• Threat Intelligence Director is enabled by default You can find it under Policies > Access Control > Then the policy under
Advanced
STIX files - XML files that can describe simple or complex indicators There are 3 ways these files can be retrieved:
• Uploaded from the computer where the FMC UI is running
• Retrieved from a URL on a remote web server
• Received from a TAXII feed (STIX files only)
The objective of this exercise is to configure and test CTID.
Cisco dCloud
Steps
Confirm that CTID will publish observables to the NGFW
2. Edit the access control policy by clicking the pencil icon to the right of the policy.
3. Select the Advanced tab.Using this advanced setting, CTID can be enabled or disabled at the access policy level.
4. Navigate to Intelligence > Elements.
5. Confirm that the NGFW1 is an element. This means that CTID can publish observables to the NGFW1 retrieved from a STIX
file from a web server.
NOTE: The CTID can be enabled or disabled globally. Clicking Pause will stop the CTID publishing to all elements.
6. Navigate to Intelligence > Sources > Sources.
Cisco dCloud
7. Click the plus sign (+) on the right to add an intelligence source.
8. For DELIVERY, select URL.
9. For TYPE, confirm that STIX is selected.
10. For URL, enter http://198.19.10.200/files/STIX.xml.
11. For NAME, enter STIX file from Webserver. .
12. Click Save.
NOTE: You cannot change the action from Monitor to Block for STIX files. STIX files can represent complex indicators, so it is
impossible for the NGFW, based on an observable, to decide if the criteria of the indicator has been satisfied.
However, even for complex indicators, you can set the action for individual observables to Block.
Cisco dCloud
13. Wait few seconds. Navigate to Intelligence > Sources > Indicators. Confirm that a complex indicator has been added.
14. Click on the name of the indicator Weatherman PUA. Observer the details of the indicator.
15. Click Close to close the Indicator Details page.
16. Navigate to Intelligence > Sources > Observables. Confirm that two SHA-256 and one IPv4 observables have been added.
17. Upload a list of URLs to CTID that will trigger an Incident
a. Navigate to Intelligence > Sources > Sources. Click the plus sign (+) on the right to add an intelligence source.
b. For DELIVERY, select Upload.
c. For TYPE, select Flat File. The CONTENT drop-down list will appear.
d. For CONTENT, select URL.
e. Click in the FILE area, and select URL_LIST.txt from the Files folder on the Jump desktop.
f. For NAME, enter Local url list.
g. For ACTION, select Block.
Cisco dCloud
18. Click Save.
19. Wait a few seconds. Navigate to Intelligence > Sources > Indicators. Confirm that two URL indicators have been added.
20. Navigate to Intelligence > Sources > Observables. Confirm that two type URL observables have been added.
Subscribe CTID to a TAXII feed
1. Navigate to Intelligence > Sources > Sources. Click the plus sign (+) on the right to add an intelligence source.
2. For DELIVERY, select TAXII.
3. For URL, enter http://hailataxii.com/taxii-discovery-service.
4. For USERNAME, enter guest.
5. For PASSWORD, enter guest.
6. For FEEDS, select guest_phishtank_com.
NOTE: It may take several seconds for the FEEDS drop-down list to populate.
7. Confirm that the screen looks like the following figure.
Cisco dCloud
8. Click Save.
9. Wait until the Status column for this source changes to Parsing. Do not wait for the parsing to complete - this would take too
long.
10. Navigate to Intelligence > Sources > Indicators. Confirm that several URL indicators have been added.
11. Navigate to Intelligence > Sources > Observables. Confirm that several URL observables have been added.
Generate CTID incidents
1. It can take several minutes for the observables to be published to the sensor. In this step, you will see how to confirm the
publication of a particular observable. In the NGFW CLI, perform the following:
2. Type expert to get into expert mode.
3. Type ls -d /var/sf/*download.
NOTE: There are several directories listed. admin@ngfw:~$ ls -d /var/sf/*download /var/sf/clamupd_download

/var/sf/iprep_download /var/sf/sifile_download /var/sf/cloud_download /var/sf/sidns_download /var/sf/siurl_download
Cisco dCloud
Four of these (iprep_download, sidns_download, sifile_download and siurl_download) are used by security intelligence and CTID.
4. Type grep developmentserver /var/sf/*download/*lf. You should see a type URL CTID observable. admin@ngfw:~$ grep
developmentserver /var/sf/*download/*lf var/sf/siurl_download/731625d4-9512-11e7-915c-
7e7252ae92ac.lf:developmentserver.com/misc/Tron.html/
NOTE: If you do not, wait a minute and try again. You must wait for this to be published before you go on.
5. Type grep 198.18.133.200 /var/sf/*download/*lf. You should see a type URL CTID observable. admin@ngfw:~$ grep
198.18.133.200 /var/sf/*download/*lf var/sf/siurl_download/731625d4-9512-11e7-915c-
7e7252ae92ac.lf:developmentserver.com/misc/Tron.html/
NOTE: If you do not, wait a minute and try again. You must wait for this to be published before you go on.
6. Type exit to exit expert mode.
On the Inside Linux server CLI:
1. Run wget -t 1 outside/files/ProjectX.pdf. This should succeed.
2. Run wget -t 1 developmentserver.com/misc/Tron.html. This should be blocked.
3. On the FMC, navigate to Intelligence > Incidents. Confirm that there are 2 incidents.
4. Drill down into the incident and observe the details for this incident.
5. Confirm that there is an incident for a URL indicator. Drill down into the incident and observe the details for this incident
Cisco dCloud
Scenario 8. ASA to NGFW Migration (Optional)

• Convert an FMC to a migration tool
• Migrate ASA objects
• Migrate NAT and unsupported features, and explore object reuse
• The objective of this exercise is to familiarize the student with the migration tool.
• How it is configured
• How it is used
After converting an FMC to a migration tool, two configurations will be migrated. Several aspects of migration will be revealed,
including object flattening and how unsupported features are handled.
Steps
Convert an FMC to a migration tool
1. On the Jump desktop, open the PuTTY link. Double click on the preconfigured session called Migrator. Login as admin,
password cisco12345.
NOTE: Note that this is a separate FMC from the one you are using to manage the NGFW. You should not try to use a production
FMC as a migration tool.
2. Type sudo enableMigrationTool.pl.

a. Enter the password C1sco12345 when prompted.
b. Read the warning - yes really read it!
c. Enter Y when asked if you want to continue.
d. Wait for the script to complete. This will take less than a minute.
3. On the Firefox browser, open a new tab.
e. Click on the bookmark bar link Migration Tool. Click Advanced, and Add Exception. When prompted, click
Confirm Security Acceptation.
NOTE: This FMC, which will be used as a migration tool, was not modified after installation. The FMC you have been using up to
now was preconfigure. This pre-configuration included adding a trusted certificate. See Appendix A for details.
f. Login as admin, password C1sco12345.
g. Confirm that you see the banner in red at the top of the UI that reads:
MIGRATION TOOL INSTALLED / You are limited to ASA conversions only
Cisco dCloud
Migrate ASA objects
The goals of this exercise are the following.
• Learn the migration process.
• Understand how network and service objects and object groups migrate.
1. In the Jump, in the Files folder, open the file ASA_config_1.txt.
a. Observer that there are nested network and service objects.
b. Observer that there is an access list and access group that reference these objects. Without the access group, the
objects would not migrate, since they would have no effect on the policy configuration.
2. In the Migrator UI (not the FMC), navigate to System > Tools > Import/Export.
a. Click Upload Package.
b. Click Browse, and select the file ASA_config_1.txt from the Files folder.
c. Click Upload.
3. . On the next page, leave all the settings unchanged, as below, and click OK.
1.
4. Wait until you are back to the Upload page.
a. Click on the icon to the right of the Deploy button
b. Click on the Task tab and wait for the tasks to compete.
c. Click on the text Click to download the FMC import file(.sfo) and save the SFO file.
Cisco dCloud
d. Click on the text Click and select the default Open with Google Chrome to open the migration report in a new tab.
Confirm that the conversion report contains no errors. Close Chrome.
5. On the (production) FMC UI, navigate to System > Tools > Import/Export.
b. Click on Browse, and select the SFO file from the Downloads folder. It will have a name of the form
c. ExportForMigration-<some UUID>.sfo.
d. Click Upload.
6. On the next page, click Import.
7. Wait for the import to complete.
8. Navigate to Objects > Object Management.
9. The Network object page will be selected. Notice the objects that were created.
a. Four network objects net1, net2, net3 and net4
b. Two network groups net12 and net34
c. One nested network group net1234
NOTE: These are exactly the network objects and network-group object that existed in the ASA configuration.
10. In the left navigation pane, select Port. Notice the objects that were created.
a. Four port objects p1_dst_1, p1_dst_2, p2_dst_1 and p2_dst_2
b. Zero port groups
NOTE: The ASA port groups, p1 and p2, have been flattened, and there is no p12.
11. Navigate to Policies > Access Control > Prefilter.
a. Notice that there is a new prefilter policy. Edit it so you can inspect the rules.
b. Notice that this single ACE is the ASA configuration is now 2 separate prefilter rules.
Cisco dCloud

a. Notice that there is a new access control policy. Edit it so you can inspect it.
b. Notice that there are no rules and that the default action is set to block.
c. Notice that the prefilter policy is set to the prefilter policy inspected in the previous step.
Migrate NAT and unsupported features, and explore object reuse
There are three separate goals in this task. They are not directly related. They have been bundled for expedience.
• Migrate a NAT policy.
• Understand object reuse.
Try to migrate a time-based ACL, and see how the unsupported feature is treated.
1. On the Jump, in the Files folder, open the file ASA_config_2.txt.
a. Observe that two network objects in the ASA configuration already exist in the FMC.
i. The network object net1, which has a different definition than the existing object of the same name
ii. The network object net2, which has the same definition as the existing object with the same name
b. Observer that there is a static NAT rule
c. Observe that there is a time-based ACL. This feature is not currently supported.
c. Click Upload.
3. You will be back to the upload page.
a. Click on the icon to the right of the Deploy button.
Cisco dCloud
Observe that this migration report warns that the time-based ACL was not supported. Close Chrome.
4. In the (production) FMC UI, navigate to System > Tools > Import/Export.
a. Click the Upload Package button.
b. Click on Browse, and select the SFO from the Downloads folder. It will have a name of the form
ExportForMigration-<some UUID>.sfo. Be sure to select the more recently created SFO file.
c. Click Upload.
6. On the next page perform the following sub-steps. See the following figure.
a. Read the information about object conflict resolution
b. Create two interface groups using the drop-down lists on this page. Interfaces references in migrated NAT rules must
be placed in interface groups. Security zones are not allowed. You could call them IF1 and IF2
c. Click Import.
a. Notice the object net1_1 was created. This is because the definition of netl was different in the two migrated ASA
configurations. Therefore the object is renamed.
b. Notice the object net2_1 was not created. This is because the definition of net2 was the same in the two migrated
ASA configurations. Therefore the object is reused.
NOTE: This behavior changed in the Firepower 6.2.1 release. In Firepower 6.2, both objects are renamed.
Cisco dCloud
a. Notice that there is a new NAT policy. Edit it so you can inspect the rules.
b. Notice that the objects net1_1 and net2 are referenced in this policy.
9. Navigate to Navigate to Policies > Access Control > Access Control.
a. Notice that there is a new access control policy. Edit it so you can inspect the rules.
b. Note that there is one rule, and that the source and destination network agree with the ACL from the ASA
configuration:
c. access-list timeacl extended permit ip any host 1.2.3.4 time-range office_hours
d. Notice that the rule is disabled. If you wish, you can enable the rule.
NOTE: The migration tool was presented with an ACL that included both network and time-based criteria. Because time based
ACLs are currently not supported, the migrated rule could only include the network criteria. Since this may not be acceptable, the
rule is disabled, and must be enabled manually.
Cisco dCloud
Scenario 9. ASA to NGFW Migration (Optional)

• Convert an FMC to a migration tool
• Migrate ASA objects
• Migrate NAT and unsupported features, and explore object reuse
• The objective of this exercise is to familiarize the student with the migration tool.
• How it is configured
• How it is used
After converting an FMC to a migration tool, two configurations will be migrated. Several aspects of migration will be revealed,
including object flattening and how unsupported features are handled.
Steps
Convert an FMC to a migration tool
1. On the Jump desktop, open the PuTTY link. Double click on the preconfigured session called Migrator. Login as admin,
password cisco12345.
NOTE: This is a separate FMC from the one you are using to manage the NGFW. You should not try to use a production FMC as a
migration tool.
2. Type sudo enableMigrationTool.pl.
a. Enter the password C1sco12345 when prompted.
b. Read the warning - yes really read it!
c. Enter Y when asked if you want to continue.
d. Wait for the script to complete. This will take less than a minute.
3. On the Firefox browser, open a new tab.
a. Click on the bookmark bar link Migration Tool. Click Advanced, and Add Exception. When prompted, click Confirm
Security Acceptation.
NOTE: This FMC, which will be used as a migration tool, was not modified after installation. The FMC you have been using up to
now was preconfigure. This pre-configuration included adding a trusted certificate. See Appendix A for details.
b. Login as admin, password C1sco12345.
c. Confirm that you see the banner in red at the top of the UI that reads:
MIGRATION TOOL INSTALLED / You are limited to ASA conversions only
Cisco dCloud
Migrate ASA objects
The goals of this exercise are the following.
• Learn the migration process.
• Understand how network and service objects and object groups migrate.
1. In the Jump, in the Files folder, open the file ASA_config_1.txt.
a. Observer that there are nested network and service objects.
b. Observer that there is an access list and access group that reference these objects. Without the access group, the
objects would not migrate, since they would have no effect on the policy configuration.
c. Click Upload.
3. . On the next page, leave all the settings unchanged, as below, and click OK.
2.
4. Wait until you are back to the Upload page.
a. Click on the icon to the right of the Deploy button
Cisco dCloud
Confirm that the conversion report contains no errors. Close Chrome.
5. On the (production) FMC UI, navigate to System > Tools > Import/Export.
b. Click on Browse, and select the SFO file from the Downloads folder. It will have a name of the form
c. ExportForMigration-<some UUID>.sfo.
d. Click Upload.
Cisco dCloud
7. Wait for the import to complete.
8. Navigate to Objects > Object Management.
9. The Network object page will be selected. Notice the objects that were created.
d. Four network objects net1, net2, net3 and net4
e. Two network groups net12 and net34
f. One nested network group net1234
NOTE: These are exactly the network objects and network-group object that existed in the ASA configuration.
10. In the left navigation pane, select Port. Notice the objects that were created.
g. Four port objects p1_dst_1, p1_dst_2, p2_dst_1 and p2_dst_2
h. Zero port groups
NOTE: The ASA port groups, p1 and p2, have been flattened, and there is no p12.
11. Navigate to Policies > Access Control > Prefilter.

i. Notice that there is a new prefilter policy. Edit it so you can inspect the rules.
j. Notice that this single ACE is the ASA configuration is now 2 separate prefilter rules.
a. Notice that there is a new access control policy. Edit it so you can inspect it.
b. Notice that there are no rules and that the default action is set to block.
c. Notice that the prefilter policy is set to the prefilter policy inspected in the previous step.
Cisco dCloud
Migrate NAT and unsupported features, and explore object reuse
There are three separate goals in this task. They are not directly related. They have been bundled for expedience.
• Migrate a NAT policy.
• Understand object reuse.
Try to migrate a time-based ACL, and see how the unsupported feature is treated.
1. On the Jump, in the Files folder, open the file ASA_config_2.txt.
a. Observe that two network objects in the ASA configuration already exist in the FMC.
i. The network object net1, which has a different definition than the existing object of the same name
ii. The network object net2, which has the same definition as the existing object with the same name
b. Observer that there is a static NAT rule
c. Observe that there is a time-based ACL. This feature is not currently supported.
c. Click Upload.
3. You will be back to the upload page.
a. Click on the icon to the right of the Deploy button.
Observe that this migration report warns that the time-based ACL was not supported. Close Chrome.
4. In the (production) FMC UI, navigate to System > Tools > Import/Export.
a. Click the Upload Package button.
b. Click on Browse, and select the SFO from the Downloads folder. It will have a name of the form
ExportForMigration-<some UUID>.sfo. Be sure to select the more recently created SFO file.
c. Click Upload.
Cisco dCloud
6. On the next page perform the following sub-steps. See the following figure.
a. Read the information about object conflict resolution
b. Create two interface groups using the drop-down lists on this page. Interfaces references in migrated NAT rules must
be placed in interface groups. Security zones are not allowed. You could call them IF1 and IF2
c. Click Import.
a. Notice the object net1_1 was created. This is because the definition of netl was different in the two migrated ASA
configurations. Therefore the object is renamed.
b. Notice the object net2_1 was not created. This is because the definition of net2 was the same in the two migrated
ASA configurations. Therefore the object is reused.
NOTE: This behavior changed in the Firepower 6.2.1 release. In Firepower 6.2, both objects are renamed.
a. Notice that there is a new NAT policy. Edit it so you can inspect the rules.
b. Notice that the objects net1_1 and net2 are referenced in this policy.
9. Navigate to Navigate to Policies > Access Control > Access Control.
Cisco dCloud
a. Notice that there is a new access control policy. Edit it so you can inspect the rules.
b. Note that there is one rule, and that the source and destination network agree with the ACL from the ASA
configuration:
c. access-list timeacl extended permit ip any host 1.2.3.4 time-range office_hours
d. Notice that the rule is disabled. If you wish, you can enable the rule.
NOTE: The migration tool was presented with an ACL that included both network and time-based criteria. Because time based
ACLs are currently not supported, the migrated rule could only include the network criteria. Since this may not be acceptable, the
rule is disabled, and must be enabled manually.
Cisco dCloud
Appendix A. FMC Pre-configuration

After the initial installation, several configuration steps were performed on the FMC to expedite the lab exercises. These
configuration steps are detailed in this appendix.
• Configuration A1,1: NTP settings
• Configuration A1,2: Demo file policy
• Configuration A1,3: Demo intrusion policy
• Configuration A1,4: Demo SSL policy
• Configuration A1,5: Custom detection list
• Configuration A1,6: Add resetapiuser.
• Configuration A1,7: Install server certificate
Steps
Configuration A1,1: NTP settings
1. Configure NTP settings on the FMC.
a. In the FMC, navigate to System > Configuration.
b. Select Time Synchronization from the left-side navigation pane.
c. Replace the default NTP server with 198.18.128.1.
d. Click Save.
Cisco dCloud
Configuration A1,2: Demo file policy
1. Navigate to Policies > Access Control > Malware & File.
2. Click New File Policy. Enter a name Demo File Policy. Click Save.
3. Click Add File Rule. This rule will block malware found in files MSEXE, MSOLE2, NEW_OFFICE and PDFs.
4. For Action select Block Malware.
5. Check the Spero and Local Malware Analysis checkboxes.
6. Under File Type Categories, check Dynamic Analysis Capable. Note that several file types belong to this category. Click
Add.
7. Your screen should look like the figure below.
8. Click Save. Ignore the warning and click OK, when prompted.
9. Click Add File Rule. This rule will block RIFF files. You will use an AVI file to test this rule, since an AVI file is a type of RIFF
file. But note that AVI is not listed separately as a file type.
10. For Action select Block Files.
11. Under File Types, type rif into the search box. Select RIFF from the list. Click Add.
12. Use default values for other settings. Your screen should look like the figure below.
13. Click Save.
Cisco dCloud
NOTE: You cannot change the order of the rules you create. The order of the rules does not matter. The action of the rule
determines its precedence. The precedence of actions is as follows.
1 - Block Files
2 - Block Malware
3 - Malware Cloud Lookup
4 - Detect Files
5 - Select the Advanced tab. Confirm that Enable Custom Detection List is selected.
6 - Check the Inspect Archives checkbox.
NOTE: Archives unable to be inspected are corrupt archive, or archives with a depth that exceeds the Max Archive Depth.
14. Click the Save button in the upper-right to save the file policy.
NOTE: Archives unable to be inspected are corrupt archive, or archives with a depth that exceeds the Max Archive Depth.
15. Click the Save button in the upper-right to save the file policy.
Cisco dCloud
Configuration A1,3: Demo intrusion policy
1. Navigate to Objects > Intrusion Rules. Click Import Rules.
a. Select the Rule update or text rule file to upload and install radio button.
b. Click Browse, and open the Snort_Rules.txt file in the Files folder of the Jump desktop.
NOTE: This file contains 2 simple Snort rules that are useful for testing IPS. They do not resemble published snort rules.
alert tcp any any -> any any (msg:"ProjectQ replaced"; content:"ProjectQ"; replace:"ProjectR"; sid: 1001001; rev:1;) alert tcp any
any -> any any (msg:"ProjectZ detected"; content:"ProjectZ"; sid: 1001002; rev:1;)
The first rule replaces the string ProjectQ with ProjectR. The second detects the string ProjectZ. Since the rules do not specify
where the string is in the flow, they could cause issues in a production deployment.
c. Click Import. The import process will take a minute or two. When it completes you will see the Rule Update Import
Log page. Confirm that 2 rules were successfully imported.
2. Navigate to Policies > Access Control > Intrusion.
3. Click Create Policy.
a. Set Name to Demo Intrusion Policy.
b. Make sure that Drop when Inline is checked.
c. Select Balanced Security and Connectivity as Base Policy.
d. Click Create and Edit Policy.
4. You will now modify the rules states for this new policy.
a. Click Rules under Policy Information menu on the left-hand side of the Edit Policy page.
b. Select local from the Category section of the rules. You should see the 2 uploaded rules. The light green arrows on
the right of each rule indicate that the rules are disabled for this policy.
Cisco dCloud
c. Check the checkbox next to the first rule. Select Generate Events from the Rule State drop-down menu. Click OK.
Uncheck the checkbox next to the first rule.
d. Check the checkbox next to the second rule. Select Drop and Generate Events from the Rule State drop-down menu.
Click OK.
e. Clear the filter by clicking on the X on the right side of the Filter text field.
f. Select SID from the Rule Content section of the rules. Enter 336 into the Enter the SID filter popup. Click OK.
g. Check the checkbox next to the rule. Select Drop and Generate Events from the Rule State drop-down menu. Click
OK.
NOTE: This rule looks for a change to the root home directory in FTP traffic established on port 21. It only looks for traffic coming
from the external network, but in our lab we use the default value of $EXTERNAL_NET, which is any, so the rule can be triggered
in both directions.
An interesting exercise would be to modify this rule to search in FTP traffic in any direction, and to use the appid attribute to detect
FTP traffic on any port.
Click Policy Information in the menu on the upper-left.
Click Commit Changes.
Click OK.
Configuration A1,4: Demo SSL policy
1. Navigate to Objects > Object Management > PKI > Internal CAs.
a. Click Import CA.
b. For Name, enter Verifraud.
c. Click the Browse button to the right of the text Certificate Data or, choose a file.
d. Browse to the Certificates folder on the Jump desktop.
e. Upload Verifraud_CA.cer.
f. Click the Browse button to the right of the text Key or, choose a file.
g. Upload Verifraud_CA.key.
h. Click Save.
2. You will exempt from decryption infrastructure devices, such as the FMC and AMP Private Cloud. To do this, create a network
object that includes these devices.
a. Navigate to Objects > Object Management > Network.
b. Click Add Network > Add Object.
c. For Name, enter Infrastructure.
d. For Network, enter 198.19.10.80-198.19.10.130.
e. Click Save to save the network object. 3. Navigate to Policies > Access Control > SSL.
Cisco dCloud
3. Click the text Add a new policy or click the New Policy button.
a. For Name, enter Demo SSL Policy.
b. Leave the default action to Do not decrypt.
c. Click Save. Wait a few seconds, and the policy will open for editing.
4. Click Add Rule.
a. For Name, enter Exempt Infrastructure.
b. Leave Action set to Do Not decrypt.
c. In the Networks tab, under Networks, select Infrastructure, and click Add to Source.
d. Click Add to add this rule to the SSL policy.
5. Click Add Rule.
a. For Name, enter Decrypt Search Engines.
b. Set Action to Decrypt - Resign.
c. Select Verifraud from the drop-down list to the right of the word with.
d. In the Applications tab, under Application Filters, search for Sear. You will see Search Engine under Categories.
Check this checkbox, and click Add to Rule.
e. Select the Logging tab, and check the Log at End of Connection checkbox.
f. Click Add to add this rule to the SSL policy.
6. Click Add Rule.
a. For Name, enter Decrypt Other.
b. Set Action to Decrypt - Resign.
c. Select Verifraud from the drop-down list to the right of the word with.
d. Select the Logging tab, and check the Log at End of Connection checkbox.
e. Click Add to add this rule to the SSL policy.
7. Click Save to save the SSL policy.
NOTE: The Replace Key checkbox deserves explanation. Whenever the action is set to Decrypt - Resign, Firepower will replace
the public key. The Replace Key checkbox determines how the decrypt action is applied to self-signed server certificates.
If Replace Key is deselected, self-signed certificates are treated like any other server certificates. Firepower replaces the key, and
resigns the certificate. Generally the endpoint is configured to trust Firepower, and therefore will trust this resigned certificate.
If Replace Key is selected, self-signed certificates are treated differently. Firepower replaces the key, and generates a new self-
signed cert. The browser on the endpoint will generate a certificate warning.
In other words, checking the Replace Key checkbox makes the resign action preserve lack-of-trust for self-signed certificates.
Cisco dCloud
Configuration A1,5: Custom detection list
There is a harmless file called Zombies.pdf that will trigger a malware event, assuming the cloud lookup succeeds. Sometimes labs
have issues with cloud connectivity. Therefore, this is added to the custom detection list to ensure it will trigger a malware event.
1. Navigate to Objects > Object Management > File List.
2. Click the pencil icon to edit the Custom-Detection-List.
a. Select Calculate SHA from the Add by drop-down list.
b. Click Browse.
c. Browse to the Files folder on the Jump desktop.
d. Select Zombies.pdf, and click OK.
e. Click Calculate and Add SHAs.
f. Click Save.
Configuration A1,6: Add restapiuser
It is convenient to have a separate use to use the API Explorer. This allows use of both the FMC and API Explorer at the same
time.
1. Navigate to System > Users. Click Create User.
a. For User Name, enter restapiuser.
b. For Password, enter Cisco12345. Confirm the password.
c. Set Maximum Number of Failed Logins to 0.
d. Check the Administrator checkbox.
Configuration A1,7: Install server certificate
By default the FMC UI uses a self-signed certificate. This is replaced by a certificate signed by the pod AD server, which the Jump
browsers trust.
1. Navigate to Objects > Object Management > PKI > Trusted CAs.
a. Click Add Trusted CA.
b. For Name, enter dCloud.
c. Click the Browse button to the right of the text Certificate Data or, choose a file.
d. Browse to the Certificates folder on the Jump desktop.
e. Upload AD-ROOT-CA-CERT.cer.
f. Click Save.
2. Connect to the FMC CLI via SSH. Become root by typing sudo -i. The Sudo password is cisco12345
a. Type cd /etc/ssl and then type cp server* /root.
Cisco dCloud
b. Type cat > /etc/ssl/server.crt
c. From the Certificates folder on the Jump desktop edit the file fmc.cer with Notepad++.
d. Select all, and then copy and paste into the FMC CLI
e. Type Ctrl+D.
f. Type cat > /etc/ssl/server.key
g. From the Certificates folder on the Jump desktop edit the file fmc.key with Notepad++.
h. Select all, and then copy and paste into the FMC CLI
i. Type Ctrl+D.
j. Type pmtool restartbyid httpsd.
Cisco dCloud
Appendix B. REST API Scripts

Here are the two Python scripts that were used in the first lab exercise. You only run the first script register_config.py. It will call
the second script connect.py, which will create the compiled file connect.pyc.
Python script register_config.py

#!/usr/bin/python import json import connect import sys
host = "fmc.example.com" username = "restapiuser" password = "C1sco12345" name="NGFW"
#connect to the FMC API
headers,uuid,server = connect.connect (host, username, password)
user_input = str(raw_input("Would you like to register the managed device? [y/n]")) if user_input ==
"y":
policy_name = str(raw_input("Enter name of new Access Control Policy to be create:")) access_policy = {
"type": "AccessPolicy",
"name": policy_name,
"defaultAction": { "action": "BLOCK" }
}
post_response = connect.accesspolicyPOST(headers,uuid,server,access_policy) policy_id =
post_response["id"]
print "\n\nAccess Control Policy\n" + policy_name + "\ncreated\n\n" device post = {
"name": name,
"hostName": "ngfw.example.com",
"regKey": "C1sco12345",
"type": "Device",
"license_caps": [
"BASE",
"MALWARE",
"URLFilter",
"THREAT"
],
"accessPolicy": {
"id": policy_id,
"type": "AccessPolicy"
}
}
post_data = json.dumps(device_post)
output = connect.devicePOST (headers, uuid, server, post_data)
print "\n\nPost request is: \n" + json.dumps(output,indent=4) + "\n\n"
GET ALL THE DEVICES AND THEIR corresponding interfaces
user_input = str(raw_input("In the FMC UI, confirm that the device discovery has completed and then
press 'y' to continue or 'n' to exit. [y/n]"))
headers,uuid,server = connect.connect (host, username, password)
if user_input == "n": quit()
devices = connect.deviceGET(headers,uuid,server) for device in devices["items"]: if device["name"] ==
name: print "DEVICE FOUND, setting ID" device_id = device["id"]
NOW THAT WE HAVE THE DEVICE ID WE NEED TO GET ALL THE INTERFACES
interfaces = connect.interfaceGET(headers,uuid,server,device id)
Interfaces i want to change interface_1 = "GigabitEthernet0/0" interface_2 = "GigabitEthernet0/1"
for interface in interfaces["items"]: if interface["name"] == interface_1: interface_1_id =
interface["id"] print "interface 1 found" if interface["name"] == interface_2: interface_2_id =
interface["id"] print "interface 2 found"
user_input = str(raw_input("Would you like to configure device interfaces? [y/n]"))
if user_input == "y": interface_put = {
"type": "PhysicalInterface",
"hardware": {
"duplex": "AUTO",
"speed": "AUTO"
},
Cisco dCloud
"enabled": True,
"MTU": 1500,
"managementOnly": False,
"ifname": "outside",
"enableAntiSpoofing": False,
"name": "GigabitEthernet0/0",
"id": interface 1 id,
"ipv4" : {
"static": {
"address":"198.18.133.2",
"netmask":"18"
}
}
}
put_data = json.dumps(interface_put)
connect.interfacePUT (headers, uuid, server, put_data,device_id,interface_1_id) interface_put = {
"type": "PhysicalInterface",
"hardware": {
"duplex": "AUTO",
"speed": "AUTO"
},
"enabled": True,
"MTU": 1500,
"managementOnly": False,
"ifname": "inside", "enableAntiSpoofing": False,
"name": "GigabitEthernet0/1",
"id": interface_2_id,
"ipv4" : {
"static": {
"address":"198.19.10.1",
"netmask":"24"
}
}
}
put_data = json.dumps(interface_put)
connect.interfacePUT (headers, uuid, server, put data,device id,interface 2 id)
Python script connect.py

#!/usr/bin/python import json import sys import requests
#Surpress HTTPS insecure errors for cleaner output
from requests.packages.urllib3.exceptions import InsecureRequestWarning
requests.packages.urllib3.disable_warnings(InsecureRequestWarning)
#define fuction to connect to the FMC API and generate authentication token def connect (host, username,
password): headers = {'Content-Type': 'application/json'} path =
"/api/fmc_platform/v1/auth/generatetoken" server = "https://"+host url = server + path try:
r = requests.post(url, headers=headers, auth=requests.auth.HTTPBasicAuth(username,password),
verify=False) auth_headers = r.headers
token = auth_headers.get('X-auth-access-token', default=None) uuid = auth headers.get('DOMAIN UUID',
default=None) if token == None:
print("No Token found, I'll be back terminating....") sys.exit()
except Exception as err:
print ("Error in generating token --> "+ str(err)) sys.exit()
headers['X-auth-access-token'] = token return headers,uuid,server
def devicePOST (headers, uuid, server, post_data): api_path= "/api/fmc_config/v1/domain/" + uuid +
"/devices/devicerecords url = server+api_path try:
r = requests.post(url, data=post_data, headers=headers, verify=False) status_code = r.status_code resp =
r.text
json_response = json.loads(resp) print("status code is: "+ str(status code)) if status_code == 201 or
status_code == 202: print("Post was sucessfull...") else:
Cisco dCloud
r.raise_for_status()
print("error occured in POST -->"+resp)
except requests.exceptions.HTTPError as err:
print ("Error in connection --> "+str(err))
finally:
if r: r.close()
return json response
def deviceGET (headers, uuid, server): api_path= "/api/fmc_config/v1/domain/" + uuid +
"/devices/devicerecords" url = server+api_path try:
r = requests.get(url, headers=headers, verify=False) status_code = r.status_code resp = r.text
json_response = json.loads(resp) print("status code is: "+ str(status_code)) if status_code == 200:
print("GET was sucessfull...") else:
finally:
if r: r.close()
return json_response
def interfaceGET (headers, uuid, server, device_id):
api_path= "/api/fmc_config/v1/domain/" + uuid + "/devices/devicerecords/"+device
id+"/physicalinterfaces" url = server+api_path try:
r = requests.get(url, headers=headers, verify=False) status_code = r.status_code resp = r.text
json_response = json.loads(resp) print("status code is: "+ str(status_code)) if status_code == 200:
print("GET was sucessfull...") else:
finally:
if r: r.close()
def interfacePUT (headers, uuid, server, put_data,device_id, interface_id):
api_path= "/api/fmc_config/v1/domain/" + uuid +
"/devices/devicerecords/"+device_id+"/physicalinterfaces/"+interface_id
url = server+api_path try:
r = requests.put(url, data=put_data, headers=headers, verify=False) status_code = r.status_code resp =
r.text
json_response = json.loads(resp) print("status code is: " + str(status_code)) if status_code == 200 :
print("Put was sucessfull...") else:
finally:
if r: r.close()
def accesspolicyPOST (headers, uuid, server, post_data):
api_path= "/api/fmc_config/v1/domain/" + uuid + "/policy/accesspolicies"
url = server+api_path
try:
r = requests.post(url, data=json.dumps(post_data), headers=headers, verify=False) status_code =
r.status_code resp = r.text
json_response = json.loads(resp) print("status code is: "+ str(status_code)) if status_code == 201 or
status_code == 202: print("Post was sucessfull...")
else:
print("error occured in POST -->"+resp) except requests.exceptions.HTTPError as err:
print ("Error in connection --> "+str(err)) finally:
if r: r.close() return json_response
Cisco dCloud
Appendix C. ISE RA VPN Configuration

ISE was configured to support all the lab exercises. In this appendix, this configuration is summarized. Note that there is an ISE
link on the Firefox bookmarks toolbar. The credentials should prepopulate. They are username admin, password cisco12345.
NOTE: This appendix is not a tutorial on ISE. It does not go into details about how ISE is configured. It only covers the details
required to configure RA VPN components for the lab exercises in this guide. The configurations are described in a top-down
manor. To create this configuration, you would probably prefer to build these objects from the bottom-up.
Authorization policies
1. Navigate to Policy > Authorization. The first two policies were created for this lab: AC-IT-Policy and AC-Default-Policy.
These policies reference two authorization profiles: AC-Auth-IT and AC-Auth-Default.
Authorization profiles
1. Navigate to Policy > Policy Elements > Results > Authorization > Authorization Profiles. The first two profiles were created
for this lab: AC-Auth-Default and AC-Auth-IT.
2. If you drill down into AC-Auth-Default, you will see that it references the DACL AC-DACL-Default, described below.
3. If you drill down into AC-Auth-IT, you will see that it references the DACL AC-DACL-IT, described below. It also has two
advanced attributes: one for the address pool, and one for the group policy.
Downloadable ACLs
1. Navigate to Policy > Policy Elements > Authorization > Downloadable ACLs. The first two DACLs were created for this
lab: AC-DACL-Default and AC-DACL-IT.
Cisco dCloud
2. If you drill down into AC-DACL-Default, you will see that it restricts access to 198.19.10.100 and 198.19.10.200.
3. If you drill down into AC-DACL-IT, you will see that there are no restrictions.
Cisco dCloud

Firepower NGFW Labpdf PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Firepower NGFW Labpdf PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Cisco dCloud

Cisco Firepower Next-Generation Firewall 6.2 Advanced

About This Demonstration

• About This Solution

• Scenario 1: Integrated Routing and Bridging (IRB)

• Scenario 2: High Availability Configuration

• Scenario 3: AnyConnect Remote Access VPN

• Scenario 4: AnyConnect with RADIUS Attributes

• Scenario 5: Site-to-Site VPN

• Scenario 6: Monitoring and Troubleshooting

• Scenario 7: Cisco Threat Intelligence Director (CTID)

• Scenario 8: ASA to NGFW Migration (Optional)

• Scenario 9: ASA to NGFW Migration (Optional)

• Appendix A: FMC Pre-configuration

• Appendix B: REST API Scripts

• Appendix C: ISE RA VPN Configuration

● Laptop ● Cisco AnyConnect®

About This Solution

Figure 1. dCloud Topology

PREPARATION IS KEY TO A SUCCESSFUL PRESENTATION.

1. Initiate your dCloud session. [Show Me How]

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

• Workstation 1: 198.18.133.36, Username: administrator, Password: C1sco12345

Scenario 1. Integrated Routing and Bridging (IRB)

• Create the objects needed for this lab exercise

• Modify the NGFW interface configuration

• Modify the NAT policy

• Modify the access control policy

• Deploy and test the configuration

Create the Object

Create the object needed for this lab exercise:

2. Click Log In.

a. Click Add > Security Zone.

Modify the NGFW interface configuration

1. Navigate to Devices > Device Management.

b. Click on the pencil icon to edit the GigabitEthernet0/1 interface.

d. Click Add Interfaces, and select Bridge Group Interface.

e. For Name enter insideBVi.

f. For Bridge Group ID, enter 1.

g. Select GigabitEthernet0/1 and GigabitEthernet0/2, and click Add.

h. Select the IPv4 tab, and enter the IP address 198.19.10.1/24.

2. Click on the pencil icon to edit the GigabitEthernet0/1 interface.

a. For Name enter inside1.

b. Confirm that the Enabled checkbox is checked.

c. Select BVIZone from the Security Zone drop-down list.

3. Click on the pencil icon to edit the GigabitEthernet0/2 interface.

a. For Name enter inside2.

b. Check the Enabled checkbox.

c. Select BVIZone from the Security Zone drop-down list.

4. Click Save to save the device configuration.

Modify the NAT policy

a. Click Add > Interface Group.

b. For NAME, enter inZone1.

c. For Interface Type, select Switched.

d. Select the interface inside1, and click Add.

2. Navigate to Devices > NAT.

3. Edit the Default PAT policy.

b. Replace InZone with BVIZone in every other rule.

c. Click Save to save the NAT policy.

Modify the access control policy

1. Navigate to Policies > Access Control > Access Control.

2. Select Base_Policy and edit the access control policy.

a. Replace InZone with BVIZone in every rule.