Cisco dCloud
Cisco Firepower Next-Generation Firewall 6.7 Basics Lab
v1.7 (WIP by Nazmul)
dCloud: The Cisco Demo Cloud
Last Updated: 09-Mar-2021
IMPORTANT! This content is community developed and is not subject to standard dCloud verification or support. Please
contact dCloud Support for more information.
REQUIREMENTS
2
ABOUT THIS SOLUTION
2
TOPOLOGY
3
GET STARTED
4
SCENARIO 1.
BASIC CONFIGURATION AND VERIFICATION OF SETTINGS
SCENARIO 2.
FLEXCONFIG
39
SCENARIO 3.
NAT AND ROUTING
46
SCENARIO 4.
PREFILTER POLICIES
60
SCENARIO 5.
DEVICE DEPLOYMENT WITH THE REST API
68
SCENARIO 6.
BASIC CONFIGURATION USING FDM
72
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
5
Page 1 of 78
Cisco dCloud
Requirements
The table below outlines the requirements for this preconfigured demonstration.
Table 1.
dCloud: The Cisco Demo Cloud
Requirements
Required
● Laptop
Optional
● Cisco AnyConnect®
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-todetection (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 a branch site.
Using the Firepower Management Center (FMC) you will configure and manage an NGFW’s at the corporate and branch sites. In
this lab, you will also configure an NGFW using the Firepower Device Manager (FDM). You will configure an NGFW using an
automation script and the REST API. You will also configure FlexConfig for adding commands to the LINA plane that are not available
on the FMC GUI, NAT (Network Address Translation), routing, and Prefilter policies to analyze traffic carried inside of tunnels.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 2 of 78
Cisco dCloud
Topology
This content includes preconfigured users and components to illustrate the scripted scenarios and features of the solution. Most
dCloud: The Cisco Demo Cloud
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
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 3 of 78
Cisco dCloud
Get Started
BEFORE PRESENTING
dCloud: The Cisco Demo Cloud
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]
•
Jump PC 1: 198.18.133.50, 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.
3.
From the jumpbox, open Firefox. It should open with FMC login page as the default page. The login name and password will
be prepopulated. Click Login.
4.
Alternatively, open the Quick Launch from the task bar, and click the FMC Web to login to the GUI of the FMC automatically.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 4 of 78
Cisco dCloud
Scenario 1.
Basic Configuration and verification of settings
This exercise consists of the following tasks:
•
Verify and create objects needed for the exercise
•
Modify the access control policy
•
Create NAT policies
•
Configure Branch1 FTD Using FMC
•
Configure FTD Using FDM
•
Deploy the Configuration changes
•
Modify the network discovery policy
•
Deploy the configuration changes
dCloud: The Cisco Demo Cloud
The objective of this exercise is to deploy a simple, but effective, NGFW configuration:
•
Allow outbound connections, and block other connection attempts
•
Perform file type and malware blocking on these outbound connections
•
Provide intrusion prevention on these outbound connections
NOTE: Some of these device specific configurations (Interfaces, Routing, Access Control Policy, NAT policy) are already done since
NGFW1 is already registered and managed by the FMC. We are going to review existing objects first and configure any required
objects.
Steps
Review and verify objects needed for the exercise
1.
On the FMC, select Objects > Object Management. This brings up the Network Object Page.
a. In the Filter bar to the right enter lab.
b. It should show an object with the following details:
• Name: Lab_Networks.
• Value: 198.18.0.0/15. This includes all IP addresses used in the lab pod.
• Type: Network
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 5 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
2.
Select Interface from the left navigation panel. Verify there should be security zones configured as shown below in the
screenshot:
NOTE: There are two types of interface objects: security zones and interface groups. The key difference is that interface groups can
overlap. Only security zones can be used in access control policy rules.
Review the interface and routing configuration of the device
1.
In the FMC, select Devices > Device Management. Click on the pencil icon to edit the NGFW1 device settings.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 6 of 78
Cisco dCloud
2.
The Interfaces tab should be selected by default. Review the interface configuration of the NGFW1. The Security Zones,
interface names and the IP addresses should be configured as shown in the screenshot below:
dCloud: The Cisco Demo Cloud
3.
Select Routing > Static Route and click on the Pencil icon next to the default route. Verify the below settings:
a. Interface outside is selected in the Interface field.
b. any-ipv4 in the Selected Network (This is the equivalent of a default route i.e. 0/0).
4.
For Gateway the Network IP Address is 198.18.128.1 (This is the next hop on the outside interface of the Firewall facing the
WAN).
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 7 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
5.
Click OK .
6.
Click Save.
Modify the access control policy
1.
From the menu, select Policies > Access Control > Access Control. Click on New Policy.
2.
Create a New policy named NGFW_Policy and under available devices, select NGFW1.
3.
Click Add to Policy.
4.
Click Save.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 8 of 78
Cisco dCloud
NOTE: As the Access Control Policy Base_Policy is already assigned to NGFW1, the FMC will show a warning about reassigning
policies for the device NGFW1. For completing other lab guides, the previously configured policy Base_Policy needs to be
reassigned to the NGFW1.
5.
dCloud: The Cisco Demo Cloud
Add a rule to the Access Control Policy to allow inbound traffic to a Splunk Server
a. Click the + Add Rule button.
b. For Name, enter Splunk Access
c. Select into Mandatory from the Insert drop-down list.
d. Select action as Allow
e. Add Zone information - The direction of the connection is inbound so we will allow traffic inbound.
• Select InZone1, and click Add to Destination.
• Select OutZone, and click Add to Source.
f. Select the Networks tab to enter the source and destination information
• Search for SplunkInside in the Available Networks list
• Click Add to Destination
g. Click Add to add the rule.
Note: This rule is for lab purposes only. Normally, it is recommended to restrict the access to the internal logging server.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 9 of 78
Cisco dCloud
6.
Add a rule to the Access Control Policy to allow outbound internet access
a. Click the + Add Rule button.
b. For Name, enter Allow Outbound Connections.
dCloud: The Cisco Demo Cloud
c. Select into Default from the Insert drop-down list.
NOTE: Rules are divided into sets within a policy. Two sets are predefined:
Mandatory rules, which take precedent over rules of child policies
Default rules, which are evaluated after the rules of child policies
In this exercise, you will not create a child policy, but you will use the default rule set as a convenient way of making sure this rule
is evaluated last. Here we are creating a rule to specifically allow outbound internet traffic as the default action of the Access
Control Policy is to Block All Traffic.
7.
The Zones tab should already be selected.
a. Select InZone1, and click Add to Source.
b. Select OutZone, and click Add to Destination.
8.
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.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 10 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
NOTE: The demo intrusion and file policies were pre-configured to save you time. See Appendix 1 in the Firepower Advanced Lab
Guide v2.5 for instructions on how to create these.
9.
Click Logging and select Log at End of Connection.
Note: You can log a connection at its beginning or its end, with the following exceptions for blocked traffic:
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 11 of 78
Cisco dCloud
Blocked traffic—Because blocked traffic is immediately denied without further inspection, usually you can log only beginning-ofconnection events for blocked or blacklisted traffic. There is no unique end of connection to log.
dCloud: The Cisco Demo Cloud
Blocked encrypted traffic—When you enable connection logging in an SSL policy, the system logs end-of-connection rather than
beginning-of-connection events. This is because the system cannot determine if a connection is encrypted using the first packet in
the session, and thus cannot immediately block encrypted sessions.
To optimize performance, log either the beginning or the end of any connection, but not both. In general, it makes sense to log only
End of connection as it contains all the information about the connection.
10. Click Add to add the rule.
11. Go to the HTTP Responses tab. Ensure that the System-provided is selected from the Block Response Page drop-down
list.
12. Go to the Advanced tab.
13. Ensure that the Maximum Active Responses is set to 25 under the Transport/Network Layer Preprocessor Settings.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 12 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
NOTE: Setting Maximum Active Responses to a value greater than 0 enables the Intrusion Policy drop (IPS) rules that drop
packets to send TCP resets to close the connection. Connections that do not trigger an IPS drop will be reset by the FTD if “block
with reset” is applied to the rule regardless of the settings of Maximum Active Responses or if it is a LINA-only drop such as a
Fastpath block. Typically, both the client and server are sent TCP resets. With the configuration above, the system can initiate up
to 25 active responses (TCP Resets) if it sees additional traffic from this connection.
In a production deployment, it is probably best to leave this set to the default. Then no resets are sent, and the malicious system
will not know that it has been detected. But for testing and demonstrations, it is generally better to send resets when packets match
drop rules.
14. Click Save at the top right to save the changes to the access control policy.
Create a Dynamic NAT rule in NAT policy
We are creating this NAT policy rule to allow outbound internet access using dynamic PAT.
1.
From the menu, select Devices > NAT.
2.
Click the New Policy button, and select Threat Defense NAT.
NOTE: The other kind of NAT called Firepower NAT which is used for the legacy Firepower appliances. It is not applicable for the
FTD devices.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 13 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
3.
For Name, enter Default PAT.
4.
Select the NGFW1. Click Add to Policy and then click Save. Click Yes on the popup.
NOTE: As the NAT Policy Default NAT Policy is already assigned to NGFW1, the FMC will show a warning about reassigning
policies for the device NGFW1. For completing other lab guides, the policy Default NAT Policy needs to be reassigned to the
NGFW1.
5.
Click Add Rule.
6.
Select In Category and NAT Rules After from the Insert drop-down lists. This will ensure that this rule will be evaluated after
the auto-NAT (object NAT) rules.
7.
Select Dynamic from the Type drop-down list.
a. You will be at the Interface Objects tab. Select InZone1 and click Add to Source.
b. Select OutZone and click Add to Destination.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 14 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
8.
Select the Translation tab.
a. Select any from the Original Source drop-down list.
b. Select Destination Interface IP from the Translated Source drop-down list.
c. Click OK to save the NAT rule.
d. Click Save to the NAT Policy.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 15 of 78
Cisco dCloud
NOTE: This rule will PAT translate the traffic originating from any source IP behind the inside interface to the Interface IP of the
outside interface of the NGFW1.
dCloud: The Cisco Demo Cloud
Static NAT Policy for FMC
NOTE: We are performing this task now, but this NAT Policy will not be used until Branch 1 is brought online in a later section.
The FMC is behind the NGFW1, which is acting as a NAT device. We need to build a static NAT Policy so that the Branch FTD will
be able to communicate with the HQ-FMC.
1.
Click on Add Rule.
2.
NAT Rule: Select Auto NAT Rule.
3.
Under Interface Objects, select InZone1 and Add to Source.
4.
Select OutZone and Add to Destination.
5.
Click on Translation and click the (+) sign next to Original Source and add the name FMC_Private.
6.
For Host enter 198.19.10.120 (This is the address of the HQ-FMC).
7.
Click Save and then select FMC_Private for Original Source.
8.
Click on the (+) sign next to the Translated Source and add the name FMC_Public.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 16 of 78
Cisco dCloud
9.
For Host enter 198.18.133.120 (An address on the WAN network). Click Save then select FMC_Public for Translated
Source.
10. Then Click OK.
dCloud: The Cisco Demo Cloud
11. Click Save.
NOTE: The screenshot above shows the NAT Rules you just created.
12. Create an Inbound Access List for the Private FMC modifying the Access Control Policy NGFW_Policy.
a. Select Policies > Access Control > Access Control.
b. Click on the pencil icon by NGFW_Policy.
c. Add rule called FMC_Static_NAT.
d. Action Allow.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 17 of 78
Cisco dCloud
e. Zones Tab
• Source Zone: OutZone,
• Destination Zone: InZone1.
dCloud: The Cisco Demo Cloud
f. Networks Tab
• Destination networks FMC_Private.
g. Inspection Tab.
• Intrusion Policy Demo Intrusion Policy.
• File Policy Demo File Policy.
h. Click Add and Save.
NOTE: The above Static Nat and Access Policy Configuration was done in order to allow inbound access to the FMC from the
Branch NGFW. The traffic between the Branch NGFW and the FMC passes inline through the NGFW1. As you will notice that the
Access Policy Rule has been added to allow traffic inbound (Outside to Inside) to the Private IP of the FMC. This is because in the
packet processing path, the NAT un-translation from Public FMC IP to Private FMC IP is done before the Access rule processing.
Static NAT for Inbound Webserver Access
1.
From the menu, select Devices > NAT. Click the Pencil icon next to the NAT policy Default PAT.
2.
Click Add Rule.
a. Select Auto NAT Rule and Static from the Type drop-down list.
b. At the Interface Objects tab. Select InZone1, and click Add to Source.
c. Select OutZone, and click Add to Destination.
3.
Select the Translation tab.
a. Select wwwin from the Original Source drop-down list.
b. Select Address and wwwout from the Translated Source drop-down list.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 18 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
c. Click OK to save the NAT rule.
4.
Click Save to save the NAT policy.
Modify Network Discovery Policy
The default network discovery policy is configured to discover all applications, both internal and external. We will want to add host
and user discovery. In a production environment, this can exceed the FMC Firepower host license. For this reason, it is best
practice to modify the policy.
1.
From the menu, select Policies > Network Discovery.
a. Click the pencil icon to the right to edit the existing rule.
b. Make sure that the Users checkbox is checked. The Hosts and Applicantions checkbox should be auto-checked.
c. Add the Lab_Networks to the list of Networks.
d. Click Save.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 19 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
Deploy Changes
1.
Confirm that NGFW settings, NAT policy network discovery, interface and static route configuration will be modified.
2.
Click Deploy in the upper right-hand corner of the FMC.
a. Check the box for the NGFW(s) device and expand the list to see the details. In addition, you will see what will cause the
interruption. The interruption is caused due to SNORT restart for adding some policy changes such as File Policy
updates.
b. Click Deploy.
c. You can view the progress and various stages of the deployment.
d. The deployment status will be shown as Completed upon completion.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 20 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
Test the NGFW connectivity
We will be leveraging the PUTTY client on the Jumbox for testing the connectivity.
1.
Using the PUTTY client on the Jumpbox, login to the Inside Linux Server CLI, login with credentials root/C1sco12345:
a. Enter wget cisco.com. This should succeed. This confirms NAT and routing.
b. Enter ping outside. This should succeed. Enter Ctrl+C to exit ping.
2.
To test inbound connectivity from outside to inside, open a Putty Connection to the Outside Linux Server from the Jumpbox.
a. Login as root/C1sco12345
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 21 of 78
Cisco dCloud
b. Ping 198.18.133.120 (Outside NAT Address of the FMC).
c. Use Ctrl + C to stop the pinging.
d. Minimize the Putty session.
3.
dCloud: The Cisco Demo Cloud
Troubleshooting if the connectivity fails:
a. Verify that the Access-Control policies and NAT policies are configured on the FMC as shown in the screenshots.
b. Verify the following connectivity in steps:
• Inside Linux Server to inside interface of NGFW– ping 198.19.10.1 should be successful
• Outside interface of NGFW to outside – ping 198.18.133.200 should be successful
• Verify the arp table of the Linux server using arp -a and the NGFW1 using the NGFW CLI command show arp
c. Check the default route on the NGFW1 using the CLI command show route. The route command should point towards
198.18.128.1 as the default gateway.
d. Check the output of packet-tracer from the FMC UI.
• Navigate to the Device > Device Management page. Select Packet Tracer for the NGFW1, as show below.
The Advanced Troubleshooting page appears.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 22 of 78
Cisco dCloud
• On the Advanced Troubleshooting page, click on the tab Packet Tracer. Enter the details as shown in the
screenshot below. The output should show that the packet is allowed. If it is dropped in the Access-list phase,
it means that the Access Control Policy is not configured properly. If it is not showing a matching NAT rule, it
means that the NAT policy is configured incorrectly.
dCloud: The Cisco Demo Cloud
NOTE: Packet-tracer is a simulation tool which simulates a packet based on the input parameters and shows all the policies/rules
the packet matches from ingress to egress. This screenshot shows a packet-tracer run for ICMP echo request packet from SRC
198.19.10.100 to DST 198.18.133.200
e. If the packet-tracer shows allow and it is not working, we can check the output of system support trace from the NGFW
CLI. Here is an example showing a trace for ICMP protocol. Additional filter related to IP and protocol can be added.
> system support trace
Enable firewall-engine-debug too? [n]: y
Please specify an IP protocol: icmp
Please specify a client IP address:
Please specify a server IP address:
Monitoring packet tracer and firewall debug messages
198.19.10.200-0 - 198.18.133.200-8 1 Packet: ICMP
198.19.10.200-0 - 198.18.133.200-8 1 Session: new snort session
198.19.10.200-8 > 198.18.133.200-0 1 AS 1 I 0 new firewall session
198.19.10.200-8 > 198.18.133.200-0 1 AS 1 I 0 using HW or preset rule order 2, 'Allow Outbound
Connections', action Allow and prefilter rule 0
198.19.10.200-8 > 198.18.133.200-0 1 AS 1 I 0 HitCount data sent for rule id: 268439553,
198.19.10.200-8 > 198.18.133.200-0 1 AS 1 I 0 allow action
198.19.10.200-0 - 198.18.133.200-8 1 Firewall: allow rule, 'Allow Outbound Connections', allow
198.19.10.200-0 - 198.18.133.200-8 1 Snort id 0, NAP id 2, IPS id 1, Verdict PASS
198.18.133.200-0 - 198.19.10.200-8 1 Packet: ICMP
198.18.133.200-0 - 198.19.10.200-8 1 Firewall: allow rule, 'Allow Outbound Connections', allow
198.18.133.200-0 - 198.19.10.200-8 1 Snort id 0, NAP id 2, IPS id 1, Verdict PASS
198.19.10.200-0 - 198.18.133.200-8 1 Packet: ICMP
198.19.10.200-0 - 198.18.133.200-0 1 Session: deleting snort session, reason: stale and not cleaned
198.19.10.200-8 > 198.18.133.200-0 1 AS 1 I 0 deleting firewall session flags = 0x14001, fwFlags = 0x100
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 23 of 78
Cisco dCloud
198.19.10.200-8 > 198.18.133.200-0 1 AS 1 I 0 Logging EOF as part of session delete with rule_id =
268439553 ruleAction = 2 ruleReason = 0
198.19.10.200-0 - 198.18.133.200-0 1 Session: deleted snort session using 0 bytes; protocol id:(0) :
LWstate 0x0 LWFlags 0x7
dCloud: The Cisco Demo Cloud
198.19.10.200-0 - 198.18.133.200-8 1 Session: new snort session
198.19.10.200-8 > 198.18.133.200-0 1 AS 1 I 0 new firewall session
198.19.10.200-8 > 198.18.133.200-0 1 AS 1 I 0 using HW or preset rule order 2, 'Allow Outbound
Connections', action Allow and prefilter rule 0
198.19.10.200-8 > 198.18.133.200-0 1 AS 1 I 0 HitCount data sent for rule id: 268439553,
198.19.10.200-8 > 198.18.133.200-0 1 AS 1 I 0 allow action
198.19.10.200-0 - 198.18.133.200-8 1 Firewall: allow rule, 'Allow Outbound Connections', allow
198.19.10.200-0 - 198.18.133.200-8 1 Snort id 0, NAP id 2, IPS id 1, Verdict PASS
>
Utilize hit count
You can use the FMC to determine the rules that are being hit most by an FTD device. Both Access Control and Prefilter policy
editor pages provide this option. For example, to view the hit counts of an Access Control policy,
1.
Open the Access Control policy.
2.
Click Analyze Hit Count in the upper right corner of the policy editor page.
3.
Select the desired device and click Fetch Current Hit Count.
4.
Verify the following functionality.
a.
You can add and delete columns by clicking on the gear icon. The First Hit Time column is missing by default.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 24 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
b.
You can Filter to display only the hit rules or the never hit rules.
c.
Also, you can Filter rules by clicking on the spy-glass icon.
d.
Right-clicking on a rule name displays the option to clear the rule count for that rule.
e.
The rule names are links, allowing you to click on the rule name to navigate to the rule in the prefilter policy.
NOTE: If you are chcking the hit count for the prefilter rules, you my find the hit count for rules with analyze action are zero,
because hit count is only maintained for rules with fastpath or block actions.
Test the IPS functionality of NGFW deployment
1.
On the Inside Linux Server CLI, enter ftp outside. Login as guest, password C1sco12345
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 25 of 78
Cisco dCloud
2.
Enter cd ~root. You should see the following message: 421 Service not available, remote server has closed
connection. This confirms that IPS is working.
dCloud: The Cisco Demo Cloud
NOTE: If the FTP session hangs, you probably forgot to enable active responses in the access control policy. You need not fix this,
as long as you remember to expect this behavior.
3.
Type quit to exit FTP.
4.
In the FMC, select Analysis > Intrusions > Events.
NOTE: Observe that Snort rule 336 was triggered. In the Demo Intrusion Policy, the rule state for this rule is set to Drop and
Generate Events. This rule is disabled in the system-defined intrusion policies such as Balanced Security and Connectivity.
5.
To view more detail information about the event, go to the Table View of Events tab.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 26 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
NOTE: In a production environment, if you run into a situation where events are not appearing, the first thing you should check is
the time synchronization between the NGFW and FMC. However, in this lab, it is more likely to be an issue with the eventing
processes. If this happens, try restarting these processes as follows.
On the NGFW CLI run the following command.
pmtool restartbytype EventProcessor
From the Jump desktop, connect to the FMC using the pre-defined PuTTY session. Login as admin/C1sco12345 and run the
following commands. The sudo password is C1sco12345
sudo pmtool restartbyid SFDataCorrelator
sudo pmtool restartbyid sftunnel
6.
Click the arrow on the left to drill down to the table view of the events. Observe that details of the event are presented.
a. Click the arrow on the left of the event to drill down further. Note that you are presented with extensive information,
including the details of the Snort rule.
b. Expand the Actions and note that you could disable the rule from here - but do not!
c. You can view the packet details also which triggered the IPS event.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 27 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
Test the file and malware blocking capabilities with NGFW1.
These wget commands can be cut and pasted from the text file on the Jump desktop called Strings to cut and paste.
1.
From the Inside Linux Server:
a. As a control test, use WGET to download a file that is not blocked. wget -t 1 outside/files/ProjectX.pdf. This should
succeed with 100% download.
b. Next use WGET to attempt to download the file blocked by type: wget -t 1 outside/files/test3.avi. This should start
download and fail right away.
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.
c. Finally use WGET to attempt to download malware. wget -t 1 outside/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.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 28 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
2.
In the FMC, select Analysis > Files > Malware Events.
a. Observe that one file, Zombies.pdf, was blocked.
b. Click the arrow on the left to drill down to the table view of the events. Note that the host 198.19.10.200 is represented by
a red icon. This is the Inside Linux Server. The red icon means the host has been assigned an indication of compromise.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 29 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
NOTE: The action is reported as Custom Detection Block, instead of Malware Block. This is because we added Zombies.pdf to the
custom detection list, just in case the lab has issues connecting to the cloud. See Appendix 1 for details.
3.
As an alternative, you can try the following from the inside Linux server:
wget -t 1 outside/malware/Buddy.exe
This should be reported as a Malware Block. However, in this particular lab environment, the cloud lookup may fail. Therefore, the
file may not be blocked.
4.
Click on the red computer icon. This will open the host profile page. Look over this page and then close it.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 30 of 78
Cisco dCloud
5.
From the menu, select Analysis > Files > File Events. You should see information about all the file events for the recently
attempted connection.
dCloud: The Cisco Demo Cloud
6.
If the Events don’t show up as expected, verify that the IPS policy and File Policy has been attached to the Access Policy Rule
named Allow Outbound Connections. Refresh the events page, as the events might take some time to populate in this lab
environment.
NOTE: You can drill down if you wish.
Adding FTD Branch 1 to network (Optional as the NGFWBR1 is already added to the FMC )
NOTE: This section is optional as the NGFWBR1 is already added to the FMC. You can verify if the configuration is present.
However, if you wish to configure from scratch, we need to unregister the NGFWBR1 from the FMC using the delete button.
For removing the NGFWBR1 from FMC, navigate to Devices > Device Management. Select the Delete option next to the device
name. Click Yes to confirm. This will delete/unregister the Branch 1 FTD from the FMC management.
1.
Earlier we created a Static NAT entry for the FMC: 198.18.133.120.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 31 of 78
Cisco dCloud
2.
Now we will configure NGFW Branch 1 so it will also be managed by the FMC.
3.
On the Jump PC Open the Putty Connection to NGFWBR1 (198.18.133.42: 22) Login admin Password C1sco12345
4.
Type show managers. The response is No mangers configured.
5.
Type the following command configure manager add 198.18.133.120 C1sco12345 abcde
dCloud: The Cisco Demo Cloud
NOTE: You need to add the FMC’s NAT Address and also a specific NAT ID (in this case abcde). The NAT ID will need to match
with the NAT ID on the FMC when you go through the NGFW registration process.
6.
Go back to the FMC webpage and go to Devices > Device Management > Add > Add Device.
a. For host, enter 198.18.133.42
b. For display name, enter NGFWBR1
c. For registration key, enter C1sco12345
7.
Under Access Control Policy, select the down arrow and choose Create New Policy.
8.
Name: Branch1access Select Base Policy: None Default Action: Block all traffic. Click Save.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 32 of 78
Cisco dCloud
9.
Select Branch1Access.
a. Under Smart Licensing: Check all boxes
b. Under Advanced Type the NAT code from the FTD: abcde.
dCloud: The Cisco Demo Cloud
10. Click Register.
11. Wait until the NGFWBR1 has registered.
NOTE: The NGFWBR1 was already configured and managed by the FMC. Deleting the device from the FMC does not delete
configuration like Interface address and name. However, zone membership needs to be reconfigured. Now that the NGFWBR1
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 33 of 78
Cisco dCloud
has been added, we will build the interface configuration, configure the default route, create a NAT policy and update the Access
Policy.
12. Click on the pencil icon next to the NGFWBR1.
dCloud: The Cisco Demo Cloud
13. Click on the pencil icon on the GigabitEthernet0/0 interface.
a. The interface name is pre-configured as Outside.
b. Configure the Zone membership. Under Security Zone: Click New, Enter a name: branch1_Outzone.
c. Select the IPv4 address tab. You will see that the IP Address has been preconfigured
1. 198.18.128.81/255.255.192.0. This is the address of the Outside WAN (ISP).
2. Click OK
NOTE: In this scenario, we used 198.18.133.42/18 for the Management IP Address of the Firewall. You can see this address by
entering the show network command from the command line or by going to expert mode on the FTD and run the ifconfig
command and look at the br1 interface. The Management IP Address is accessible only to the Operating System. We therefore
have to build a WAN interface as an outside interface. The Outside Interface can also be configured by DHCP from the ISP, we did
not want to add an additional server to this lab scenario.
14. Repeat for GigabitEthernet0/1 line with Name: Inside, Security Zone: Click New and Enter a name: InZone
15. You can verify that the IP Address 198.19.11.1/24 is already configured on this interface.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 34 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
16. Click Save at the top of the Web page.
17. Go to Routing >Static Route > Add Route > to build a Static route to the Internet.
18. Select Interface outside.
19. For Available Network, select any-ipv4
a. For Gateway. Click the + button and configure the New Network Object:
b. Name: Branch1-WAN-GW
c. Host: 198.18.128.1.
d. Click Save.
20. Click OK
NOTE: If the Interface outside does not show up in the pull-down box, make sure you clicked on the save button and saved the
changes after making the zone assignments.
21. When done, click Save at the top of the web page.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 35 of 78
Cisco dCloud
22. Go to Devices NAT > New Policy > Threat Defense NAT.
23. Name the Policy Branch1_NAT_Policy and under available devices select NGFWBR1.
24. Click Add to Policy.
dCloud: The Cisco Demo Cloud
25. Click Save.
26. Click to Add Rule.
27. Select Auto NAT Rule under NAT rule and Type: Dynamic.
28. Under Interface Objects,
a. select InZone. Click Add to Source.
b. select branch1_Outzone. Click Add to Destination.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 36 of 78
Cisco dCloud
29. On the Translation Tab under Original Source, select the (+) and configure New Network with the details as :
dCloud: The Cisco Demo Cloud
a. Object Name: Branch1_Networks
b. Select Network radio button.
c. Network: 198.19.11.0/24 (You could also use/create an Object in the Objects Page that would encompass an entire lab
network group such as 198.18.0.0/15).
d. Click Save.
e. From the drop down under Original Source, select the newly created object Branch1_Networks
30. On Translated Packet, select Destination Interface IP.
31. Select OK and then Save at the top of the web page.
32. To modify the Access Control Policy, go to Policies > Access Control > Access Control
33. Click on the pencil icon to edit the Branch1access Policy
34. Click on Add Rule
a. Name the rule Branch1Allow.
b. The Zones tab should be selected by default. Select InZone for Source and branch1_OutZone for destination
c. Click on Inspection tab. For Inspection Policy, Select Demo Intrusion Policy and for File Policy, select Demo File
Policy.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 37 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
35. Click on Add Click on Save at the top of the web page.
36. Go to the Deploy > Deployment page. Select NGFWBR1, and click the Deploy button.
NOTE: The above NAT and Access Policy rules have been added to allow outbound internet access from the Branch1 networks.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 38 of 78
Cisco dCloud
Scenario 2.
FlexConfig
This exercise consists of the following tasks.
•
Create a user defined FlexConfig object
•
Modify a Text Object used in a system defined FlexConfig object
•
Create and configure a FlexConfig policy
•
Deploy the changes and test the configuration
dCloud: The Cisco Demo Cloud
FlexConfig is a feature that allows to configure and deploy the configuration features that are not yet available natively in the FTD
using the UI based managers ( FDM or FMC ). There are two objectives for this lab exercise:
1.
Configure EIGRP using a user defined FlexConfig object.
2.
Use a system defined FlexConfig objects to disable SIP inspection.
NOTE: There are separate system defined FlexConfig objects for configuring EIGRP. For configurations that may change over
time, it is better to use these objects. But to demonstrate the simplicity and power of FlexConfig, a user defined FlexConfig object
will be used. System defined FlexConfig Objects will be used to configure the FTD as a source of NetFlow data.
Steps
Create a user defined FlexConfig object
1.
Navigate to the FMC UI, select Objects > Object Management.
2.
On the left navigation panel, under FlexConfig, select FlexConfig Object.
Note: There are many Flex Config Objects that are already pre-configured. Instead of creating new objects, you can choose to use
them by copying and then renaming it.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 39 of 78
Cisco dCloud
3.
Click Add FlexConfig Object.
a. For Name, enter myEIGRP.
b. In the main text area, enter the following commands.
dCloud: The Cisco Demo Cloud
router eigrp 10
network 198.18.128.0 255.255.192.0
c. Click Save.
Modify a Text Object for a system defined FlexConfig object
You should still be on the Object Management page in the FMC UI.
1.
Click on the magnifying glass icon to the right of the Flex Object called Default_Inspection_Protocol_Disable. You cannot
edit this object, but you could copy it if you wanted to.
NOTE: The FlexConfig objects are written in the Apache Velocity language. This language supports loops and if statements.
These begin with a #. This is not a comment. It indicates that the line is not literal text to be included in the output. Comments
begin with ##.That this FlexConfig object loops over a text object called disableInspectProtocolList. You will now edit this text
object.
2.
Click Close.
3.
On the Object Management page, under FlexConfig select Text Object.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 40 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
4.
Edit the text object called disableInspectProtocolList by selecting the pencil icon.
a. This variable takes multiple values. Leave the value set to 1.
b. Enter the value sip.
5.
Click Save.
Create and configure a FlexConfig policy
1.
From the menu, select Devices > FlexConfig. Click New Policy.
a. For Name, enter NGFW1_Test Flex Policy.
b. Select the device NGFW1. Click Add to Policy.
2.
Click Save.
3.
The new policy will open for editing.
a. In the left column, under User Defined, select myEIGRP. Click the arrow to add the FlexConfig object to the policy.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 41 of 78
Cisco dCloud
b. In the left column, under System Defined, select Default_lnspection_Protocol_Disable. Click to add the FlexConfig
object to the policy.
dCloud: The Cisco Demo Cloud
Note: Here the FlexConfig object is added to the Append (default) section. The commands defined by the FlexConfig object will be
appended to the configuration generated by the Firepower Management Center upon deployment. The Prepend section is
normally used for putting FlexConfig object at the beginning of the configurations generated from the Firepower Management
Center policies. E.g. for commands that clear or negate a configuration.
4.
Click Save.
5.
Click Preview Config. Select NGFW1 from the Select Device drop-down list.
a. Wait a few seconds and the configuration changes will appear. Confirm that the commands look correct.
6.
Click Close.
NOTE: It is important to pay attention to the CLI commands generated as a syntax error or incorrect inputs could lead to a
deployment failure.
Deploy the changes and test the configuration
1.
From the jumpbox, open PUTTY client and login to the NGFW1 with the credentials admin/C1sco12345. From the NGFW1
CLI run show running-config policy-map type inspect sip global_policy. Confirm that SIP inspection is enabled by
checking for the command inspect sip
login as: admin
Using keyboard-interactive authentication.
Password:
Last login: Mon Jan 20 17:04:32 UTC 2020 from jump.dcloud.local on pts/0
Copyright 2004-2019, Cisco and/or its affiliates. All rights reserved.
Cisco is a registered trademark of Cisco Systems, Inc.
All other trademarks are property of their respective owners.
Cisco Fire Linux OS v6.5.0 (build 4)
Cisco Firepower Threat Defense for VMWare v6.5.0 (build 115)
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 42 of 78
Cisco dCloud
>
> show running-config policy-map type inspect sip global_policy
!
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect icmp
inspect icmp error
inspect ip-options UM_STATIC_IP_OPTIONS_MAP
class class-default
set connection advanced-options UM_STATIC_TCP_MAP
!
>
dCloud: The Cisco Demo Cloud
2.
From the Inside Linux Server session, type ping 204.44.14.1. This should fail.
3.
Click Deploy. Select NGFW1. You will be presented with a warning pertaining to Flex Configuration Policy. Please read it and
click Proceed. Wait until the deployment is complete.
4.
From the NGFW1 CLI run show running-config policy-map type inspect sip global_policy. Confirm that SIP inspection is
now disabled. The command inspect sip should not be present in the output of this command.
5.
From the NGFW1 CLI run show eigrp neighbors. Confirm that an adjacency has been formed between the FTD and CSR60
router.
6.
From the NGFW1 CLI run show eigrp topology. Confirm that the EIGRP routes have been received.
a. Look for network 203.14.10.0/24
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 43 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
NOTE: You will also see some routes that have no successors. These routes will be used in the next section BGP
7.
Run show route eigrp. Confirm that the NGFW1 now has EIGRP learned routes in its routing table.
Troubleshooting EIGRP
1.
If the EIGRP neighborship is not showing as above:
a.
Verify the EIGRP configuration by running the command show run router from the NGFW1 CLI.
> show running-config router
router eigrp 10
network 198.18.128.0 255.255.192.0
!
>
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 44 of 78
Cisco dCloud
b.
If the EIGRP commands are missing, it implies that the deployment failed. Check the deployment history from
the notifications and verify that the EIGRP commands were pushed successfully. Verify the syntax of the EIGRP
flex config object. In case you copy pasted the configuration, try manually typing in the configuration in the
myEIGRP Flex Object and attempt Deploy again.
c.
dCloud: The Cisco Demo Cloud
If the EIGRP commands are present as shown and still the EIGRP neighborship is missing, verify the
connectivity between the NGFW1 outside interface and the IP address of the next hop by typing the command
ping 198.18.133.60 on the NGFW CLI. It should be successful.
d.
If the pings don’t work, check the ARP table of the NGFW by using the command show arp.
i. If the ARP entry is missing, verify the outside interface IP configuration of the NGFW1 is 198.18.133.81
255.255.192.0.
ii.
If the configuration is correct but the ARP entry is missing, it implies that there could be a connectivity
issue in the lab POD.
iii. If the ARP entry is not missing, verify that the pings were executed for the correct IP i.e. 198.18.133.60
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 45 of 78
Cisco dCloud
Scenario 3.
NAT and Routing
This exercise consists of the following tasks.
•
Create objects needed for this lab exercise
•
Configure static NAT
•
Modify access control policy to allow outside access to wwwin
•
Configure BGP
•
Deploy the changes and test the configuration There are two objectives for this lab exercise:
•
Create a public web server
•
Configure BGP
dCloud: The Cisco Demo Cloud
The first objective will involve creating network objects, creating access control lists. Also, static NAT and dynamic routing will be
configured.
NOTE: The public server will be deployed in the inside network.
Steps
Verify and create objects needed for this lab exercise
1.
From the menu, select Objects > Object Management. The Network object page will be selected.
a. Verify that the object named wwwin is configured with the below details:
• Name: wwwin.
• Type: Host
• Network: 198.19.10.202.
b. Verify that the object named wwwout is configured on the FMC with the following details:
• Name: enter wwwout.
• Type: Host
• Network: 198.18.128.202.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 46 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
2.
Click Add Network > Add Object and create an object with the following details:
a. For Name, enter 203.14.10.0, Click on Network for type and enter 203.14.10.0/24 and Click Save.
3.
On the Objects page, select Access List > Standard from the left navigation pane.
a. Click Add Standard Access List.
b. For Name, enter Filter203.
c. Click Add to include the two access control entries shown below. The second entry is critical, because of an implicit
deny all at the end of the list.
d. Click Save.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 47 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
Configure static NAT ( this part is already done under Scenario 1 )
1.
From the menu, select Devices > NAT.
2.
Click the pencil icon to edit the Default PAT policy (which was configured in Scenario 1).
3.
Click Add Rule. The Add NAT Rule window appears.
4.
Select Auto NAT Rule and Static from the Type drop-down list. You will be at the Interface Objects tab.
5.
Select InZone1, and click Add to Source.
6.
Select OutZone, and click Add to Destination.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 48 of 78
Cisco dCloud
7.
Select the Translation tab.
8.
Select wwwin from the Original Source drop-down list.
9.
Select Address and wwwout from the Translated Source drop-down list.
dCloud: The Cisco Demo Cloud
10. Click OK to save the NAT rule.
11. Click Save to save the NAT policy.
Modify access control policy to allow outside access to wwwin
1.
From the menu, select Policies > Access Control > Access Control.
2.
Edit the Access Control Policy named NGFW_Policy.
a. Click Add Rule.
b. For Name, enter Web Server Access.
c. Select into Default from the Insert drop-down list.
d. The Zones tab should already be selected.
• Select InZone1, and click Add to Destination.
• Select OutZone, and click Add to Source.
e. Select the Networks tab.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 49 of 78
Cisco dCloud
• Select wwwin, and click Add to Destination.
• Select Ports. Under Available Ports type HTTP and select HTTP and HTTPS and click Add to Destination.
dCloud: The Cisco Demo Cloud
• Under Selected Destination Ports, type ICMP in the Protocol box. By default, Any ICMP type and code are
selected. Click Add.
NOTE: We use the true IP of the webserver, instead of the NAT'ed address that the client will connect to. This is because in the
packet processing path, the NAT untranslation is done before the access rule processing.
f. Select the Inspection tab.
g. Select Demo Intrusion Policy from the Intrusion Policy drop-down list.
h. Select Demo File Policy from the File Policy drop-down list.
i. Click Add to add the rule.
3.
Click Save to save the access control policy changes.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 50 of 78
Cisco dCloud
Configure BGP
1.
From the menu, select Devices > Device Management.
2.
Click on the pencil icon to edit the device settings for the device NGFW1.
dCloud: The Cisco Demo Cloud
a. Select the Routing tab.
b. In the left, under the Manage Virtual Routers section, scroll down to find General Settings.
c. Under the General Settings, select BGP and check the Enable BGP checkbox. Set the AS Number to 1.
d. Expand BGP in the left navigation pane above the General Settings and select IPv4. Check the Enable IPv4 checkbox.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 51 of 78
Cisco dCloud
e. Click on the Neighbor tab and click on Add.
f. For IP Address, enter 198.18.133.60. For Remote AS, enter 60.
3.
Check the Enable address checkbox.
dCloud: The Cisco Demo Cloud
a. Select Filter203 from the Incoming Access List drop-down list. Click OK to add the neighbor.
4.
Click Save to save the BGP configuration.
5.
From the jumpbox, login to the CSR60 with the credentials admin/C1sco12345
6.
Run the command show run | sec router bgp. The below configuration is already present
Deploy the changes and test the configuration
1.
Deploy the changes and wait until the deployment is complete.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 52 of 78
Cisco dCloud
2.
On the Jump desktop, open the PuTTY link.
a. Double click on the preconfigured session called Outside Linux Server.
b. Login as root, password C1sco12345
dCloud: The Cisco Demo Cloud
c. Type curl wwwout. This should succeed.
NOTE: The NGFW is doing proxy ARP for the IP address wwwout
3.
On the Jump desktop, open the PuTTY link. Double click on the preconfigured session called CSR60. Login as admin,
password C1sco12345
a. On the CSR60 CLI, run the command show bgp, and confirm that 4 routes appear.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 53 of 78
Cisco dCloud
4.
From the NGFW1 CLI:
5.
Run show route. Confirm that the only routes learned from BGP were 62.24.45.0/24 and 62.112.45.0/24. Note that
dCloud:
203.14.10.0/24 was successfully filtered out of BGP. However, if you performed the FlexConfig scenario,
youThe
willCisco
seeDemo
this Cloud
route as an external EIGRP route.
6.
Run show bgp and show bgp rib-failure. This shows that the 198.18.128.0/18 route was not inserted in the routing table
because there was a better route (connected).
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 54 of 78
Cisco dCloud
NOTE: You can also run the following commands from the FMC.
7.
From the menu, select Device > Device Management.
8.
Next to the NGFW1 device, select the three dots icon, and click on the Troubleshoot option. The Health Monitor page opens.
9.
On the Health Monitor page, select the NGFW1 device on the left panel.
dCloud: The Cisco Demo Cloud
10. Click on the View System & Troubleshooting Details…
11. Click Advanced Troubleshooting.
12. Select the Threat Defense CLI tab. From this tab, you can run several NGFW CLI commands.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 55 of 78
Cisco dCloud
13. From the Command dropdown, select Show, and run the following commands in the Parameter, one by one:
a. route and click the Execute button.
b. eigrp neighbors and click the Execute button.
dCloud: The Cisco Demo Cloud
c. bgp and click the Execute button.
14. From the Inside Linux server session, type ping 62.24.45.1. This should succeed.
Troubleshooting Connectivity from Outside Linux Server
1.
If the curl command fails, first check the connectivity between the Outside Linux Server and the NGFW1 outside interface.
a. From the Outside Linux Server run ping 198.18.133.81. It should be successful.
b. If the pings fail, check the arp table on the Outside Linux Server using the command arp -a. The arp table should contain
the MAC address of the IP 198.18.133.81 as shown in the output of the command show interface GigabitEthernet0/0.
2.
If pings to the NGFW1 outside interface are successful, try the command ping wwwout from the Outside Linux Server.
a. If this ping fails, verify that the arp table on the Outside Linux Server has the MAC address for the IP Address
198.18.128.202 same as that of NGFW1 outside interface IP 198.18.133.81
[root@outside ~]# arp -a
? (198.18.133.50) at 00:50:56:b8:5b:48 [ether] on eth0
gateway (198.18.128.1) at 00:50:56:00:00:01 [ether] on eth0
wwwout (198.18.128.202) at 00:50:56:b8:e6:ca [ether] on eth0
? (198.18.133.81) at 00:50:56:b8:e6:ca [ether] on eth0
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 56 of 78
Cisco dCloud
NOTE: The MAC address output might differ for each POD from the above snippet. However, since the NGFW1 is doing Proxy arp
for the wwwout IP on the outside interface, the MAC address of NGFW1 interface IP and the wwwout IP should be the same in the
arp table.
dCloud: The Cisco Demo Cloud
b. If the arp entry is absent or is not matching the NGFW1 outside interface, verify the NAT config from the FMC and verify
that the proxy arp is enabled on the Outside interface of NGFW1 using the command show run all sysopt | inc
outside from the NGFW1 CLI.
c. If the matching arp entry is there but the pings are not working, leverage the Packet Tracer utility from the FMC to verify
that the Access Control Policy rule was configured correctly to allow inbound traffic from Outside to wwwout. To open
the Packet Tracer utility, go to the Device > Device Management page. Next to the NGFW1 device, select the three
dots icon, and click on the Packet Tracer option.
Troubleshooting BGP neighborship
1.
Verify that the CSR60 BGP configuration is shown as below:
router bgp 20
bgp log-neighbor-changes
neighbor 198.18.133.2 remote-as 10
neighbor 198.18.133.81 remote-as 10
!
address-family ipv4
network 62.24.45.0 mask 255.255.255.0
network 62.112.45.0 mask 255.255.255.0
network 198.18.128.0 mask 255.255.192.0
network 203.14.10.0
neighbor 198.18.133.2 activate
neighbor 198.18.133.81 activate
exit-address-family
2.
If BGP routes are missing, verify the BGP neighborship state first by the command show bgp summary:
a. Working output
ngfw1# show bgp summary
BGP router identifier 198.19.10.1, local AS number 10
BGP table version is 5, main routing table version 5
3 network entries using 600 bytes of memory
3 path entries using 240 bytes of memory
1/1 BGP path/bestpath attribute entries using 208 bytes of memory
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 57 of 78
Cisco dCloud
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1072 total bytes of memory
BGP activity 3/0 prefixes, 3/0 paths, scan interval 60 secs
Neighbor
198.18.133.60
V
4
AS MsgRcvd MsgSent
20 528
436
TblVer
5
dCloud: The Cisco Demo Cloud
InQ OutQ Up/Down
0
0 07:57:34
State/PfxRcd
3
InQ OutQ Up/Down
0
0 00:00:01
State/PfxRcd
Idle
b. Not working output
ngfw1# show bgp summary
BGP router identifier 198.19.10.1, local AS number 10
BGP table version is 8, main routing table version 8
Neighbor
198.18.133.60
3.
V
4
AS MsgRcvd MsgSent
20 0
0
TblVer
1
If the BGP state is not Established (3), enable debugs on the NGFW CLI using the command debug ip bgp, the debugs will
show the BGP exchanges with the neighbor. In production you can specifiy the neighbor IP in the command debug ip bgp
x.x.x.x. Here is an example of working debugs from the output of debug ip bgp
ngfw1#
BGP: 198.18.133.60 passive open to 198.18.133.81
BGP: 198.18.133.60 passive went from Idle to Connect
BGP: ses global 198.18.133.60 (0x00002b3ec357fed0:0) pas Setting open delay timer to 60 seconds.
BGP: ses global 198.18.133.60 (0x00002b3ec357fed0:0) pas read request no-op
BGP: 198.18.133.60 passive rcv message type 1, length (excl. header) 38
BGP: ses global 198.18.133.60 (0x00002b3ec357fed0:0) pas Receive OPEN
BGP: 198.18.133.60 passive rcv OPEN, version 4, holdtime 180 seconds
BGP: 198.18.133.60 passive rcv OPEN w/ OPTION parameter len: 28
BGP: 198.18.133.60 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 198.18.133.60 passive OPEN has CAPABILITY code: 1, length 4
BGP: 198.18.133.60 passive OPEN has MP_EXT CAP for afi/safi: 1/1
BGP: 198.18.133.60 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
BGP: 198.18.133.60 passive OPEN has CAPABILITY code: 128, length 0
BGP: 198.18.133.60 passive OPEN has ROUTE-REFRESH capability(old) for all address-families
BGP: 198.18.133.60 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
BGP: 198.18.133.60 passive OPEN has CAPABILITY code: 2, length 0
BGP: 198.18.133.60 passive OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: 198.18.133.60 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
BGP: 198.18.133.60 passive OPEN has CAPABILITY code: 70, length 0
BGP: 198.18.133.60 passive unrecognized capability code: 70 - ingored
BGP: 198.18.133.60 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 198.18.133.60 passive OPEN has CAPABILITY code: 65, length 4
BGP: 198.18.133.60 passive OPEN has 4-byte ASN CAP for: 20
BGP: 198.18.133.60 passive rcvd OPEN w/ remote AS 20, 4-byte remote AS 20
BGP: ses global 198.18.133.60 (0x00002b3ec357fed0:0) pas Adding topology IPv4 Unicast:base
BGP: ses global 198.18.133.60 (0x00002b3ec357fed0:0) pas Send OPEN
BGP: 198.18.133.60 passive went from Connect to OpenSent
BGP: 198.18.133.60 passive sending OPEN, version 4, my as: 10, holdtime 180 seconds, ID c6130a01
BGP: 198.18.133.60 passive went from OpenSent to OpenConfirm
BGP: 198.18.133.60 passive went from OpenConfirm to Established
BGP: ses global 198.18.133.60 (0x00002b3ec357fed0:1) pas Assigned ID
BGP: nbr global 198.18.133.60 Stop Active Open timer as a non-multisession capable session with nbr is
alread
BGP: ses global 198.18.133.60 (0x00002b3ec357fed0:1) Up
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 58 of 78
Cisco dCloud
BGP_Router: unhandled major event code 128, minor 0
ngfw1#
4.
If the debugs don’t show any BGP updates from the neighbor, verify the TCP 179 port connectivity.
dCloud: The Cisco Demo Cloud
a. Verify that the port is open on CSR60 (BGP port) and the NGFW1 in LISTEN state.
• For NGFW1 run the command, show asp table socket. The output should be as below:
ngfw1# show asp table socket
Protocol
TCP
TCP
Socket
00016828
00336908
State
LISTEN
ESTAB
Local Address
198.18.133.81:179
198.18.133.81:179
Foreign Address
0.0.0.0:*
198.18.133.60:47341
• On the CSR60, run the command show tcp brief all numeric. The output should be as below:
csr60#show tcp brief all numeric
TCB
Local Address
7FF2DB81CAE8 198.19.10.111.23
7FF2DB808780 0.0.0.0.179
7FF2DBD45478 0.0.0.0.53
7FF27751EFC0 0.0.0.0.53
7FF2DBD391F0 0.0.0.0.179
Foreign Address
198.19.10.50.61473
198.18.133.81.*
*.*
*.*
198.18.133.2.*
(state)
ESTAB
LISTEN
LISTEN
LISTEN
LISTEN
b. Verify that the TCP connectivity is there. From the NGFW CLI, run the command ping tcp 198.19.133.111 179. The
output should be successful
ngfw1# ping tcp 198.18.133.60 179
Type escape sequence to abort.
No source specified. Pinging from identity interface.
Sending 5 TCP SYN requests to 198.18.133.60 port 179
from 198.18.133.81, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 59 of 78
Cisco dCloud
Scenario 4.
Prefilter Policies
This exercise consists of the following tasks.
•
Investigate NGFW default behavior for tunneled traffic
•
Create a tunnel zone
•
Create a prefilter policy
•
Modify the access control policy
•
Deploy the changes and test the configuration
dCloud: The Cisco Demo Cloud
If there is a clear-text tunnel, the NGFW access control policies apply to the tunneled traffic. Prefilter policies give control over the
tunneling protocol. The supported tunneling protocols are GRE, IP-in-IP, IPv6-in-IP, and Teredo.
Prefilter policies communicate with access control policies via tunnel tags. The prefilter policy assigns tunnel tags to specified
tunnels. The access control policy can then include rules that only apply to traffic tunneled through those specified tunnels.
In this exercise, you will create a GRE tunnel between the inside and outside CentOS servers.
You will then configure the NGFW to block ICMP through this GRE tunnel.
NOTE: This exercise has Scenario 4 as a prerequisite. This is because the exercise assumes the static NAT rule, which translates
198.19.10.202 to 198.18.128.202. To understand the configuration of the tunnel interface, you can inspect
/etc/sysconfig/network-scripts/ifcfg-tunO on the inside and outside servers.
Steps
Investigate NGFW default behavior for tunneled traffic
In this task, you will confirm that the access control policy rules apply the tunneled traffic.
1.
From the Jump desktop, launch PuTTY. Double-click on the pre-defined Inside Linux server session. Login as root, with
password C1sco12345
2.
Similarly, double-click on the pre-defined Outside Linux Server session. Login as root, with password C1sco12345
3.
Create a GRE tunnel between the Inside Linux server and Outside Linux server.
a. On the Inside Linux Server CLI, type ifup tun0.
b. On the Outside Linux Server CLI, type ifup tun0.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 60 of 78
Cisco dCloud
c. On the Inside Linux Server, try to ping through the tunnel by running the command ping 10.3.0.2.
d. Verify the GRE tunnel is established and passing through the NGFW1 by using the following commands:
• show conn | include GRE
dCloud: The Cisco Demo Cloud
• show conn detail all | include GRE
Test the IPS capabilities.
1.
Attempt to generate an intrusion event.
a. Run the following command from the Inside Linux Server CLI:
ftp 10.3.0.2
b. Login as guest, password C1sco12345
c. Type cd ~root. You should see the following message:
421 Service not available, remote server has closed connection.
d. Type exit to leave the FTP application.
2.
In the FMC, from the menu, select Analysis > Intrusions > Events.
a. Click the arrow on the left to drill down to the table view of the events.
b. Observe that the source and destination IPs are 10.3.0.1 and 10.3.0.2, respectively.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 61 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
3.
Test the file and malware blocking capabilities by running the following commands on the Inside Linux server CLI.
NOTE: These Wget commands can be cut and pasted from the file on the Jump desktop called Strings to cut and paste.txt.
a. As a control test, use WGET to download a file that is not blocked. wget -t 1 10.3.0.2/files/ProjectX.pdf.
b. This should succeed.
c. Next use WGET to download the file blocked by type: wget -t 1 10.3.0.2/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.
d. Finally use WGET to download malware.
e. wget -t 1 10.3.0.2/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.
4.
In the FMC, from the menu, select Analysis > Files > File Events.
a. Click Table View of File Events.
b. Observe that the sending and receiving IPs are 10.3.0.2 and 10.3.0.1, respectively.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 62 of 78
Cisco dCloud
Verify the tunnel zone
1.
From the FMC navigate to Objects > Object Management.
2.
Select Tunnel Zone from the left navigation pane. Verify that tunnel zone with the name GRE exists. .
dCloud: The Cisco Demo Cloud
Create a prefilter policy
1.
From the menu, select Policies > Access Control > Prefilter.
2.
Click New Policy. Enter a name NGFW Prefilter Policy. Click Save. Wait a few seconds for the policy to open for editing.
3.
Click Add Tunnel Rule. For Name, enter Handle GRE Traffic.
4.
Using the Assign Tunnel Zone drop-down list, Select GRE.
5.
From the Encapsulation & Ports tab, check the GRE checkbox.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 63 of 78
Cisco dCloud
NOTE: There are 3 actions.
Analyze - traffic will be passed to Snort, and access policy rules will apply.
Block - traffic is blocked.
Fastpath - traffic is allowed and bypasses any further inspection.
dCloud: The Cisco Demo Cloud
You can also create other prefilter rules for this policy. This gives you the ability to analyze, block or fast path traffic based on layer
2 through 4 information.
6.
Click Add to add the rule.
7.
Click Save to save the prefilter policy.
Modify the access control policy
1.
From the menu, select Policies > Access Control > Access Control. The list of access control policy appears.
2.
As the NGFW_Policy Access Control Policy is created based on Base_Policy, selecting a prefilter policy on the Base_Policy
also inherits into the NGFW_Policy.
3.
Click the pencil icon next to the Base_Policy to edit the policy.
4.
Click on the Demo Prefilter Policy located at the left of the string Prefilter Policy above the policy rules.
5.
In the Prefilter Policy popup window, select NGFW Prefilter Policy, and click OK.
6.
Click Save to save the configuration changes.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 64 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
7.
Go back to Policies > Access Control > Access Control page to view the list of the access control policy.
8.
This time, click the pencil icon next to the NGFW_Policy to edit the policy.
9.
When the NGFW_Policy opens in the policy editor, notice that the Prefilter Policy is inherited from the Base_Policy. If you
click on the policy name, you will find that this selection is read-only – you cannot select a new Prefilter Policy here.
10. In the NGFW_Policy access control policy editor, under the Rules tab, create a new rules by following the steps below:
a. Click Add Rule.
b. Call the rule Block ICMP Over GRE.
c. Select into Mandatory from the Insert drop-down list.
d. Set the action to Block with reset.
e. In the Available Zones column, select GRE and click Add to Source.
f. In the Available Applications column, select ICMP and click Add to Rule.
g. Select the Logging tab. Check the Log at Beginning of Connection checkbox.
h. Click Add to add the rule to the policy.
11. Click Add Rule.
a. Call the rule Allow GRE Traffic.
b. Select into Default from the Insert drop-down list. This will become the last rule in the access control policy.
c. In the Available Zones column, select GRE and click Add to Source.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 65 of 78
Cisco dCloud
d. Select the Inspection tab.
• Select Demo Intrusion Policy from the Intrusion Policy drop-down list.
• Select Demo File Policy from the File Policy drop-down list.
dCloud: The Cisco Demo Cloud
e. Click Add to add the rule to the policy.
f. Click Save to save the access control policy.
Deploy the changes and test the configuration
1.
Deploy the changes, as you have been. Wait for the deployment to complete.
2.
On the Outside Linux Server, run tcpdump -n -i tun0 to monitor tunnel traffic.
a. Run the following commands on the Inside Linux Server CLI.
b. wget 10.3.0.2 This should succeed.
c. ping 10.3.0.2. The pings will not work.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 66 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
If you are not getting the results above:
1.
Tear down tunnel:
• On the Outside Linux Server CLI, type Ctrl C then ifdown tun0.
• On the Inside Linux Server CLI, type ifdown tun0.
2.
Re-establish the tunnel using the commands ifup tun0 on both the Linux Servers
3.
Retest
4.
Inspect the output of the tcpdump command on the Outside Linux Server to confirm that the ping is not making it to 10.3.0.2.
5.
On the FMC Analysis > Connections > Events, look for traffic from 10.3.0.1 to 10.3.0.2. You should see Block with reset for
ICMP traffic
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 67 of 78
Cisco dCloud
Scenario 5.
Device Deployment with the REST API
The objective of this lab you will perform a simple deployment of the NGFW. Most of this will be with a REST API python script. But
dCloud: The Cisco Demo Cloud
first, you must perform some preliminary steps.
NGFW device onboarding onto the FMC is done in two parts. First, configuration settings are added on the NGFW to configure
FMC as the device manager and establish communication with the FMC on the management interface. Secondly, the NGFW
device is added onto the Devices page on the FMC to initiate and establish communication. Here, we use the jumpbox to
complete both the steps.
Steps
NOTE: The next section is optional. Due to the nature of the lab environment, the NGFW showcased here is already registered
and managed by the FMC. To configure the rest of the section, the NGFW1 needs to be unregistered from the FMC using the
steps mentioned in Unregister the NGFW from the FMC. If you wish to skip this section, you can verify the objects and policies,
instead of configuring them as most of them will be already added to the FMC policies.
Unregister the NGFW from the FMC
1.
If the FMC GUI is not currently open, or if the session has timed out, login to the FMC again.
2.
Navgiate to Devices > Device Management. Click on the Delete icon for the device named NGFW1. It will prompt with a
Warning. Select Yes.
3.
Once the NGFW1 device deleted, the device listing will not show it in the Device Management page.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 68 of 78
Cisco dCloud
Configure the NGFW for management by the FMC
1.
On the Jump desktop, open the PuTTY link. Double click on the preconfigured session called NGFW1. Login using userid
admin, password C1sco12345
dCloud: The Cisco Demo Cloud
NOTE: If you run into issues with typing special characters, please open the file on the Jump desktop called Strings to cut and
paste.txt.
2.
Enter the command show managers. You should see the message No managers configured
Note: If the output differs from the above screenshot, check the FMC device listing page to verify if the NGFW1 has been removed.
If not, retry deleting the device from the FMC as instructed before. If the FMC does not show the NGFW1 device listed but the
output still differs, manually try removing the FMC management using the command configure manager delete.
3.
Add the FMC by entering the following command:
configure manager add fmc.dcloud.local C1sco12345
4.
If a warning appears, answer yes when/(if) asked if you want to continue. Do not type only y. The NGFW2, NGFW3, were
installed with the on-box manager (Firepower Device Manager or FDM) enabled. This is the default configuration. This is why
you are receiving this warning. You will only receive the warning if the FTD is set to be managed locally.
NOTE: We will have an on-box management lab exercise later in this class. Be aware that you cannot switch between FMC and
FDM without deleting the NGFW configuration.
5.
Leave this PuTTY session open, since it will be used throughout the lab.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 69 of 78
Cisco dCloud
Run a REST API script to register and configure the NGFW
To demonstrate the REST API, you will run a Python script that will perform the following tasks:
dCloud: The Cisco Demo Cloud
•
Create an access control policy
•
Register the NGFW1 to the FMC
•
Configure the NGFW(s) interfaces
NOTE: The NGFW can be added to the FMC for management using the FMC UI. However, here we are going to use REST API
to demonstrate the automated capabilities of the solution. A python script is present on the Inside Linux Server called runapiscript
at the location /usr/local/bin. The scripts are for training purposes only, so they are not perfectly polished. The command
runapiscript is a symbolic link to a python script register_config.py which uses a Python module generated by connect.py. The
script presents you an option to configure one of three firewalls and it invokes the REST APIs on the FMC to register the NGFW
with the FMC, applies the Health Policy to the NGFW, discovers the interfaces, configures the IP addresses and deploys the Access
Control Policy with the name specified during the execution of the script.
1.
From the Jump desktop, launch PuTTY. Double-click on the Inside Linux server session. Login as root, password
C1sco12345
2.
On the Inside Linux server CLI run runapiscript.
3.
When asked Which firewall do you want to register?, enter 1 (NGFW1) and press Enter.
4.
When prompted to enter an access control policy name, enter a name, such as: Firewall_Policy Access Control Policy.
5.
You will see the script run through the registration process.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 70 of 78
Cisco dCloud
6.
The script will automatically continue to the discovery and interface configuration processes.
NOTE: It may take several seconds before any tasks start. If no tasks start for over a minute, run the runapiscript script again. Be
dCloud: The Cisco Demo Cloud
sure to use a different name for the access control policy or delete the policy that the script created. If you have an FMC tab still
open, you can see the notifications live for the various steps of the registration process.
7.
Leave this PuTTY session open to finish running the script gracefully. The FMC displays the progress notification
automatically in real time. Alternatively, on the FMC, you can click on the notification icon next to the Deploy button, and
select the Tasks tab to watch various task status, such as, Register, Discovery, Health Policy, Policy Pre-Deployment, and
Policy Deployment.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 71 of 78
Cisco dCloud
Scenario 6.
Basic Configuration using FDM
Configuring NGFW3 Management Using Firepower Device Manager (FDM ON BOX)
dCloud: The Cisco Demo Cloud
NOTE: NGFW3 has been preconfigured with the Management IP Address and the Username/Password used below.
1.
On the Jump PC, use the Start menu to open the Firefox browser.
2.
On the browser bookmark bar, click on the NGFW3 (FDM).
3.
If you are prompted with a security warning accept the risks.
4.
The Firepower Device Manager screen should prepopulate. If not, the credentials are Username: Admin Password:
C1sco12345
5.
Click Login. You will come to the following Device Setup screen, which displays the FTD cable connections and other device
settings.
6.
Scroll down to the Outside Interface Address.
7.
Select the arrow next to Using DHCP.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 72 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
8.
Click on Manual Input.
9.
Configure the Outside Interface Address.
•
IP Address: 198.18.133.83
•
Network Mask: 255.255.192.0 ( From the drop down select Manually Input )
•
Gateway: 198.18.128.1
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 73 of 78
Cisco dCloud
10. Configure the Management Interface for using OPENDNS Servers by clicking the button USE OPENDNS.
11. Add the Tertiary DNS IP Address as 198.18.128.1
12. Check for the Hostname ngfw3.dcloud.local and click Next.
dCloud: The Cisco Demo Cloud
NOTE: If you get a message that the connection to www.cisco.com has failed. That is ok, move on to the setting of the NTP
services.
13. Manually set up the NTP Server.
a. Time Zone: (UTC-08:00)America/Los_Angeles
b. NTP Time Server:
• User-Defined NTP Servers
• Address: 198.18.128.1.
c. Click Next.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 74 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
14. You will get the message to register with the Licensing server. Select Continue with Evaluation Period. Click FINISH.
15. Next, you will be presented with an additional option to manage the device using Cisco Defense Orchestrator or continue with
only FDM. Select Standalone Device. The GUI prompts you to select a configuration step − Configure Interfaces and
Configure Policy.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 75 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
16. Select Configure Interfaces. The GUI shows the list of available interfaces in the Interfaces page.
17. As you can see Interface GigabitEthernet 0/1 is configured as inside with IP Address 192.168.45.1. Also, the Outside Interface
GigabitEthernet 0/0 has the outside interface that we manually configured. If you wish to change the address of
GigabitEthernet 0/1, hover your mouse over the GigabitEthernet 0/1 line. Under the Actions column, click the pencil Icon.
18. Delete the DHCP pool. Change the IP Address to: 198.19.10.3/255.255.255.0. Click OK.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 76 of 78
Cisco dCloud
dCloud: The Cisco Demo Cloud
19. Click on the deployment icon (top right side of the GUI) to review the configuration changes that will be deployed to the FTD.
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 77 of 78
Cisco dCloud
20. The Pending Changes window shows the new configuration changes that are ready to be deployed on the FTD. Deploy the
configuration by clicking on the DEPLOY NOW button. Wait for the deployment to complete.
dCloud: The Cisco Demo Cloud
© 2021 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 78 of 78