Chapter 11
Blocking Traffic Using Inline Interface Mode
An FTD device in Inline interface mode can block unintended traffic while it remains invisible to the network hosts. However, in Chapter 9, “Firepower Deployment in Transparent Mode,” you learned about Transparent Mode, which can also block traffic and keeps itself transparent in the network. So, why would someone choose Inline Mode? This chapter explores the advantages of Inline Mode and demonstrates its action and configuration.
Inline Mode Essentials
FTD supports a wide variety of block actions, such as simple blocking, blocking with reset, interactive blocking, and interactive blocking with reset. However, a block action cannot drop any suspicious packet if the interfaces are not set up properly.
Figure 11-1 shows a list of the actions that you can apply to an access rule. Note the different types of block actions FTD supports.
FTD enables you to choose any interface mode, regardless of the underlying deployment mode—Routed or Transparent. However, ultimately, the capability of an interface mode defines whether FTD is able to block any suspicious traffic it sees.
Table 11-1 lists various FTD modes and describes their abilities to block traffic. The deployment mode in this table defines how FTD functions as a firewall. The interface mode defines how FTD acts on the traffic in case of any suspicious activities.
Table 11-1 Ability to Block Traffic in Various Modes
Deployment Mode |
Interface Mode |
Able to Block Traffic? |
Routed |
|
Yes |
Transparent |
|
Yes |
|
Inline |
Yes |
|
Inline-tap |
No |
|
Passive |
No |
|
Passive (ERSPAN) |
No |
Inline Mode Versus Passive Mode
An intrusion detection and prevention system detects suspicious activities and prevents network attacks. You can deploy an FTD device either as an intrusion detection system (IDS) or to function as an intrusion prevention system (IPS). To prevent any potential intrusion attempt in real time, you must deploy an FTD device in Inline Mode. In Inline Mode, the ingress and egress interfaces are bundled into an interface pair. Each pair must be associated with an inline set, which is a logical group of one or more interface pairs.
Figure 11-2 illustrates how two interfaces (GigabitEthernet1/1 with GigabitEthernet1/2 and GigabitEthernet1/3 with GigabitEthernet1/4) can build the inline pairs. Note that both of the inline pairs are included in Inline Set 1 in this illustration.
An FTD device in Passive Mode, on the contrary, can only detect intrusion attempts. A switch or tap mirrors all the packets it receives and sends a copy of each packet to the FTD device using port mirroring. Because the original traffic does not go through an FTD device, FTD is unable to take any action on a packet. In other words, an FTD device in Passive Mode cannot block any intrusion attempt; it can only detect an attempt based on the traffic it sees.
Figure 11-3 provides an example of a typical FTD deployment. The topology shows two FTD devices deployed in two different modes—Inline (IPS) and Passive (IDS).
Inline Mode Versus Transparent Mode
Both Inline Mode and Transparent Mode work like bumps in the wire, which means they are invisible to the connected devices. However, they are two different techniques.
In Inline Mode, the interfaces on an interface pair are network agnostic. They can send and receive any traffic, as long as the policies permit. In addition, you do not need to configure IP addresses on any of the member interfaces of an inline-pair.
In contrast, an FTD device in Transparent Mode places the inside and outside networks into a virtual bridge group and creates a Layer 2 bridging network. Traffic originates from an FTD device using a Bridged Virtual Interface (BVI) as its source interface. The BVI, inside network, and outside network must all be configured with the IP addresses from a single subnet.
You can enable Network Address Translation (NAT) in the Transparent Mode; however, FTD does not support NAT in the Inline Mode.
Tracing a Packet Drop
After receiving a packet from the ingress interface, FTD processes the packets and takes an action based on the deployed access rules and intrusion rules. In Chapter 10, “Capturing Traffic for Advanced Analysis,” you learned how to capture live traffic from an interface. In this chapter, you are going to leverage the capturing tool to trace a drop of a packet through an FTD device.
Figure 11-4 illustrates the potential reasons for a packet drop by an FTD device. After FTD filters traffic using its traditional firewall rules, the Firepower/Snort engine inspects traffic.
To record additional tracing data during a capture, you need to use the trace parameter with the capture command. For example, to capture any HTTP traffic received on an inside interface, you used the following command in Chapter 10:
> capture http_traffic interface INSIDE_INTERFACE match tcp any any eq 80
Now, to capture tracing data for each packet, you can add the trace parameter, as shown here:
> capture http_traffic trace interface INSIDE_INTERFACE match tcp any any eq 80
To view the additional tracing data for a specific packet, add the number of that packet with the trace keyword, as shown here:
> show capture http_traffic packet-number 1 trace
Moreover, FTD provides a tool called packet-tracer, which can generate simulated packets using the information of five tuples: source IP address, destination IP address, source port number, destination port number, and protocol. By considering the deployed rule conditions, this tool simulates traffic flow from the ingress interface to the egress interface, as if a client and server were communicating using a network protocol through the FTD. Here is an example:
> packet-tracer input INSIDE_INTERFACE tcp 192.168.1.2 10000 192.168.1.200 80
This command generates a virtual packet flow from the INSIDE_INTERFACE with the following header information:
Source IP Address: 192.168.1.2
Destination IP Address: 192.168.1.200
Source Port: 10000
Destination Port: 80
Protocol: TCP
Later in this chapter you will use both capture trace and packet-trace tools to determine where a packet gets dropped. For now, just keep this concept in mind.
Best Practices for Inline Mode Configuration
When you create an inline set, consider the following during configurations:
If your network uses asynchronous routing, and the inbound and outbound traffic go through two different interface pairs, you should include both interface pairs in the same interface set. Doing so ensures that FTD does not see just half of the traffic; it can see the flows from both directions and recognize them when they are part of a single connection.
If the interfaces of an inline pair are connected to switches that run Spanning Tree Protocol (STP), you should enable PortFast on the associated switch ports. It allows those switch ports to transition to the forwarding state immediately and reduces hardware bypass time.
You should enable the FailSafe feature on the inline interface set. In case of a software failure, this feature allows FTD to continue its traffic flow through the device by bypassing the detection.
You should allow the inline set to propagate its link state. This reduces the routing convergence time when one of the interfaces in an inline set goes down.
The configuration examples in this chapter discuss the steps to enable FailSafe and the Propagate Link State feature on an inline set.
Configuring Inline Mode
In this section, you are going to configure and verify three important elements of an inline interface:
You will create a simple inline set and verify traffic flow.
You will enable the fault tolerance features on an inline set to avoid downtime in case of a failure.
You will learn how to block a particular service or port through an inline interface.
Figure 11-5 provides an overview of the lab topology that is used in this chapter. The configuration examples and the command outputs in this chapter are based on this topology.
Fulfilling Prerequisites
If you previously configured an FTD device as a firewall in routed mode, you need to remove any platform settings, the IP address, and DHCP server configurations from the FTD data interfaces, as they are not necessary in Inline Mode.
Creating an Inline Set
An inline set is a logical group of one or more interface pairs. Before you add an inline set, you must create an inline interface pair and associate the pair with the inline set you want to add.
To create an inline set, follow these steps:
Step 1. Navigate to the Devices > Device Management page. A list of all the devices that are registered with FMC appears.
Step 2. Click the pencil icon next to the FTD device (see Figure 11-6).
Step 3. Select the Interfaces tab. A list of the available interfaces appears, and you can set up or modify interface settings by using this page.
Step 4. Select the pencil icon next to each interface that will be part of an inline pair—in this case, the GigabitEthernet1/1 and GigabitEthernet1/2 interfaces (see Figure 11-7).
Step 5. In the Edit Physical Interface window, the default value of the Mode dropdown is None. Keep it unchanged, as this represents Inline Mode. Then assign a name to the interface and click the Enabled check box to enable it. An IP address is not necessary.
Figure 11-8 shows the settings on the GigabitEthernet1/1 interface. This example uses the names INSIDE_INTERFACE and OUTSIDE_INTERFACE for the GigabitEthernet1/1 and GigabitEthernet1/2 interfaces, respectively.
Step 6. Click OK to return to the Interfaces tab and repeat Steps 4 and 5 for the other interface of the pair.
Step 7. After both interfaces are named and enabled, click the Save button to save the changes.
Figure 11-9 shows an overview of each interface configuration. Note that the IP address or security zone is not configured. Only the logical interface is necessary for an inline interface.
Now, begin the second part of the configuration—adding the interface pair to an inline set—by following these steps:
Step 1. On the Devices > Device Management page, go to the Inline Sets tab and click the Add Inline Set button. The Add Inline Set window appears.
Step 2. In the Add Inline Set window, give a name to the inline set, select an interface pair, and add it to the inline set (see Figure 11-10).
Note
Do not configure any additional settings at this moment. You will come back here when you learn the fault tolerance configuration later in this chapter.
Step 3. Click OK to return to the Inline Sets tab.
Step 4. Click Save to save the configuration, and click Deploy to deploy it to FTD (see Figure 11-11).
Verifying the Configuration
Upon a successful deployment, you should be able to ping from your inside host 192.168.1.2 to the outside server 192.168.1.200.
Figure 11-12 shows the table view of a connection event. The event confirms that host 192.168.1.2 is able to send ICMP echo requests to 192.168.1.200.
If a ping test fails but the FMC does not show any reason for a failure, you can troubleshoot by checking the interface status.
Example 11-1 shows the output of the show inline-set command on the FTD CLI. This command provides various components of an inline set configuration, such as member interfaces of an inline pair, the status of each interface, and advanced settings.
Example 11-1 Status of the INSIDE_OUTSIDE_PAIR Inline Set
> show inline-set
Inline-set INSIDE_OUTSIDE_PAIR
Mtu is 1500 bytes
Failsafe mode is off
Failsecure mode is off
Tap mode is off
Propagate-link-state option is off
hardware-bypass mode is disabled
Interface-Pair[1]:
Interface: GigabitEthernet1/1 "INSIDE_INTERFACE"
Current-Status: UP
Interface: GigabitEthernet1/2 "OUTSIDE_INTERFACE"
Current-Status: UP
Bridge Group ID: 500
>
Example 11-2 shows the overall status of the available interfaces on an FTD device. It confirms that the GigabitEthernet1/1 and GigabitEthernet1/2 interfaces are up and configured with no IP address. However, it does not confirm if they are part of an inline pair.
Example 11-2 Summary of the FTD Interface Status
> show interface ip brief
Interface IP-Address OK? Method Status Protocol
Virtual0 127.1.0.1 YES unset up up
GigabitEthernet1/1 unassigned YES unset up up
GigabitEthernet1/2 unassigned YES unset up up
GigabitEthernet1/3 unassigned YES unset administratively down down
GigabitEthernet1/4 unassigned YES unset administratively down down
GigabitEthernet1/5 unassigned YES unset administratively down down
GigabitEthernet1/6 unassigned YES unset administratively down down
GigabitEthernet1/7 unassigned YES unset administratively down down
GigabitEthernet1/8 unassigned YES unset administratively down down
Internal-Control1/1 127.0.1.1 YES unset up up
Internal-Data1/1 unassigned YES unset up up
Internal-Data1/2 unassigned YES unset down down
Internal-Data1/3 unassigned YES unset up up
Internal-Data1/4 169.254.1.1 YES unset up up
Management1/1 unassigned YES unset up up
>
Example 11-3 confirms that the GigabitEthernet1/1 interface is in Inline Mode, and it is included in an inline pair called INSIDE_OUTSIDE_PAIR. It also provides detailed statistics about the traffic.
Example 11-3 Detailed Statistic About the GigabitEthernet1/1 Interface
> show interface GigabitEthernet1/1
Interface GigabitEthernet1/1 "INSIDE_INTERFACE", is up, line protocol is up
Hardware is Accelerator rev01, BW 1000 Mbps, DLY 10 usec
Auto-Duplex(Full-duplex), Auto-Speed(1000 Mbps)
Input flow control is unsupported, output flow control is off
MAC address a46c.2ae4.6bc0, MTU 1500
IPS Interface-Mode: inline, Inline-Set: INSIDE_OUTSIDE_PAIR
IP address unassigned
2382 packets input, 258694 bytes, 0 no buffer
Received 142 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 pause input, 0 resume input
0 L2 decode drops
2079 packets output, 234133 bytes, 0 underruns
0 pause output, 0 resume output
0 output errors, 0 collisions, 0 interface resets
0 late collisions, 0 deferred
0 input reset drops, 2 output reset drops
input queue (blocks free curr/low): hardware (946/894)
output queue (blocks free curr/low): hardware (1023/1020)
Traffic Statistics for "INSIDE_INTERFACE":
592 packets input, 53381 bytes
530 packets output, 63776 bytes
11 packets dropped
1 minute input rate 1 pkts/sec, 85 bytes/sec
1 minute output rate 1 pkts/sec, 88 bytes/sec
1 minute drop rate, 0 pkts/sec
5 minute input rate 1 pkts/sec, 79 bytes/sec
5 minute output rate 0 pkts/sec, 103 bytes/sec
5 minute drop rate, 0 pkts/sec
>
Verifying Packet Flow by Using packet-tracer
If the interface status and configuration seem correct but the hosts in the inside and outside networks are still unable to communicate, you can use a simulated packet to determine the flow of a packet through an FTD device. The packet-tracer command can generate a virtual packet based on the parameters you enter with it. In the next example, you will simulate the flow of an ICMP packet using the following syntax:
packet-tracer input source_interface protocol_name source_address ICMP_type
ICMP_code destination_address
Note
The packet-tracer command syntax is different for a TCP packet. You will learn how to use it near the end of this chapter, when the blocking of a TCP service/port is simulated.
In an ICMP header, the type and code fields contain the control messages. There are many different types of ICMP control messages available. In the following exercise, however, you are going to use two types of messages—echo request and echo reply.
Figure 11-13 shows the format of an ICMP packet. The 8-bit type and 8-bit code fields carry the ICMP control messages.
Table 11-2 shows the values of the type and code fields. Using these values, you can generate a particular ICMP control message.
Table 11-2 Values for the Echo Request and Echo Reply Messages
Control Message |
Type |
Code |
Echo request |
8 |
0 |
Echo reply |
0 |
0 |
Example 11-4 demonstrates the simulation of ICMP traffic, sent from the inside interface. The host 192.168.1.2 from the inside network sends an ICMP echo request to an outside system, 192.168.1.200. The ingress and egress interfaces of this simulated packet are determined by the inline set configuration of the FTD device.
Example 11-4 Simulating an ICMP Echo Request
> packet-tracer input INSIDE_INTERFACE icmp 192.168.1.2 8 0 192.168.1.200
Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 2
Type: NGIPS-MODE
Subtype: ngips-mode
Result: ALLOW
Config:
Additional Information:
The flow ingressed an interface configured for NGIPS mode and NGIPS services will be
applied
Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip any any rule-id 268434432
access-list CSM_FW_ACL_ remark rule-id 268434432: ACCESS POLICY: AC Policy - Default/1
access-list CSM_FW_ACL_ remark rule-id 268434432: L4 RULE: DEFAULT ACTION RULE
Additional Information:
This packet will be sent to snort for additional processing where a verdict will be
reached
Phase: 4
Type: NGIPS-EGRESS-INTERFACE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
Ingress interface INSIDE_INTERFACE is in NGIPS inline mode.
Egress interface OUTSIDE_INTERFACE is determined by inline-set configuration
Phase: 5
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 269, packet dispatched to next module
Result:
input-interface: INSIDE_INTERFACE
input-status: up
input-line-status: up
Action: allow
>
Example 11-5 concludes that an ICMP echo reply packet, originated by the host 192.168.1.200, should be able to reach its destination, 192.168.1.2.
Example 11-5 Simulating an ICMP Echo Reply
> packet-tracer input OUTSIDE_INTERFACE icmp 192.168.1.200 0 0 192.168.1.2
Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 2
Type: NGIPS-MODE
Subtype: ngips-mode
Result: ALLOW
Config:
Additional Information:
The flow ingressed an interface configured for NGIPS mode and NGIPS services will be
applied
Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip any any rule-id 268434432
access-list CSM_FW_ACL_ remark rule-id 268434432: ACCESS POLICY: AC Policy - Default/1
access-list CSM_FW_ACL_ remark rule-id 268434432: L4 RULE: DEFAULT ACTION RULE
Additional Information:
This packet will be sent to snort for additional processing where a verdict will be
reached
Phase: 4
Type: NGIPS-EGRESS-INTERFACE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
Ingress interface OUTSIDE_INTERFACE is in NGIPS inline mode.
Egress interface INSIDE_INTERFACE is determined by inline-set configuration
Phase: 5
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 271, packet dispatched to next module
Result:
input-interface: OUTSIDE_INTERFACE
input-status: up
input-line-status: up
Action: allow
>
Verifying Packet Flow by Using Real Packet Capture
In the previous section, you used virtually generated packets to simulate the flow of packets. In this section, you are going to use real ping requests to determine the flow of a packet through an FTD. Follow these steps:
Step 1. Enter two capture rules with tracing capability, as shown in Example 11-6. They begin capturing ICMP traffic. To trace packets from both directions, you need to capture traffic from both of the interfaces of an inline pair.
Example 11-6 demonstrates the use of the trace keyword with the capture command. The example uses the capture command twice, to capture traffic from the ingress and egress interfaces separately. The Capturing - 0 bytes message on the show capture command confirms that the process is running but has not seen any packets yet.
Example 11-6 Creating and Verifying Matching Conditions for Packet Captures
> capture inside_icmp trace interface INSIDE_INTERFACE match icmp any any
> capture outside_icmp trace interface OUTSIDE_INTERFACE match icmp any any
> show capture
capture inside_icmp type raw-data trace interface INSIDE_INTERFACE [Capturing - 0
bytes]
match icmp any any
capture outside_icmp type raw-data trace interface OUTSIDE_INTERFACE [Capturing - 0
bytes]
match icmp any any
>
Step 2. Send a few ping requests from your inside host to the outside system. After sending and receiving two to four ICMP packets, stop the ping request. You should now be able to see the capture between the inside and outside systems. Example 11-7 shows the captures of ICMP traffic from both directions on both interfaces.
Example 11-7 Captures of the ICMP Traffic
> show capture inside_icmp
4 packets captured
1: 21:52:25.988428 192.168.1.2 > 192.168.1.200: icmp: echo request
2: 21:52:25.989405 192.168.1.200 > 192.168.1.2: icmp: echo reply
3: 21:52:26.989862 192.168.1.2 > 192.168.1.200: icmp: echo request
4: 21:52:26.990412 192.168.1.200 > 192.168.1.2: icmp: echo reply
4 packets shown
>
> show capture outside_icmp
4 packets captured
1: 21:52:25.989038 192.168.1.2 > 192.168.1.200: icmp: echo request
2: 21:52:25.989252 192.168.1.200 > 192.168.1.2: icmp: echo reply
3: 21:52:26.990106 192.168.1.2 > 192.168.1.200: icmp: echo request
4: 21:52:26.990305 192.168.1.200 > 192.168.1.2: icmp: echo reply
4 packets shown
>
Step 3. From Example 11-7, select a packet you want to trace, using its associated number on the left. In this lab scenario, the host 192.168.1.2 sends the echo request packet from the inside interface. That’s why you use the inside_icmp capture to view the tracing data. Similarly, when you want to trace the echo reply packet from the host 192.168.1.200, you need to use the outside_icmp capture.
Example 11-8 shows the flow of packet number 1 from Example 11-7. You must use the trace keyword to view the tracing data.
Example 11-8 Tracing an Echo-Request Packet Originated by the Host 192.168.1.2
> show capture inside_icmp packet-number 1 trace
4 packets captured
1: 21:52:25.988428 192.168.1.2 > 192.168.1.200: icmp: echo request
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list
Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 3
Type: NGIPS-MODE
Subtype: ngips-mode
Result: ALLOW
Config:
Additional Information:
The flow ingressed an interface configured for NGIPS mode and NGIPS services will be
applied
Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip any any rule-id 268434432
access-list CSM_FW_ACL_ remark rule-id 268434432: ACCESS POLICY: AC Policy - Default/1
access-list CSM_FW_ACL_ remark rule-id 268434432: L4 RULE: DEFAULT ACTION RULE
Additional Information:
This packet will be sent to snort for additional processing where a verdict will be
reached
Phase: 5
Type: NGIPS-EGRESS-INTERFACE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
Ingress interface INSIDE_INTERFACE is in NGIPS inline mode.
Egress interface OUTSIDE_INTERFACE is determined by inline-set configuration
Phase: 6
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 279, packet dispatched to next module
Phase: 7
Type: EXTERNAL-INSPECT
Subtype:
Result: ALLOW
Config:
Additional Information:
Application: 'SNORT Inspect'
Phase: 8
Type: SNORT
Subtype:
Result: ALLOW
Config:
Additional Information:
Snort Verdict: (pass-packet) allow this packet
Phase: 9
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list
Result:
input-interface: OUTSIDE_INTERFACE
input-status: up
input-line-status: up
Action: allow
1 packet shown
>
Example 11-9 shows two different outputs for tracing the same packet. Only the second command shows the desired detail because the outside interface receives the echo reply packet.
Example 11-9 Tracing an Echo Reply Packet Originated by the Host 192.168.1.200
> show capture inside_icmp packet-number 2 trace
4 packets captured
2: 21:52:25.989405 192.168.1.200 > 192.168.1.2: icmp: echo reply
1 packet shown
>
> show capture outside_icmp packet-number 2 trace
4 packets captured
2: 21:52:25.989252 192.168.1.200 > 192.168.1.2: icmp: echo reply
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list
Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 3
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found flow with id 279, using existing flow
Phase: 4
Type: EXTERNAL-INSPECT
Subtype:
Result: ALLOW
Config:
Additional Information:
Application: 'SNORT Inspect'
Phase: 5
Type: SNORT
Subtype:
Result: ALLOW
Config:
Additional Information:
Snort Verdict: (pass-packet) allow this packet
Phase: 6
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list
Result:
input-interface: INSIDE_INTERFACE
input-status: up
input-line-status: up
Action: allow
1 packet shown
>
Tip
To learn how to inactivate a capture on an interface or how to delete a capture process permanently, see Chapter 10.
Enabling Fault Tolerance Features
In Inline Mode, traffic goes through an FTD device. FTD can interrupt the traffic flow in case of any software or hardware failure. To avoid any network outage, the Firepower system offers various fault tolerance features, such as FailSafe and Link State Propagation, as described in the following sections.
Configuring Fault Tolerance Features
This section assumes that you have already configured your FTD device in basic Inline Mode by following the steps described in the previous section. Now, you are going to edit that configuration to enable two fault tolerance features:
FailSafe: In the event of any software failure, if FTD stops processing traffic, and the buffer becomes full, FTD drops traffic. The FailSafe feature watches the use of the buffer. When the buffer is full, FailSafe allows the traffic to go through FTD without any inspection. Hence, users do not experience any permanent network outage.
Propagate Link State: If one of the links of an inline pair goes down, the second link can stay up and able to receive traffic. However, FTD cannot transfer traffic through an interface that has no link. The Propagate Link State feature automatically brings the remaining interface down if one of the interfaces in an inline pair goes down. This feature improves routing convergence time by not sending traffic through a failed link.
Follow these steps to enable FailSafe and Propagate Link State:
Step 1. Navigate to the Devices > Device Management page. Click the pencil icon next to the FTD device where you created the inline set.
Step 2. In the device editor page, go to the Inline Sets tab. Click the pencil icon next to the inline set that you want to modify. The Add Inline Set window appears.
Step 3. Go to the General tab and select the FailSafe check box (see Figure 11-14).
Step 4. Go to the Advanced tab and select the Propagate Link State check box (see Figure 11-15).
Step 5. Click the OK button to return to the device editor page.
Step 6. Click Save to save the changes, and click Deploy to deploy the settings to FTD.
Verifying Fault Tolerance Features
After you reconfigure an inline set with the FailSafe and Propagate Link State features, you can run the show inline-set command to verify the changes. Example 11-10 confirms that the FailSafe and Propagate Link State features are enabled successfully.
Example 11-10 Viewing the Inline Set Configuration from the CLI
> show inline-set
Inline-set INLINE_OUTSIDE_PAIR
Mtu is 1500 bytes
Failsafe mode is on/activated
Failsecure mode is off
Tap mode is off
Propagate-link-state option is on
hardware-bypass mode is disabled
Interface-Pair[1]:
Interface: GigabitEthernet1/1 "INSIDE_INTERFACE"
Current-Status: Down(Propagate-Link-State-Activated)
Interface: GigabitEthernet1/2 "OUTSIDE_INTERFACE"
Current-Status: Down(Down-By-Propagate-Link-State)
Bridge Group ID: 500
>
To verify that the Propagate Link State feature works as expected, you can unplug the cable from one of the interfaces and run the show interface command to determine the status. Example 11-11 shows the output of the show interface command. After unplugging the cable from the GigabitEthernet1/1 interface, the second interface, GigabitEthernet1/2, has also gone down.
Example 11-11 Viewing the Status of the Propagate Link State Feature
> show interface GigabitEthernet1/1
Interface GigabitEthernet1/1 "INSIDE_INTERFACE", is down, line protocol is down
Hardware is Accelerator rev01, BW 1000 Mbps, DLY 10 usec
Auto-Duplex, Auto-Speed
Input flow control is unsupported, output flow control is off
MAC address a46c.2ae4.6bc0, MTU 1500
IPS Interface-Mode: inline, Inline-Set: INSIDE_OUTSIDE_PAIR
Propagate-Link-State-Activated
IP address unassigned
14779 packets input, 1512926 bytes, 0 no buffer
Received 147 broadcasts, 0 runts, 0 giants
.
.
<Output Omitted for Brevity>
> show interface GigabitEthernet1/2
Interface GigabitEthernet1/2 "OUTSIDE_INTERFACE", is administratively down, line protocol is down
Hardware is Accelerator rev01, BW 1000 Mbps, DLY 10 usec
Auto-Duplex, Auto-Speed
Input flow control is unsupported, output flow control is off
MAC address a46c.2ae4.6bc1, MTU 1500
IPS Interface-Mode: inline, Inline-Set: INSIDE_OUTSIDE_PAIR
Down-By-Propagate-Link-State
IP address unassigned
15397 packets input, 1558479 bytes, 0 no buffer
Received 930 broadcasts, 0 runts, 0 giants
.
.
<Output Omitted for Brevity>
Blocking a Specific Port
Now that you have configured the inline interface pair, you will try to block a particular port or service using an FTD device. In the previous section, you used ICMP to determine the traffic flow. In this section, you will configure an FTD device to block the cleartext Telnet traffic—a TCP protocol that uses port 23.
Configuring Blocking a Specific Port
The following steps describe how to add an access rule that can block any packets destined for port 23:
Step 1. Navigate to the Policies > Access Control > Access Control page.
Step 2. Click the pencil icon next to an access control policy that you want to deploy to an FTD device.
Step 3. When the policy editor page appears, click the Add Rule button to create a new rule. The Add Rule window appears. Figure 11-16 shows the addition of an access rule that blocks traffic destined for port 23 (the Telnet service port).
Step 4. Give the access rule a name, enable the rule, and select the Block action.
Step 5. In the Ports tab, find the Telnet service in the Available Ports list and add the Telnet port to the destination.
Step 6. Go to the Logging tab and select Log at Beginning of Connection. This optional step allows you to view an event when a Telnet connection is blocked. Figure 11-17 shows logging being enabled for the Shell Access access rule. When this access rule blocks a Telnet connection, the web interface displays a Block event for it.
Step 7. Click the Add button to return to the policy editor page.
Step 8. To define a default action, select Balanced Security and Connectivity from the dropdown. This allows any nonmalicious traffic other than the Telnet traffic to go through.
Figure 11-18 shows the policy editor page after you add the rule to block Telnet traffic.
Step 9. Click Save to save the configuration, and click Deploy to deploy the Access Control Policy to FTD.
Verifying Blocking of a Specific Port
After a successful deployment of the updated access control policy, you can go to your inside host 192.168.1.2 to access the outside system 192.168.1.200 using Telnet. Your attempt to connect through the Telnet port should not work because FTD is now blocking any traffic destined for port 23. For a blocked connection, the FMC should also log a connection event.
Figure 11-19 illustrates two types of connection events—block and allow. The Telnet traffic is blocked by the Shell Access rule, while any other traffic (such as ping requests) is allowed by the Default Action rule.
Example 11-12 displays the Shell Access rule that you created to block Telnet traffic. In the line following this rule, you can find the default action to permit any other traffic. The hitcnt value increases as more Telnet traffic is blocked by FTD.
Example 11-12 Viewing the Access Control Rules from the CLI
> show access-list
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)
alert-interval 300
access-list CSM_FW_ACL_; 7 elements; name hash: 0x4a69e3f3
access-list CSM_FW_ACL_ line 1 remark rule-id 9998: PREFILTER POLICY: Default Tunnel
and Priority Policy
access-list CSM_FW_ACL_ line 2 remark rule-id 9998: RULE: DEFAULT TUNNEL ACTION RULE
access-list CSM_FW_ACL_ line 3 advanced permit ipinip any any rule-id 9998 (hitcnt=0)
0xf5b597d6
access-list CSM_FW_ACL_ line 4 advanced permit 41 any any rule-id 9998 (hitcnt=0)
0x06095aba
access-list CSM_FW_ACL_ line 5 advanced permit gre any any rule-id 9998 (hitcnt=0)
0x52c7a066
access-list CSM_FW_ACL_ line 6 advanced permit udp any eq 3544 any range 1025 65535
rule-id 9998 (hitcnt=0) 0x46d7839e
access-list CSM_FW_ACL_ line 7 advanced permit udp any range 1025 65535 any eq 3544
rule-id 9998 (hitcnt=0) 0xaf1d5aa5
access-list CSM_FW_ACL_ line 8 remark rule-id 268440576: ACCESS POLICY: AC Policy -
Mandatory/1
access-list CSM_FW_ACL_ line 9 remark rule-id 268440576: L4 RULE: Shell Access
access-list CSM_FW_ACL_ line 10 advanced deny tcp any any object-group TELNET
rule-id 268440576 event-log flow-start (hitcnt=2) 0xae7f8544
access-list CSM_FW_ACL_ line 10 advanced deny tcp any any eq telnet rule-id
268440576 event-log flow-start (hitcnt=2) 0x2bcbaf06
access-list CSM_FW_ACL_ line 11 remark rule-id 268434432: ACCESS POLICY: AC Policy -
Default/1
access-list CSM_FW_ACL_ line 12 remark rule-id 268434432: L4 RULE: DEFAULT ACTION RULE
access-list CSM_FW_ACL_ line 13 advanced permit ip any any rule-id 268434432
(hitcnt=134) 0xa1d3780e
>
Analyzing a Packet Drop by Using a Simulated Packet
You can use the packet-tracer tool to generate a virtual TCP packet and simulate the flow of the packet through an FTD device. It allows you to analyze any potential packet drop due to the access control policy.
Example 11-13 simulates the requests for Telnet traffic access from both networks—inside and outside—in two packet-tracer outputs. Both requests are blocked by the Shell Access rule that you created earlier. This example uses port 23 as the destination port and assumes port number 10000 as a randomly generated source port.
Example 11-13 Simulating a TCP Packet Drop
! Packet originates from the inside network, Telnet server is located at the outside
network
> packet-tracer input INSIDE_INTERFACE tcp 192.168.1.2 10000 192.168.1.200 23
Phase: 1
Type: NGIPS-MODE
Subtype: ngips-mode
Result: ALLOW
Config:
Additional Information:
The flow ingressed an interface configured for NGIPS mode and NGIPS services will be
applied
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: DROP
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced deny tcp any any object-group TELNET rule-id
268440576 event-log flow-start
access-list CSM_FW_ACL_ remark rule-id 268440576: ACCESS POLICY: AC Policy -
Mandatory/1
access-list CSM_FW_ACL_ remark rule-id 268440576: L4 RULE: Shell Access
object-group service TELNET tcp
port-object eq telnet
Additional Information:
Result:
input-interface: INSIDE_INTERFACE
input-status: up
input-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
>
! Packet originates from the outside network, Telnet server is located at the inside
network
> packet-tracer input OUTSIDE_INTERFACE tcp 192.168.1.200 10000 192.168.1.2 23
Phase: 1
Type: NGIPS-MODE
Subtype: ngips-mode
Result: ALLOW
Config:
Additional Information:
The flow ingressed an interface configured for NGIPS mode and NGIPS services will be
applied
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: DROP
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced deny tcp any any object-group TELNET rule-id
268440576 event-log flow-start
access-list CSM_FW_ACL_ remark rule-id 268440576: ACCESS POLICY: AC Policy -
Mandatory/1
access-list CSM_FW_ACL_ remark rule-id 268440576: L4 RULE: Shell Access
object-group service TELNET tcp
port-object eq telnet
Additional Information:
Result:
input-interface: OUTSIDE_INTERFACE
input-status: up
input-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
>
Analyzing a Packet Drop by Using a Real Packet
If your network experiences any connectivity issue, and you do not see any configuration errors, you can capture the live traffic with the tracing feature enabled. This allows you to analyze a real packet—how it goes through an FTD device and how it is blocked by an access rule when it matches a condition. The following steps describe the process:
Step 1. Create a rule that can capture any traffic destined for port 23. You must apply the rule on the interface that sees the incoming requests.
Example 11-14 shows a command that is able to capture any traffic with destination port 23. You must use the trace keyword to capture additional tracing data. After you enter the command, you can view the status of a capture by using the show capture command.
Example 11-14 Capturing Telnet Traffic with Tracing Data
> capture inside_telnet trace interface INSIDE_INTERFACE match tcp any any eq 23
>
> show capture
capture inside_telnet type raw-data trace interface INSIDE_INTERFACE [Capturing - 0
bytes]
match tcp any any eq telnet
>
Step 2. Try to access the Telnet server. Although it fails due to the Shell Access rule, your failure attempt generates Telnet traffic that you will analyze next.
Example 11-15 displays four packets with destination port 23. They are captured using the command provided in Example 11-14.
Example 11-15 FTD Capturing Four Telnet Packets
> show capture inside_telnet
4 packets captured
1: 01:24:06.440422 192.168.1.2.36534 > 192.168.1.200.23: S 2986077586:
2986077586(0) win 29200 <mss 1460,sackOK,timestamp 3482899 0,nop,wscale 7>
2: 01:24:07.437965 192.168.1.2.36534 > 192.168.1.200.23: S 2986077586:
2986077586(0) win 29200 <mss 1460,sackOK,timestamp 3483149 0,nop,wscale 7>
3: 01:24:09.442009 192.168.1.2.36534 > 192.168.1.200.23: S 2986077586:
2986077586(0) win 29200 <mss 1460,sackOK,timestamp 3483650 0,nop,wscale 7>
4: 01:24:13.450217 192.168.1.2.36534 > 192.168.1.200.23: S 2986077586:
2986077586(0) win 29200 <mss 1460,sackOK,timestamp 3484652 0,nop,wscale 7>
4 packets shown
>
Step 3. Select a packet by using its number and view the packet by using the show capture command. Add the trace parameter with the command in order to view additional tracing data. Example 11-16 shows the dropping of a TCP packet through an FTD device. The tracing data confirms that the packet was dropped due to an access rule.
Example 11-16 Viewing a Captured Packet with Tracing Data
> show capture inside_telnet packet-number 2 trace
4 packets captured
2: 01:24:07.437965 192.168.1.2.36534 > 192.168.1.200.23: S 2986077586:
2986077586(0) win 29200 <mss 1460,sackOK,timestamp 3483149 0,nop,wscale 7>
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list
Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 3
Type: NGIPS-MODE
Subtype: ngips-mode
Result: ALLOW
Config:
Additional Information:
The flow ingressed an interface configured for NGIPS mode and NGIPS services will be
applied
Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: DROP
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced deny tcp any any object-group TELNET rule-id
268440576 event-log flow-start
access-list CSM_FW_ACL_ remark rule-id 268440576: ACCESS POLICY: AC Policy -
Mandatory/1
access-list CSM_FW_ACL_ remark rule-id 268440576: L4 RULE: Shell Access
object-group service TELNET tcp
port-object eq telnet
Additional Information:
Result:
input-interface: INSIDE_INTERFACE
input-status: up
input-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
1 packet shown
>
Summary
In this chapter, you have learned how to configure an FTD device in Inline Mode, how to enable fault tolerance features on an inline set, and how to trace a packet in order to analyze the root cause of a drop. This chapter also describes various command-line tools that you can use to verify the status of an interface, an inline pair, and an inline set.
Quiz
1. Which of the following statements is true?
a. The configuration steps for Inline Mode and Transparent Mode are the same.
b. An inline pair uses a loopback IP address for communication.
c. The FailSafe feature is enabled on an inline set by default.
d. The Propagate Link State feature is not enabled by default on an inline set.
2. Which of the following statements is true?
a. You should include both interface pairs in the same inline set to ensure the recognition of asynchronous traffic.
b. The FailSafe feature allows an FTD device to continue its traffic flow through the device by bypassing the detection.
c. Propagate Link State reduces the routing convergence time when one of the interfaces in an inline set goes down.
d. All of the above.
3. Which command provides an overview of the various components of an inline interface set?
a. show interface ip brief
b. show inline-set
c. show interface detail
d. show interface inline detail
4. To determine whether a packet is dropped by an access rule, which of the following options is provided by FTD?
a. Capture traffic in .pcap file format and open the file in an external packet analyzer.
b. Use the packet-tracer tool to trace a live packet directly.
c. Capture the traffic and use the trace functionality, and view the packets by using the capture command.