Cisco NGFW Basic Lab v1.5

Cisco dCloud
Cisco Firepower Next-Generation Firewall 6.6 Basics Lab

v1.5 dCloud: The Cisco Demo Cloud
Last Updated: 07-Aug-2020
IMPORTANT! This content is community developed and is not subject to standard dCloud verification or support. Please contact
dCloud Support for more information.
About This Demonstration

This guide for this preconfigured demonstration includes:
• Requirements
• About This Solution
• Topology
• Get Started
• Scenario 1: Basic Configuration
• Scenario 2: FlexConfig
• Scenario 3: NAT and Routing
• Scenario 4: Prefilter Policies
• Scenario 5: Device Deployment with the REST API
Requirements
The table below outlines the requirements for this preconfigured demonstration.
Table 1. Requirements
Required Optional
● Laptop ● Cisco AnyConnect®
© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 65
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
dCloud: The Cisco Demo Cloud
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 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.
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]
• 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. Navigate to admin > User Preferences in the top right hand corner. Under the General tab, click on the dropdown under UI
Theme and select Light theme.
5. A popup will show up with a disclaimer about the Light Theme. Click on Use Light theme.
Cisco dCloud
6. The FMC UI will change from the classic UI to new UI.
The above steps are optional for Firepower release 6.5. In Firepower release 6.6, the above UI theme is used by default. All the lab
screenshots were captured using the new UI theme. It has no impact on the configuration steps.
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
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:
i.Name: Lab_Networks.
ii.Value: 198.18.0.0/15. This includes all IP addresses used in the lab pod.
iii.Type: Network
Cisco dCloud
2. Select Interface from the left navigation panel. Verify there should be security zones configured with the below details:
a. InZone
i.Name: InZone
ii.Type: Security Zone
iii.Interface Type: Routed
b. OutZone
i.Name: OutZone
ii.Type: Security Zone
iii.Interface Type: Routed
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.
Cisco dCloud
2. The Interfaces tab should be selected by default. Review Security Zones for the interfaces GigabitEthernet0/0 and
GigabitEthernet0/1 by clicking on the Pencil icon against each interface respectively, verify the zone name as shown below
and clicking OK
a. GigabitEthernet0/0 – OutZone
b. GigabitEthernet0/1 - InZone
3. Confirm that the inside and outside interfaces of NGFW1 have Security Zones configured with the IP addresses as shown
below and click Save:
Cisco dCloud
4. 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).
5. 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).
6. Click OK .
7. Click Save.
Cisco dCloud
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.
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. 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.
i.Select InZone, and click Add to Destination.
ii.Select OutZone, and click Add to Source.
f. Select the Networks tab to enter the source and destination information
i. Search for SplunkInside in the Available Networks list
ii.Click Add to Destination
Cisco dCloud
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.
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.
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 InZone, and click Add to Source.
b. Select OutZone, and click Add to Destination.
Cisco dCloud
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.
Cisco dCloud
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 Add to add the rule.
10. Select the HTTP Responses tab.
11. Select System-provided from the Block Response Page drop-down list.
12. Select the Advanced tab.
13. Click the pencil icon to edit the Transport/Network Layer Preprocessor Settings.
14. In the Maximum Active Responses field, enter 25
15. Click OK.
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.
Cisco dCloud
16. Click on Rules tab and for the rule Allow Outbound Connections, click on the Pencil to edit the rule settings. 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:
Blocked traffic—Because blocked traffic is immediately denied without further inspection, usually you can log only beginning-of-
connection events for blocked or blacklisted traffic. There is no unique end of connection to log.
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.
17. Click Save to save the changes to the rule.
18. 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.
Cisco dCloud
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.
Cisco dCloud
7. Select Dynamic from the Type drop-down list.
a. You will be at the Interface Objects tab. Select InZone and click Add to Source.
b. Select OutZone and click Add to Destination.
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.
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.
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 IntGroup10 and Add to Source.
Cisco dCloud
Note: Here, we used Interface group IntGroup10 instead of InZone for selecting the inside interface. For Auto NAT rules, if a zone
is assigned to multiple interfaces, an interface group has to be used instead.
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.
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.
Cisco dCloud
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.
e. Zones Tab
i.Source Zone: OutZone,
ii.Destination Zone: InZone.
f. Networks Tab
i.Destination networks FMC_Private.
g. Inspection Tab.
Cisco dCloud
i. Intrusion Policy Demo Intrusion Policy.
ii. 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 IntGroup10, and click Add to Source.
c. Select OutZone, and click Add to Destination.
a. Select wwwin from the Original Source drop-down list.
b. Select Address and wwwout from the Translated Source drop-down list.
Cisco dCloud
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. Verify that Lab_Networks is added to the list of Networks. Click Save.
Cisco dCloud
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.
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
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. 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.
Cisco dCloud
b. Verify the following connectivity in steps:
i.Inside Linux Server to inside interface of NGFW– ping 198.19.10.1 should be successful
ii.Outside interface of NGFW to outside – ping 198.18.133.200 should be successful
iii.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.
i.Navigate to the troubleshoot page of the NGFW1 by clicking on the icon as shown below. Click Advanced
Troubleshooting.
ii.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.
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
Cisco dCloud
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.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
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
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
>
Test the IPS functionality of NGFW deployment
1. On the Inside Linux Server CLI, enter ftp outside. Login as guest, password C1sco12345
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.
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.
Cisco dCloud
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
5. 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.
Cisco dCloud
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.
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.
Cisco dCloud
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.
5. From the menu, select Analysis > Files > File Events. You should see information about all the file events for the recently
attempted connection.
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.
Cisco dCloud
For removing the NGFWBR1 from FMC, navigate to Devices > Device Management. Click the Delete icon and click Yes. 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.
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
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.
Cisco dCloud
9. Select Branch1Access.
a. Under Smart Licensing: Check all boxes
b. Under Advanced Type the NAT code from the FTD: abcde.
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
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.
Cisco dCloud
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: branch1_Inzone
15. You can verify that the IP Address 198.19.11.1/24 is already configured on this interface.
Cisco dCloud
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.
22. Go to Devices NAT > New Policy > Threat Defense NAT.
Cisco dCloud
23. Name the Policy Branch1_NAT_Policy and under available devices select NGFWBR1.
24. Click Add to Policy.

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 branch1_InZone. Click Add to Source.
b. select branch1_Outzone. Click Add to Destination.
Cisco dCloud
29. On the Translation Tab under Original Source, select the (+) and configure New Network with the details as :
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 branch1_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.
Cisco dCloud
35. Click on Add Click on Save at the top of the web page.
36. Click Deploy and Select NGFWBR1.
NOTE: The above NAT and Access Policy rules have been added to allow outbound internet access from the Branch1 networks.
Cisco dCloud
Cisco dCloud
Configuring NGFW3 Management Using Firepower Device Manager (FDM ON BOX)
NOTE: NGFW3 has been preconfigured with the Management IP Address and the Username/Password used below.
1. From the Jump PC, open Firefox browser and click on the NGFW3 (FDM) from the browser bookmark bar
2. If you are prompted with a security warning accept the risks
3. The Firepower Device Manager screen should prepopulate. If not, the credentials are Username: Admin Password:
C1sco12345
4. Click Login
5. You will come to the following Device Setup screen, which displays the FTD cable connections and other device settings.
Scroll down to the Outside Interface Address
6. Select the arrow next to Using DHCP.
7. Click on Manual Input.
Cisco dCloud
8. 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
9. Configure the Management Interface for using OPENDNS Servers by clicking the button USE OPENDNS.
10. Add the Tertiary DNS IP Address as 198.18.128.1
11. Check for the Hostname ngfw3.dcloud.local and click Next.
Cisco dCloud
12. 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 the NTP Server.
a. Select Time Zone.
i. Select (UTC-08:00)America/Los_Angeles
b. NTP Time Server
i. User-Defined NTP Servers
ii. Address: 198.18.128.1.
c. Click Next.
Cisco dCloud
14. You will get the message to register with the Licensing server. Select Continue with Evaluation Period. Click FINISH.
15. Next, you will be presention with an additional option to manage the device using Cisco Defense Orchestrator or continue with
only FDM. Select Standalone Device. The next screen prompts you to configure Interfaces and Policy.
Cisco dCloud
16. Select Interfaces.
NOTE: 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, choose the GigabitEthernet 0/1 line and under actions, click the pencil Icon. Delete the DHCP pool. Change
the IP Address to: 198.19.10.3/255.255.255.0. Click OK
17. Click on the deployment icon and review the configuration changes that will be deployed to the FTD. The deployment window
shows a diff of the changes being pushed.
18. Deploy the configuration by clicking on DEPLOY NOW. Wait for the deployment to complete.
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
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:
• Configure EIGRP using a user defined FlexConfig object.
• 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. You can use them as well by copying and then
renaming it.
3. Click Add FlexConfig Object.
a. For Name, enter myEIGRP.
Cisco dCloud
b. In the main text area, enter the following commands.

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.
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.
Cisco dCloud
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.
b. In the left column, under System Defined, select Default_lnspection_Protocol_Disable. Click to add the FlexConfig
object to the policy.
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.
Cisco dCloud
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)
>
> 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
!
>
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.
Cisco dCloud
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
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.
Cisco dCloud
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
!
>
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. 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
Cisco dCloud
Scenario 3. NAT and Routing

