Secure Firewall Lab-Basics 7

Cisco dCloud
Cisco Secure Firewall 7.2 Basics Lab

Last Updated: 20-July-2022 dCloud: The Cisco Demo Cloud
REQUIREMENTS ...................................................................................................................................................2
ABOUT THIS SOLUTION ........................................................................................................................................2
TOPOLOGY ..........................................................................................................................................................3
GET STARTED .......................................................................................................................................................4
SCENARIO 1. ................................................................... BASIC CONFIGURATION AND VERIFICATION OF SETTINGS

...........................................................................................................................................................................5
SCENARIO 2. ............................................................................................................................ NAT AND ROUTING

......................................................................................................................................................................... 47
SCENARIO 3. ........................................................................................................................... PREFILTER POLICIES

......................................................................................................................................................................... 65
SCENARIO 4. .......................................................................................... DEVICE DEPLOYMENT WITH THE REST API

......................................................................................................................................................................... 76
SCENARIO 5. ................................................................................................... BASIC CONFIGURATION USING FDM

......................................................................................................................................................................... 81
© 2022 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 88
Cisco dCloud
Requirements
The table below outlines the requirements for this preconfigured demonstration.
dCloud: The Cisco Demo Cloud
Table 1. Requirements
Required Optional
● Laptop ● 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 Secure Firewall 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 Secure NGFW to evolve with a focus on enabling enterprises to stop, prioritize, understand, and automate
responses to modern threats in real-time. Secure 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. Secure
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 Firewall 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 Firewall Device Manager (FDM). You will configure an NGFW using an automation
script and the REST API.
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. Alternatively, open the Quick Launch from the task bar, and click the FMC Web to login to the GUI of the FMC automatically.
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.
Cisco dCloud
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
2. Select Interface from the left navigation panel. Verify there should be security zones configured as shown below in the
screenshot:
Cisco dCloud
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.
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:
Cisco dCloud
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).
5. Click OK.
6. 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, then 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.
4. 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
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.
5. 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.
6. The Zones tab should already be selected.
a. Select InZone1, and click Add to Source.
b. Select OutZone, and click Add to Destination.
Cisco dCloud
7. Select the Inspection tab.
a. Select dCloud Balanced Intrusion from the Intrusion Policy drop-down list.
b. Select TG File Policy from the File Policy drop-down list.
NOTE: The demo intrusion and file policies were pre-configured to save you time. See Appendix 1 in the Firewall Advanced Lab
Guide v2.5 for instructions on how to create these.
Cisco dCloud
8. 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.
9. Click Save to add the rule.
Cisco dCloud
10. Go to the HTTP Responses tab. Ensure that the System-provided is selected from the Block Response Page drop-down.
11. Go to the Advanced tab.
12. Ensure that the Maximum Active Responses is set to 25 under the Transport/Network Layer Preprocessor Settings.
a. Click on the pencil icon by Transport/Network Layer Preprocessor Settings.
b. Enter 25 into the Maximum Active Responses input box.
c. Click OK.
Cisco dCloud
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.
13. 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 Firewall 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.
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.
Cisco dCloud
Cisco dCloud
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.
Cisco dCloud
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.
9. For Host enter 198.18.133.120 (An address on the WAN network). Click Save then select FMC_Public for Translated
Source.
Cisco dCloud
10. Then Click OK.
11. Click Save.
NOTE: The screenshot above shows the NAT Rules you just created.
Cisco dCloud
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
• Source Zone: OutZone,
• Destination Zone: InZone1.
f. Networks Tab
• Destination networks FMC_Private.
g. Inspection Tab.
• Intrusion Policy dCloud Balanced Intrusion.
• File Policy TG 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.
Cisco dCloud
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.
a. Select wwwin from the Original Source drop-down list.
b. Select Address and wwwout from the Translated Source drop-down list.
c. Click OK to save the NAT rule.
4. Click Save to save the NAT policy.
Cisco dCloud
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.
Cisco dCloud
Test the NGFW connectivity
We will be leveraging the PUTTY client on the Jumbox for testing the connectivity.
1. Using the Quick Launch on the Jumpbox, login to the Kali Inside Linux Server CLI, you should be automatically logged in as
administrator. Login credentials: administrator/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 connection to the Kali Outside Linux Server from the Quick
Launch on the Jumpbox.
a. You should be logged in automatically.
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.
Cisco dCloud
Cisco dCloud
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.
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 Devices > Device Management page. Select Packet Tracer for the NGFW1, as show below.
The New Trace page appears.
Cisco dCloud
• On the New Trace page, 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
>
Cisco dCloud
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,
4. Open the Access Control policy for NGFW_Policy.
5. Click Analyze Hit Count in the upper right corner of the policy editor page.
6. Select the desired device and click Fetch Current Hit Count.
7. 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.
Cisco dCloud
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 checking the hit count for the prefilter rules, you may find the hit count for rules with analyze action are zero,
because hit count is only maintained for rules with fastpath or block actions.
Cisco dCloud
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.
5. To view more detail information about the event, go to the Table View of Events tab.
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
Cisco dCloud
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. dCloud: The Cisco Demo Cloud
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.
Cisco dCloud
2. In the FMC, select Analysis > Files > Malware Events. Click on Table View of 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.
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.
Cisco dCloud
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. 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.
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.
Cisco dCloud
8. Name: Branch1access Select Base Policy: None Default Action: Block all traffic. Click Save.
9. Select Branch1Access.
a. Under Smart Licensing: Check all boxes
b. Under Advanced Type the NAT code from the FTD: abcde.
Cisco dCloud
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.
13. Click on the pencil icon on the GigabitEthernet0/0 interface.
a. The interface name is pre-configured as Outside.
Cisco dCloud
b. Configure the Zone membership. Under Security Zone: Click New, Enter a name: branch1_Outzone.
c. Select the IPv4 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.
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.
Cisco dCloud
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 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
Cisco dCloud
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 dCloud Balanced Intrusion and for File Policy, select TG File
Policy.
Cisco dCloud
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.
Cisco dCloud
i. , verify that the pings were executed for the correct IP i.e. 198.18.133.60
Cisco dCloud
Scenario 2. 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
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.
Cisco dCloud
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.
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.
Cisco dCloud
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.
Cisco dCloud
8. Select wwwin from the Original Source drop-down list.