• 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
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:
i.Name: wwwin.
ii.Type: Host
iii.Network: 198.19.10.202.
b. Verify that the object named wwwout is configured on the FMC with the following details:
i.Name: enter wwwout.
ii.Type: Host
iii.Network: 198.18.128.202.
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.
Cisco dCloud
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.
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.
3. Click Add Rule.
a. Select Auto NAT Rule and Static from the Type drop-down list.
b. You will be at the Interface Objects tab. Select IntGroup10, and click Add to Source.
c. Select OutZone, and click Add to Destination.
a. Select wwwin from the Original Source drop-down list.
b. Select Address and wwwout from the Translated Source drop-down list.
Cisco dCloud
5. 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 NGFW Access Control Policy for 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.
i.Select InZone, and click Add to Destination.
ii.Select OutZone, and click Add to Source.
e. Select the Networks tab.
i.Select wwwin, and click Add to Destination.
ii.Select Ports. Under Available Ports type HTTP and select HTTP and HTTPS and click Add to Destination.
iii.Under Selected Destination Ports type in the Protocol box ICMP. Click Add.
Cisco dCloud
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.
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.
a. Select the Routing tab.
b. In the left section under Manage Virtual Routers, scroll down.
Cisco dCloud
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.
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.
a. Select Filter203 from the Incoming Access List drop-down list. Click OK to add the neighbor.
Cisco dCloud
4. Click Save to save the BGP configuration.
5. From the jumpbox, login to the CSR60 with the credentials admin/C1sco12345
a. Add the following commands to the CSR60
b. This was already configured