9. Select Address and wwwout from the Translated Source drop-down list.
10. Click OK to save the NAT rule.
11. Click Save to save the NAT policy.
Cisco dCloud
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.
• Select wwwin, and click Add to Destination.
f. Select the Ports tab.
• Under Available Ports type HTTP and select HTTP and HTTPS and click Add to Destination.
• 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.
g. Select the Inspection tab.
h. Select dCloud Balanced Intrusion from the Intrusion Policy drop-down list.
i. Select TG File Policy from the File Policy drop-down list.
j. Click Add to add the rule.
Cisco dCloud
3. Click Save to save the access control policy changes.
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.
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.
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.
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
Cisco dCloud
Deploy the changes and test the configuration
1. Deploy the changes and wait until the deployment is complete.

2. On the Jump desktop, open the Quick Launch.
a. Click on the preconfigured session called Kali Outside Linux Server.
b. You should be logged in automatically as administrator, password C1sco12345
c. Type curl wwwout. This should succeed.
NOTE: The NGFW is doing proxy ARP for the IP address wwwout
Cisco dCloud
3. On the Jump desktop, open the Quick Launch. Click on the preconfigured session called CSR60. You should be automatically
logged in as admin, password C1sco12345
a. On the CSR60 CLI, run the command show bgp, and confirm that 4 routes appear. dCloud: The Cisco Demo Cloud
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.
Cisco dCloud
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 Devices > Device Management.
8. Next to the NGFW1 device, select the three dots icon, and click on the Health Monitor option. The Health Monitor page
opens.
Cisco dCloud
9. On the Health Monitor page, select the NGFW1 device on the left panel.
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.
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.
c. bgp and click the Execute button.
14. 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. 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.
Cisco dCloud
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
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
Cisco dCloud
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 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.
• 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
• 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
Cisco dCloud
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 dCloud: The Cisco Demo Cloud
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 3. 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
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, open the Quick Launch. Click on the pre-defined Inside Linux server session. You should be
automatically logged in as administrator, with password C1sco12345
2. Similarly, Click on the pre-defined Outside Linux Server session. You should be automatically logged in as administrator,
with password C1sco12345
3. Create a GRE tunnel between the Inside Linux server and Outside Linux server.
Cisco dCloud
NOTE: if you receive a message saying; ifup: failed to open lockfile /run/network/ifstate.tun0: Permission denied. You may need to
run the command as a sudo user: sudo ifup tun0
Cisco dCloud
4.
a. On the Inside Linux Server CLI, type ifup tun0.

b. On the Outside Linux Server CLI, type ifup tun0.
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
• 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.
Cisco dCloud
Cisco dCloud
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.

2. Select Tunnel Zone from the left navigation pane. Verify that tunnel zone with the name GRE exists. .
Cisco dCloud
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.
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.
6. Click Add to add the rule.
7. Click Save to save the prefilter policy.
Cisco dCloud
Modify the access control policy
1. From the menu, select Policies > Access Control > Access Control. The list of access control policies appears.
2. Click the pencil icon next to the NGFW_Policy to edit the policy.
3. Click on the Default Prefilter Policy located at the right of the string Prefilter Policy above the policy rules.
4. In the Prefilter Policy popup window, select NGFW Prefilter Policy, and click OK.
5. Click Save to save the configuration changes.
6. Go back to Policies > Access Control > Access Control page to view the list of the Access Control policies.
7. Click the pencil icon next to the NGFW_Policy to edit the policy.
8. When the NGFW_Policy opens in the policy editor, notice that the Prefilter Policy is configured as NGFW Prefilter 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.
Cisco dCloud
9. 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. Select the Applications tab. 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.
10. 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.
• Select dCloud Balanced Intrusion from the Intrusion Policy drop-down list.
• Select TG 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.
Cisco dCloud
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 sudo 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.
Cisco dCloud
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
Cisco dCloud
Scenario 4. 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 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. Navigate 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.
Cisco dCloud
Configure the NGFW for management by the FMC
4. On the Jump desktop, open the Quick Launch. Click on the preconfigured session called NGFW1. You should be
automatically logged in as 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.
5. 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.
6. Add the FMC by entering the following command:
configure manager add fmc.dcloud.local C1sco12345
7. 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 (Firewall 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.
8. Leave this 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 tasks:
• 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, open the Quick Launch. Click on the Inside Linux server session. You should be automatically
logged in as administrator, password C1sco12345
2. Obtain the runapiscript.

i. Type sudo -i to login as the root user.
ii. Enter password C1sco12345.
iii. Type cd /usr/local/bin.
iv. Remove files by typing rm connect.py runapiscript.
v. Run wget pov.developmentserver.com/dCloud/connect.py. Wait for the file download to complete.
vi. Run wget pov.developmentserver.com/dCloud/runapiscript. Wait for the file download to complete.
vii. Run chmod a+x connect.py runapiscript.
viii. Type exit.
3. On the Inside Linux server CLI run runapiscript.
4. When asked Which firewall do you want to register?, enter 1 (NGFW1) and press Enter.
5. When prompted to enter an access control policy name, enter a name, such as: Firewall_Policy Access Control Policy.
6. You will see the script run through the registration process.
Cisco dCloud
7. 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
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.
8. 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.
Cisco dCloud
Cisco dCloud
Scenario 5. Basic Configuration using FDM

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. On the Jump PC, use the Start menu to open the Chrome 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.
Cisco dCloud
6. Scroll down to the Outside Interface Address.
7. Select the arrow next to Using DHCP.

8. Click on Manually Input.
Cisco dCloud
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
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.
NOTE: If you get a message that the connection to www.cisco.com has failed. Thats ok, move on to setting up the NTP services.
Cisco dCloud
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.
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 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.
16. Select Configure Interfaces. The GUI shows the list of available interfaces in the Interfaces page.
Cisco dCloud
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.
Cisco dCloud
19. Click on the deployment icon (top right side of the GUI) to review the configuration changes that will be deployed to the FTD.
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.
Cisco dCloud

Secure Firewall Lab-Basics 7

Uploaded by

Document Information

Original Description:

Original Title

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

Secure Firewall Lab-Basics 7

Uploaded by

Copyright:

Available Formats

Cisco dCloud

Cisco Secure Firewall 7.2 Basics Lab

ABOUT THIS SOLUTION ........................................................................................................................................2

GET STARTED .......................................................................................................................................................4

SCENARIO 1. ................................................................... BASIC CONFIGURATION AND VERIFICATION OF SETTINGS

SCENARIO 2. ............................................................................................................................ NAT AND ROUTING

SCENARIO 3. ........................................................................................................................... PREFILTER POLICIES

SCENARIO 4. .......................................................................................... DEVICE DEPLOYMENT WITH THE REST API

SCENARIO 5. ................................................................................................... BASIC CONFIGURATION USING FDM

● 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

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

dCloud: The Cisco Demo Cloud

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

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

Review the interface and routing configuration of the device

a. Interface outside is selected in the Interface field.

Modify the access control policy

3. Click Add to Policy, then click Save.

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

• Select InZone1, and click Add to Destination.

• Select OutZone, and click Add to Source.

• Search for SplunkInside in the Available Networks list

• Click Add to Destination

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

6. The Zones tab should already be selected.

a. Select InZone1, and click Add to Source.

b. Select OutZone, and click Add to Destination.

7. Select the Inspection tab.

8. Click Logging and select Log at End of Connection.

dCloud: The Cisco Demo Cloud

9. Click Save to add the rule.

dCloud: The Cisco Demo Cloud

11. Go to the Advanced tab.

a. Click on the pencil icon by Transport/Network Layer Preprocessor Settings.

b. Enter 25 into the Maximum Active Responses input box.

dCloud: The Cisco Demo Cloud

Create a Dynamic NAT rule in NAT policy

1. From the menu, select Devices > NAT.

3. For Name, enter Default PAT.