Router bgp 60
neighbor 198.18.133.81 remote-as 1
address-family ipv4
neighbor 198.18.133.81 activate
1. Deploy the changes and wait until the deployment is complete.
2. On the Jump desktop, open the PuTTY link. Double click on the preconfigured session called Outside Linux Server. Login as
root, password C1sco12345
a. Type curl wwwout. This should succeed.
b. Type ssh wwwout. This should fail as we allowed only HTTP, HTTPS and ICMP in the Access Control Policy rule.
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.
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
203.14.10.0/24 was successfully filtered out of BGP. However, if you performed the FlexConfig scenario, you will see this
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).
NOTE: You can also run the following commands from the FMC.
7. From the menu, select Device > Device Management.
8. Edit the NGFW1 device and select the Devices tab.
9. Click on the Wrench and Screwdriver Icon
10. Click Advanced Troubleshooting.
11. Select the Threat Defense CLI tab. From this tab, you can run several NGFW CLI commands.
12. Command Show:
a. Route and the Execute button
b. BGP and the Execute button
c. eigrp neighbors and the Execute button
13. From the Inside Linux server session, type ping 62.24.45.1. This should succeed.
Cisco dCloud
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
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.
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
i.Navigate to the troubleshoot page of the NGFW1 by clicking on the icon as shown below. Click Advanced
Troubleshooting.
ii.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.
Troubleshooting BGP neighborship
1. Verify that the CSR60 BGP configuration is shown as below:

router bgp 20
bgp log-neighbor-changes
Cisco dCloud

!
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
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
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 V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

198.18.133.60 4 20 528 436 5 0 0 07:57:34 3
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 V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

198.18.133.60 4 20 0 0 1 0 0 00:00:01 Idle
3. 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
Cisco dCloud
BGP: 198.18.133.60 passive OPEN has ROUTE-REFRESH capability(old) for all address-families
BGP: 198.18.133.60 passive OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: 198.18.133.60 passive unrecognized capability code: 70 - ingored
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
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.
a. Verify that the port is open on CSR60 (BGP port) and the NGFW1 in LISTEN state.
i.For NGFW1 run the command, show asp table socket. The output should be as below:
ngfw1# show asp table socket
Protocol Socket State Local Address Foreign Address

TCP 00016828 LISTEN 198.18.133.81:179 0.0.0.0:*
TCP 00336908 ESTAB 198.18.133.81:179 198.18.133.60:47341
ii.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 Foreign Address (state)
7FF2DB81CAE8 198.19.10.111.23 198.19.10.50.61473 ESTAB
7FF2DB808780 0.0.0.0.179 198.18.133.81.* LISTEN
7FF2DBD45478 0.0.0.0.53 *.* LISTEN
7FF27751EFC0 0.0.0.0.53 *.* LISTEN
7FF2DBD391F0 0.0.0.0.179 198.18.133.2.* 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
Cisco dCloud
Scenario 4. Prefilter Policies

• 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
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 following tunneling protocols are supported.
• GRE
• IP-in-IP
• IPv6-in-IP
• 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.
Cisco dCloud
1. You should still have the SSH session open to the Inside Linux server.
2. If you do not have an SSH session to the Outside Linux Server, from the Jump desktop, launch PuTTY and double-click on the
pre-definite Outside Linux Server session. Login as root, password C1sco12345 dCloud: The Cisco Demo Cloud
3. Create a GRE tunnel between the Inside Linux server and Outside Linux server.
a. On the Outside Linux Server CLI, type ifup tun0.
b. On the Inside Linux Server CLI, type ifup tun0.
c. On the Inside Linux Server, confirm that you can ping through the tunnel with the following command. ping 10.3.0.2
d. If the pings don’t work, verify the GRE tunnel is passing through the NGFW1 by using the command show conn | in GRE
Test the IPS capabilities.
1. Run the following command from the Inside Linux Server CLI. ftp 10.3.0.2
a. Login as guest, password C1sco12345
b. Type cd ~root. You should see the following message:
c. 421 Service not available, remote server has closed connection.
d. Type quit to exit FTP.
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.
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.
Cisco dCloud
Verify the tunnel zone
1. From the FMC navigate to Objects > Object Management.

a. Select Tunnel Zone from the left navigation pane.
b. Verify that tunnel zone with the name GRE exists. .
Create a prefilter policy
2. From the menu, select Policies > Access Control > Prefilter.
a. Click New Policy. Enter a name NGFW Prefilter Policy. Click Save.
b. Wait a few seconds for the policy to open up for editing.
3. Click Add Tunnel Rule.
a. For Name, enter Handle GRE Traffic.
b. Select GRE from the Assign Tunnel Zone drop-down list.
c. Select the Encapsulation & Ports tab and check the GRE checkbox.
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.
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.
4. Click Add to add the rule.
5. Click Save to save the prefilter policy.
Modify the access control policy
1. From the menu, select Policies > Access Control > Access Control to edit the NGFW_Policy Access Control Policy.
2. Click on the Default Prefilter Policy to the right of the string Prefilter Policy above the policy rules.
3. Select NGFW Prefilter Policy.
4. Click OK.
5. Select the Rules tab.
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.
Cisco dCloud
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.
6. 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.
d. Select the Inspection tab.
i.Select Demo Intrusion Policy from the Intrusion Policy drop-down list.
ii.Select Demo File Policy from the File Policy drop-down list.
e. Click Add to add the rule to the policy.
f. Click Save to save the access control policy.
Note: The above screenshot shows only the rules with the word “GRE” in the rule name. You can search for the rules using various
conditions in the search bar.
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.
Cisco dCloud
b. wget 10.3.0.2 This should succeed.
c. ping 10.3.0.2. The pings will not work. You may see the following output, indicating that the ping is being blocked.
From 10.3.0.2 icmp_seq=1 Packet filtered dCloud: The Cisco Demo Cloud
3. If you are not getting the results above
a. Tear down tunnel:
i.On the Outside Linux Server CLI, type Ctrl C then ifdown tun0.
ii.On the Inside Linux Server CLI, type ifdown tun0.
b. Re-establish the tunnel using the commands ifup tun0 on both the Linux Servers
c. 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
a. You should see Block with reset for ICMP traffic
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
first, you must perform some preliminary steps. dCloud: The Cisco Demo Cloud
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 sections, 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 jump to Scenario 2 and 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. The FMC should already be open since we made the changes to the UI theme before starting the lab. 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. Now the device listing will not contain NGFW1.
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
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 following command show managers
a. You should see 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.
b. Enter the following command:
configure manager add fmc.dcloud.local C1sco12345
3. If a warning appears answer yes when/(if) asked if you want to continue. Do not type y.
NOTE: 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 Managed
Locally
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.
4. Leave this PuTTY session open, since it will be used throughout the lab.
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:
• 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 will present you with the 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 reasonable name, such as: NGFW_Policy Access Control
Policy.
5. You will see the script run through the registration process.
6. The script will automatically continue for the discovery process
NOTE: It may take several seconds before any tasks start. If no tasks start for over a minute, run the runapiscript script again. Be
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. The script will automatically configure the interfaces (Leave this PuTTY session open. You will use it throughout the lab).
8. Go to the FMC and click the icon to the right of the Deploy button, and select the Tasks tab.
a. Watch as the the Register, Discovery, Health Policy, Policy Pre-Deployment, and Policy Deployment tasks complete
Cisco dCloud

Cisco NGFW Basic Lab v1.5

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cisco NGFW Basic Lab v1.5

Uploaded by

Copyright:

Available Formats

Cisco dCloud

Cisco Firepower Next-Generation Firewall 6.6 Basics Lab

Last Updated: 07-Aug-2020

About This Demonstration

• About This Solution

• Scenario 1: Basic Configuration

• Scenario 3: NAT and Routing

• Scenario 4: Prefilter Policies

• Scenario 5: Device Deployment with the REST API

● 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.

• Jump PC 1: 198.18.133.50, Username: administrator, Password: C1sco12345

dCloud: The Cisco Demo Cloud

6. The FMC UI will change from the classic UI to new UI.

Scenario 1. Basic Configuration and verification of settings

• 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

• 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

Review and verify objects needed for the exercise

a. In the Filter bar to the right enter lab.

b. It should show an object with the following details:

dCloud: The Cisco Demo Cloud

ii.Type: Security Zone

iii.Interface Type: Routed

ii.Type: Security Zone

iii.Interface Type: Routed

Review the interface and routing configuration of the device

dCloud: The Cisco Demo Cloud

a. Interface outside is selected in the Interface field.

Modify the access control policy

3. Click Add to Policy.

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

i.Select InZone, and click Add to Destination.

ii.Select OutZone, and click Add to Source.

i. Search for SplunkInside in the Available Networks list

ii.Click Add to Destination

dCloud: The Cisco Demo Cloud

g. Click Add to add the rule.

a. Click the + Add Rule button.

b. For Name, enter Allow Outbound Connections.

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

Mandatory rules, which take precedent over rules of child policies

7. The Zones tab should already be selected.

a. Select InZone, and click Add to Source.

b. Select OutZone, and click Add to Destination.

dCloud: The Cisco Demo Cloud

8. Select the Inspection tab.

10. Select the HTTP Responses tab.

12. Select the Advanced tab.

14. In the Maximum Active Responses field, enter 25