Chapter 13
Handling Encapsulated Traffic
FTD can analyze encapsulated traffic. It can take an action based on the outermost and innermost headers of an encapsulated packet. As of this writing, FTD supports the Generic Routing Encapsulation (GRE), IP-in-IP, IPv6-in-IP, and Teredo encapsulation protocols. This chapter demonstrates how an FTD device handles an encapsulated packet over a tunnel.
Encapsulation and Prefilter Policy Essentials
An encapsulation protocol, also known as a tunneling protocol, is used to mask the original IP header of a packet and encapsulate the packet with a completely different IP header. Routers can leverage this protocol to transport certain types of traffic that may not be allowed via the underlying network. Some of that traffic includes (but is not limited to) multicast traffic, nonroutable IP traffic, and non-IP traffic. Through encapsulation technology, a user is able to access a network or service that may be denied in the original network.
This chapter uses the GRE encapsulation protocol in its configuration examples. In GRE, one tunnel endpoint encapsulates data packets with an additional header and forwards them to another tunnel endpoint for decapsulation. A router acts as a GRE tunnel endpoint.
Figure 13-1 shows how a GRE header and an IP header (outer) encapsulate a TCP header and its original IP header (inner).
You can deploy a prefilter policy in FTD to analyze the encapsulated packets based on their outermost headers. When a packet matches with a rule on a prefilter policy, FTD takes an appropriate action before the packet hits any other security policies.
Figure 13-2 illustrates how a prefilter policy can act as a gatekeeper to the rest of the security policies.
FTD, by default, enables a default prefilter policy. You can change the settings of the default policy. However, you cannot delete this system-provided policy, nor can you add a new rule to this policy. The only configurable option is the default action against the traffic. There are two choices for the default action—Analyze All Tunnel Traffic and Block All Tunnel Traffic. These default actions are illustrated later in the "Prefilter Policy Settings” section of this chapter (see Figure 13-5).
A custom prefilter policy allows you to add a tunnel rule, which can offer granular control over the tunnel traffic. By using a custom tunnel rule, you can bypass the encapsulated pass-through traffic from any further inspection.
This chapter uses both the default policy and a custom policy to demonstrate the flow of an encapsulated packet in various conditions.
Best Practices for Adding a Prefilter Rule
You can deploy a prefilter policy on an FTD device to define how the FTD should handle any encapsulated traffic. When a prefilter rule matches encapsulated traffic, the remaining non-encapsulated traffic is automatically forwarded to the next level of inspection. You do not need to create a separate prefilter rule to allow the non-encapsulated traffic.
Fulfilling Prerequisites
This chapter assumes that you have prior experience with GRE protocol implementation. In addition, to prepare a lab to implement the examples in this chapter, you need to complete the following tasks:
Deploy an FTD device between two routers and configure a simple GRE tunnel between them. FTD must be able to see all the traffic between the routers.
Build two pairs of subnetworks, where one subnet pair transfers traffic over an encapsulated tunnel, and the other pair uses a regular non-encapsulated network. You can use either physical hosts or loopback interfaces to represent the endpoints.
Figure 13-3 shows two subnets in each location—a branch office and a data center. Network 2 in the branch office and Network 200 in the data center are connected over a GRE tunnel. The remaining subnets (Network 1 and Network 100) use the non-encapsulated route.
Table 13-1 provides a summary of the addressing scheme used in this chapter. The lab exercises in this chapter demonstrate that when Network 2 and Network 200 communicate, the traffic uses the GRE tunnel and is subject to the action in a prefilter policy. The packet flow between Network 1 and Network 100 always remains the same, regardless of any action you define for tunnel traffic.
Table 13-1 Overview of the IP Addresses Used in This Lab
Network |
Location |
Subnet |
Packet Header |
Network 1 |
Branch |
192.168.1.0/24 |
Not encapsulated |
Network 2 |
Branch |
192.168.2.0/24 |
Encapsulated |
Network 100 |
Data center |
192.168.100.0/24 |
Not encapsulated |
Network 200 |
Data center |
192.168.200.0/24 |
Encapsulated |
To demonstrate a TCP connection between the subnetworks, this chapter uses Telnet service. The method to initiate a Telnet connection varies, depending on the Telnet client or operating system you use. This book assumes that you know how to establish a Telnet connection.
Transferring and Capturing Traffic on the Firewall Engine
To examine the flows of both encapsulated and non-encapsulated packets through an FTD device, enable two independent capture processes—one for GRE encapsulated packets and the other one for non-encapsulated Telnet packets:
> capture gre_traffic trace interface INSIDE_INTERFACE match gre any any
> capture telnet_traffic trace interface INSIDE_INTERFACE match tcp any any eq 23
>
Make sure the capture is running but not capturing any data until you manually send traffic. Example 13-1 shows confirmation that the capture process is running. The “0 bytes” output indicates that the FTD device has not received any packets.
Example 13-1 The Capture Process Is Running but FTD Has Not Received Any Packets to Capture
> show capture
capture gre_traffic type raw-data trace interface INSIDE_INTERFACE [Capturing - 0
bytes]
match gre any any
capture telnet_traffic type raw-data trace interface INSIDE_INTERFACE [Capturing - 0
bytes]
match tcp any any eq telnet
>
To transfer and capture traffic on the firewall engine, follow these steps:
Step 1. Connect to host 192.168.100.1/24 from host 192.168.1.1/24, using the Telnet application. It should generate non-encapsulated Telnet packets. You can verify this by viewing the capture process, as shown in Example 13-2, which demonstrates that the Telnet connection between 192.168.1.1/24 and 192.168.100.1/24 triggers the telnet_traffic access rule and generates 3572 bytes of traffic.
Example 13-2 Capture is Running—FTD has Captured Telnet Packets
> show capture
capture gre_traffic type raw-data trace interface INSIDE_INTERFACE [Capturing - 0 bytes]
match gre any any
capture telnet_traffic type raw-data trace interface INSIDE_INTERFACE
[Capturing - 3572 bytes]
match tcp any any eq telnet
>
Note
The method to initiate a Telnet connection varies, depending on the Telnet client you use. You can use any tool or an operating system to establish a Telnet connection.
Step 2. Connect to host 192.168.200.1/24 from host 192.168.2.1/24 by using the Telnet application. This should generate GRE encapsulated packets. Although you have used the Telnet application, the packets have TCP headers inside and the GRE headers outside. You can verify this by viewing the GRE traffic statistics in the capture process. Example 13-3 shows that the Telnet connection between 192.168.2.1/24 and 192.168.200.1/24 triggers the gre_traffic access rule instead of the telnet_traffic access rule. It proves that the Telnet connection between these two subnets uses the GRE tunnel.
Example 13-3 FTD Capturing GRE Packets After Sending Traffic over the Tunnel
> show capture
capture gre_traffic type raw-data trace interface INSIDE_INTERFACE [Capturing - 4748
bytes]
match gre any any
capture telnet_traffic type raw-data trace interface INSIDE_INTERFACE
[Capturing - 3572 bytes]
match tcp any any eq telnet
>
Hosts in this lab use two different paths to transfer encapsulated and non-encapsulated traffic. The “Fulfilling Prerequisites” section of this chapter describes the router configurations in Figure 13-3.
To clear the previously captured packets from memory and to begin the capture again, run the clear capture command:
> clear capture /all
Scenario 1: Analyzing Encapsulated Traffic
This first scenario shows how to enable the analysis of encapsulated traffic. Here is a summary of the steps you need to perform:
Step 1. Configure prefilter and access control policies on the FMC and deploy them in FTD.
Step 2. Transfer traffic through the encapsulated tunnel and the non-encapsulated path.
Step 3. Capture packets with tracing data for further analysis.
Configuring Policies to Analyze Encapsulated Traffic
To analyze encapsulated traffic, Firepower uses the settings from both a prefilter policy and an access control policy. A prefilter policy allows you to select an encapsulation protocol and an action on encapsulated traffic. An access control policy invokes a prefilter policy and deploys it on an FTD device. By default, a new access control policy invokes the settings from the system-provided default prefilter policy.
Tip
If your goal is to simply analyze or block all tunnel traffic, select a default action in the default prefilter policy to keep the configuration simple. However, if you need separate tunnel rules for different types of encapsulated traffic, create a custom prefilter policy. A default prefilter policy does not allow you to add custom rules.
Prefilter Policy Settings
To verify the settings of the default prefilter policy, go to the Policies > Access Control > Prefilter page. Use the pencil icon to edit the default prefilter policy. Figure 13-4 shows the Prefilter Policy page. By default, FTD provides the default prefilter policy, and uses it in an access control policy.
To analyze encapsulated traffic, select the Analyze All Tunnel Traffic option. This allows an FTD device to forward an encapsulated packet to the next level of inspection.
Figure 13-5 shows the configurable options in the default prefilter policy. You cannot add rules to the default prefilter policy; you can only select a default action from the dropdown.
Access Control Policy Settings
By default, FTD does not generate a connection event when an access control policy has no access rule. You can change this behavior by enabling logging for the default action of an access control policy. Receiving connection events for a default action indicates that traffic is going through the access control policy. Therefore, this chapter does not use a custom access rule.
Figure 13-6 shows the selection of Intrusion Prevention: Balanced Security and Connectivity as the default action. Select the logging icon located next to the Default Action dropdown. The Logging window appears.
Figure 13-7 shows the Logging window. You can enable logging either at the beginning or at the end of a connection, but not for both because doing so could affect the system performance.
After you make any changes to the prefilter or access control policies, you must save the settings and redeploy the access control policy to activate the new changes.
Verifying the Configuration and Connection
After you have configured the policies to generate connection events for both types of traffic—encapsulated and non-encapsulated—to verify their operation, you need to capture traffic from the ASA firewall engine. If a capture is already running, you can remove the previously captured packets by running the clear capture command:
> clear capture /all
Note
The steps for capturing Telnet and GRE traffic are described earlier in this chapter, in the section “Transferring and Capturing Traffic on the Firewall Engine.” To learn more about the packet capture option, read Chapter 10, “Capturing Traffic for Advanced Analysis.”
Once you enable the captures, use Telnet to connect to Network 100 from Network 1. Similarly, connect to Network 200 from Network 2. Both connection attempts should be successful. You can view the associated connection events in the FMC.
Figure 13-8 shows two connection events for two separate Telnet connections—originated from Network 1 and Network 2. Because FTD can analyze the inner header of an encapsulated packet, the FMC shows the original IP address—not the address on the outermost header—in a connection event.
If you do not see the events as shown in Figure 13-8, make sure you have enabled logging for the default action. You can verify the logging settings by running the show access-control-config command (see Example 13-4). If you did not enable logging, read the section “Configuring Policies to Analyze Encapsulated Traffic,” earlier in this chapter.
Example 13-4 shows confirmation that the default action of the access control policy is configured to generate a log at the beginning of a connection.
Example 13-4 Verifying the Setting for the Default Action
> show access-control-config
===================[ AC Policy ]====================
Description :
Default Action : Allow
Default Policy : Balanced Security and Connectivity
Logging Configuration
DC : Enabled
Beginning : Enabled
End : Disabled
Rule Hits : 0
Variable Set : Default-Set
.
.
.
! Type 'q' to quit
<Output Omitted for Brevity>
If you do not see an expected connection event, you can turn on the firewall-engine-debug tool to determine if (and why) a packet goes through the engines. As an access rule inspects a packet, the tool displays the internal ID for an active rule and its associated action in real time.
Example 13-5 shows debug messages for both encapsulated and non-encapsulated Telnet connections. If FTD generates debug messages during both connection attempts, it confirms that the Firepower inspection engines are able to see and inspect traffic inside and outside a tunnel.
Example 13-5 Debugging the Firewall Engine
> system support firewall-engine-debug
Please specify an IP protocol: tcp
Please specify a client IP address:
Please specify a client port:
Please specify a server IP address:
Please specify a server port:
Monitoring firewall engine debug messages
! The following messages appear when you connect to 192.162.100.1/24 from the host
192.168.1.1/24 over the non-encapsulated path. It triggers the default action
(rule id: 268434432) on the Access Control policy:
.
192.168.1.1-43286 > 192.168.100.1-23 6 AS 5 I 1 New session
192.168.1.1-43286 > 192.168.100.1-23 6 AS 5 I 1 using HW or preset rule order 2,
id 268434432 action Allow and prefilter rule 0
192.168.1.1-43286 > 192.168.100.1-23 6 AS 5 I 1 allow action
192.168.1.1-43286 > 192.168.100.1-23 6 AS 5 I 1 Deleting session
.
.
! The following output appears when you connect to 192.162.200.1/24 from the host
192.168.2.1/24 over the GRE tunnel. It triggers the prefilter rule id 9988:
.
192.168.2.1-23208 > 192.168.200.1-23 6 AS 5 I 0 New session
192.168.2.1-23208 > 192.168.200.1-23 6 AS 5 I 0 using prefilter rule 9998 with
tunnel zone -1
192.168.2.1-23208 > 192.168.200.1-23 6 AS 5 I 0 Starting with minimum 0, id 0 and
SrcZone first with zones -1 -> -1, geo 0(0) -> 0, vlan 0, sgt tag: untagged,
svc 0, payload 0, client 0, misc 0, user 9999997, url , xff
192.168.2.1-23208 > 192.168.200.1-23 6 AS 5 I 0 match rule order 2, id 268434432
action Allow
192.168.2.1-23208 > 192.168.200.1-23 6 AS 5 I 0 allow action
.
.
<Output Omitted for Brevity>
If you want to know exactly which rule will trigger a message on the firewall-engine-debug output, first take note of the rule ID from the debug output, and then find it in the list of active access rules. Example 13-6 shows the list of active access rules on an FTD device. You can find any tunnel, prefilter, and access rules with their associated internal rule IDs in this list.
Example 13-6 Verifying Prefilter Policy Configuration by Using 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_; 6 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=3)
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 268434432: ACCESS POLICY: AC Policy -
Default/1
access-list CSM_FW_ACL_ line 9 remark rule-id 268434432: L4 RULE: DEFAULT ACTION RULE
access-list CSM_FW_ACL_ line 10 advanced permit ip any any rule-id 268434432
(hitcnt=2) 0xa1d3780e
>
Analyzing Packet Flows
Now that you have captured Telnet and GRE packets, you can retrieve any particular captured packets directly on the CLI of the FTD device. Remember that in order to view the detailed tracing data of a packet, you must add the trace keyword with the capture command. To learn more, read the section “Transferring and Capturing Traffic on the Firewall Engine,” earlier in this chapter.
Example 13-7 shows the output of the show capture command, which enables you to view the three-way handshake (SYN, SYN-ACK, and ACK) of a TCP connection. Each packet is assigned a number (on the left side of each row) that you can use for further analysis.
Example 13-7 Retrieving Non-encapsulated Telnet Packets
> show capture telnet_traffic
49 packets captured
1: 12:57:33.942105 192.168.1.1.46774 > 192.168.100.1.23: S 636710801:
636710801(0) win 4128 <mss 536>
2: 12:57:33.945706 192.168.100.1.23 > 192.168.1.1.46774: S 1516450804:
1516450804(0) ack 636710802 win 4128 <mss 536>
3: 12:57:33.947140 192.168.1.1.46774 > 192.168.100.1.23: . ack 1516450805
win 4128
4: 12:57:33.947186 192.168.1.1.46774 > 192.168.100.1.23: P 636710802:
636710814(12) ack 1516450805 win 4128
.
.
<Output Omitted for Brevity>
Example 13-8 shows the detailed flow of a captured packet. This example uses packet number 1, which is a SYN packet from 192.168.1.1 to 192.168.100.1.
Example 13-8 Analyzing a Non-encapsulated Telnet Packet
> show capture telnet_traffic packet-number 1 trace
49 packets captured
1: 12:57:33.942105 192.168.1.1.46774 > 192.168.100.1.23: S 636710801:
636710801(0) win 4128 <mss 536>
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 102, 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
Result:
input-interface: INSIDE_INTERFACE
input-status: up
input-line-status: up
Action: allow
1 packet shown
>
Example 13-9 shows the packets encapsulated with GRE headers (IP number 47). The external IP address 203.0.113.1 represents the internal host 192.168.1.1. Each packet has a reference number (on the left side of each row) that you can use later, during flow analysis.
Example 13-9 Retrieving the Encapsulated GRE Packets
> show capture gre_traffic
49 packets captured
1: 12:59:01.441536 203.0.113.1 > 203.0.113.100: ip-proto-47, length 48
2: 12:59:01.444190 203.0.113.100 > 203.0.113.1: ip-proto-47, length 48
3: 12:59:01.446525 203.0.113.1 > 203.0.113.100: ip-proto-47, length 44
4: 12:59:01.446571 203.0.113.1 > 203.0.113.100: ip-proto-47, length 56
5: 12:59:01.446601 203.0.113.1 > 203.0.113.100: ip-proto-47, length 44
6: 12:59:01.449378 203.0.113.100 > 203.0.113.1: ip-proto-47, length 44
7: 12:59:01.450156 203.0.113.100 > 203.0.113.1: ip-proto-47, length 56
8: 12:59:01.450217 203.0.113.100 > 203.0.113.1: ip-proto-47, length 84
.
.
<Output Omitted for Brevity>
Example 13-10 shows tracing data for a GRE-encapsulated packet. Because this is tunnel traffic, the default prefilter policy forwards it to the inspection engine for further analysis.
Example 13-10 Analyzing a GRE-Encapsulated Packet
> show capture gre_traffic packet-number 1 trace
49 packets captured
1: 12:59:01.441536 203.0.113.1 > 203.0.113.100: ip-proto-47, length 48
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 gre any any rule-id 9998
access-list CSM_FW_ACL_ remark rule-id 9998: PREFILTER POLICY: Default Tunnel and
Priority Policy
access-list CSM_FW_ACL_ remark rule-id 9998: RULE: DEFAULT TUNNEL 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 103, 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
Result:
input-interface: INSIDE_INTERFACE
input-status: up
input-line-status: up
Action: allow
1 packet shown
>
Scenario 2: Blocking Encapsulated Traffic
In this second scenario, FTD blocks tunnel traffic due to a configuration on the default prefilter policy. The physical topology or the router configurations remains unchanged.
Configuring Policies to Block Encapsulated Traffic
To block all tunnel traffic, you can use the FTD default prefilter policy. However, if you want to block tunnel traffic from a particular source and destination, you need to add a prefilter rule for it. This exercise uses the default prefilter policy because the goal is to analyze the flow of a blocked packet over the tunnel:
Step 1. Go to Policies > Access Control > Prefilter.
Step 2. Click the pencil icon to edit the default prefilter policy.
Step 3. In the policy editor page, from the Default Action dropdown select Block All Tunnel Traffic (see Figure 13-9).
Step 4. Optionally, use the logging icon, next to the dropdown, to enable logging when the default prefilter policy blocks any tunnel traffic (see Figure 13-10).
Step 5. Click Save to save the policy, and click Deploy to deploy it to the FTD device.
Verifying the Configuration and Connection
After you have reconfigured the prefilter policy to block all tunnel traffic, to verify its operation, enable two independent captures for Telnet and GRE traffic. If the FTD device has been running capture, you can remove any previously captured packets by running the clear capture command:
> clear capture /all
Note
The steps for capturing Telnet and GRE traffic are described in the section “Transferring and Capturing Traffic on the Firewall Engine,” earlier in this chapter. If you want to learn more about packet capture option, read Chapter 10.
In addition, run the firewall-engine-debug tool at the FTD CLI. It allows you to analyze any activities in real time as the traffic comes.
When you enable both the capture and the firewall-engine-debug tools, you can generate live traffic through the FTD device by attempting to establish Telnet connections to Network 100 and Network 200 from Network 1 and Network 2, respectively. In this scenario, Network 1 and Network 100 should be able to establish a Telnet connection, but Network 2 should fail to connect to Network 200 due to the Block action on the prefilter policy.
Example 13-11 does not show any tunnel traffic in the firewall-engine-debug output. Because the traffic is blocked before it hits an inspection engine, the firewall-engine-debug tool cannot see and log the Block action.
Example 13-11 Debugging Connections When a Prefilter Policy Blocks All Tunnel Traffic
! The non-encapsulated traffic from 192.168.1.1 to 192.168.100.1 is allowed by a
rule (id 268434432).
> system support firewall-engine-debug
Please specify an IP protocol: tcp
Please specify a client IP address:
Please specify a client port:
Please specify a server IP address:
Please specify a server port:
Monitoring firewall engine debug messages
! An action on the traffic from 192.168.1.1 to 192.168.100.1 is logged below:
192.168.1.1-36257 > 192.168.100.1-23 6 AS 5 I 0 New session
192.168.1.1-36257 > 192.168.100.1-23 6 AS 5 I 0 using HW or preset rule order 2, id
268434432 action Allow and prefilter rule 0
192.168.1.1-36257 > 192.168.100.1-23 6 AS 5 I 0 allow action
192.168.1.1-36257 > 192.168.100.1-23 6 AS 5 I 0 Deleting session
! Traffic from 192.168.2.1 to 192.168.200.1 does not appear here; because they are
encapsulated and therefore, blocked by the Prefilter policy.
^C
Caught interrupt signal
Exiting.
>
The firewall-engine-debug output shows rule ID 268434432 with the Allow action, but it does not display the condition that triggers this particular rule. To learn about a rule condition, you can view the list of all active access rules and find the associated rule ID for a specific rule.
Example 13-12 elaborates the default actions of both the prefilter and access control policies. The tunnel traffic is denied by rule 9998, and any other traffic is permitted by rule 268434432 and forwarded for Firepower deep packet inspection.
Example 13-12 List of Access Rules by the Prefilter and Access Control Default Actions
> 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_; 6 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 deny ipinip any any rule-id 9998 event-log
flow-start (hitcnt=0) 0x128a09cb
access-list CSM_FW_ACL_ line 4 advanced deny 41 any any rule-id 9998 event-log
flow-start (hitcnt=0) 0x6e21b1ba
access-list CSM_FW_ACL_ line 5 advanced deny gre any any rule-id 9998 event-log
flow-start (hitcnt=4) 0xe9c037af
access-list CSM_FW_ACL_ line 6 advanced deny udp any eq 3544 any range 1025 65535
rule-id 9998 event-log flow-start (hitcnt=0) 0x77ac07e0
access-list CSM_FW_ACL_ line 7 advanced deny udp any range 1025 65535 any eq 3544
rule-id 9998 event-log flow-start (hitcnt=0) 0x3054708b
access-list CSM_FW_ACL_ line 8 remark rule-id 268434432: ACCESS POLICY: AC Policy -
Default/1
access-list CSM_FW_ACL_ line 9 remark rule-id 268434432: L4 RULE: DEFAULT ACTION RULE
access-list CSM_FW_ACL_ line 10 advanced permit ip any any rule-id 268434432
(hitcnt=12) 0xa1d3780e
>
For the successful and unsuccessful Telnet attempts, the FMC should display connection events. You can find them in the Analysis > Connections > Events page.
Table 13-2 summarizes the actions in a lab network when FTD is configured to block all tunnel traffic.
Table 13-2 Expected Behavior in Lab Scenario 2 When the Tunnel Traffic Is Blocked
Network |
Policy Action |
Event Log |
Non-encapsulated traffic between Network 1 and Network 100 |
The prefilter policy does not interrupt traffic because the traffic is non-encapsulated. It is allowed by the default action of the access control policy. |
An Allow event is logged by the default action of the access control policy. |
Encapsulated traffic between Network 2 and Network 200 |
The prefilter policy blocks all of the tunnel traffic, per configuration, before it hits any inspection engines. |
A Blocked event is logged by the default action of the prefilter policy. |
Figure 13-11 shows that the default action of the default prefilter policy blocks a GRE connection. Because the packet is blocked and not analyzed afterward, FTD does not reveal the innermost IP header. As a result, the connection event shows the IP addresses of the router interfaces.
If you do not see an event that you expect to see, make sure you enabled logging for the default actions on both the prefilter and access control policies. In addition, you must check to make sure the latest access control policy where you saved the recent changes is active. You can verify it by checking the status of the access control policy, at Policies > Access Control > Access Control.
Analyzing Packet Flows
The packet flows between 192.168.1.1/24 and 192.168.100.1/24 are identical in Scenario 1 and Scenario 2—regardless of the default action you choose for tunnel traffic—because these hosts transfer traffic over a non-encapsulated path. However, in Scenario 2, FTD blocks traffic between the hosts 192.168.2.1/24 and 192.168.200.1/24 because they attempt to route their traffic over the tunnel.
Example 13-13 displays the Telnet traffic over a tunnel. First, it shows the encapsulation of a packet with a GRE header (IP number 47). Then it analyzes the blocking of a GRE packet due to the default tunnel action rule 9998.
Example 13-13 Analyzing the GRE-Encapsulated Traffic When It Is Blocked by FTD
> show capture gre_traffic
4 packets captured
1: 18:46:45.801670 203.0.113.1 > 203.0.113.100: ip-proto-47, length 48
2: 18:46:47.802708 203.0.113.1 > 203.0.113.100: ip-proto-47, length 48
3: 18:46:51.802952 203.0.113.1 > 203.0.113.100: ip-proto-47, length 48
4: 18:46:59.803165 203.0.113.1 > 203.0.113.100: ip-proto-47, length 48
4 packets shown
>
> show capture gre_traffic packet-number 1 trace
4 packets captured
1: 18:46:45.801670 203.0.113.1 > 203.0.113.100: ip-proto-47, length 48
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 gre any any rule-id 9998 event-log flow-start
access-list CSM_FW_ACL_ remark rule-id 9998: PREFILTER POLICY: Default Tunnel and Priority Policy
access-list CSM_FW_ACL_ remark rule-id 9998: RULE: DEFAULT TUNNEL ACTION RULE
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
>
Scenario 3: Bypassing Inspection
In this third scenario, FTD bypasses only the tunnel traffic, while any other non-encapsulated traffic can still go through the FTD device, as in Scenarios 1 and 2. The physical topology or the router configurations remain untouched.
Configuring Policies to Bypass Inspection
The default prefilter policy can allow or block the tunnel traffic, but it does not offer an option to bypass inspection. To bypass, you need to create a custom prefilter policy and invoke it in an access control policy that you want to deploy.
Custom Prefilter Policy
Use the following steps to create a custom prefilter policy:
Step 1. Navigate to Policies > Access Control > Prefilter.
Step 2. In the Prefilter Policy page that appears, click the New Policy button to create a new prefilter policy. Figure 13-12 shows the name of a new policy—Custom Tunnel and Prefilter Policy. In the background, you can see the New Policy button as well.
Step 3. When the New Policy window appears, name the policy and click the Save button for the policy. The policy editor page appears.
Step 4. On the policy editor page, click the Add Tunnel Rule button. The Add Tunnel Rule configuration window appears. Figure 13-13 shows the prefilter policy editor page. A user-created policy offers two additional options—Add Tunnel Rule and Add Prefilter Rule.
Step 5. Assign a name to your custom tunnel rule and select Fastpath from the Action dropdown.
Step 6. Make sure the rule is enabled, and select the radio button Match Tunnels from Source and Destination.
Step 7. Click the Encapsulation & Ports tab and enable GRE in the list of encapsulation protocols. Optionally, you can go to the Tunnel Endpoints tab and select the source and destination tunnel endpoints. These tunnel endpoints are the IP addresses of both sides of the tunnels. You can configure them the same way you would configure a network address within an access rule or a prefilter rule.
Figure 13-14 shows the configuration of a tunnel rule named GRE Tunnel Rule. The rule matches GRE tunnel traffic from source and destination, and it uses Fastpath with them for any further inspection.
Step 8. Optionally, go to the Logging tab and enable logging at the beginning of a connection (see Figure 13-15). This allows an FTD device to generate a log when this particular rule triggers.
Step 9. Click the Add button. The GUI returns to the policy editor page.
Step 10. Click the Save button to save the policy. To activate the new custom prefilter policy, you must invoke it in the current access control policy.
Figure 13-16 shows a basic but complete configuration of a tunnel rule. It enables any GRE packets to bypass further inspection.
Access Control Policy Settings
FTD, by default, invokes the default prefilter policy. You can select a particular policy using the access control policy editor page. Here are the steps to follow:
Step 1. Go to Policies > Access Control. A list of available access control policies appears.
Step 2. Select the pencil icon to edit the desired policy. The access control policy editor page appears.
Step 3. In the top-left corner, click the Default Prefilter Policy link.
Step 4. In the Prefilter Policy popup window that appears, select your desired policy from the dropdown. Figure 13-17 shows the access control policy configurations for Scenario 3. First, you must select a custom prefilter policy that has the Fastpath rule. Then you need to enable logging for default action. Finally, you can save and deploy the policy.
Step 5. Optionally, enable logging for the default action. This allows you to determine whether a packet hits the default action of an access control policy or bypasses the inspection before it hits the default action.
Step 6. Finally, click Save to save the changes, and click Deploy to deploy the revised access control policy to your FTD device. It should activate the revised prefilter policy as well.
Now, connect to Network 200 from Network 2 via Telnet. Because these networks are connected over the GRE tunnel, FTD allows the traffic between them to bypass any additional inspection. You can verify this by viewing the associated connection events on the Analysis > Connection > Events page.
Figure 13-18 shows a Fastpath event that is triggered by the GRE tunnel rule. In this case, because FTD does not analyze the inside of the encapsulated traffic, the connection event shows the outermost headers (IP addresses of the router interfaces) instead of the innermost headers.
If FTD still does not bypass the tunnel traffic and acts based on the previous prefilter policy, try clearing the existing connections on the FTD. This forces the hosts to establish new connections by using the new policy.
To clear all the existing connections, run the following command:
> clear conn all
To clear connections from a certain host, run the following command:
> clear conn address IP_Address_of_a_Host
Verifying the Configuration and Connection
You have just enabled a custom prefilter policy to bypass all tunnel traffic. To verify its operation, enable two independent captures for the Telnet and GRE protocols. If FTD has been running capture, you can remove any previously captured packets by running the clear capture command:
> clear capture /all
Note
The steps for capturing Telnet and GRE traffic are described in the section “Transferring and Capturing Traffic on the Firewall Engine,” earlier in this chapter. If you want to learn more about packet capture option, read Chapter 10.
In addition, run the firewall-engine-debug tool on the CLI of your FTD device to analyze any activities in real time as the traffic comes.
Once you enable both the capture and the firewall-engine-debug tools, you can generate live traffic through the FTD device by trying to establish Telnet connections between Network 1 and Network 100 and between Network 2 and Network 200. In Scenario 3, both connection attempts are successful; however, the debug engine does not see traffic from Network 2 and Network 200 because it is encapsulated and bypasses further inspection.
Example 13-14 shows the debugging of a connection between Network 1 and Network 100. Although the Telnet connection was successful, the output does not show any related debug message because a Fastpath rule in the custom prefilter policy allows the encapsulated traffic to bypass any further inspection.
Example 13-14 Firewall Engine Debug Output—When the Tunnel Traffic Bypasses FTD
> system support firewall-engine-debug
Please specify an IP protocol: tcp
Please specify a client IP address:
Please specify a client port:
Please specify a server IP address:
Please specify a server port:
Monitoring firewall engine debug messages
! Traffic from 192.168.1.1 to 192.168.100.1 is non-encapsulated, therefore it is
inspected by a rule (id 268434432).
192.168.1.1-40591 > 192.168.100.1-23 6 AS 5 I 1 New session
192.168.1.1-40591 > 192.168.100.1-23 6 AS 5 I 1 using HW or preset rule order 3,
id 268434432 action Allow and prefilter rule 0
192.168.1.1-40591 > 192.168.100.1-23 6 AS 5 I 1 allow action
192.168.1.1-40591 > 192.168.100.1-23 6 AS 5 I 1 Deleting session
! Traffic from 192.168.2.1 to 192.168.200.1 are transferred over a GRE tunnel.
Therefore, they are bypassed from any further inspection, and do not appear here
in the firewall-engine-debug output.
^C
Caught interrupt signal
Exiting.
>
Example 13-15 confirms the deployment of the Fastpath rule named GRE Tunnel Rule. An FTD device trusts the traffic when the rule uses the Fastpath action.
Example 13-15 A Fastpath Rule Shows a Trust Action in the CLI Access List
> 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 268438530: PREFILTER POLICY: Custom
Tunnel and Prefilter Policy
access-list CSM_FW_ACL_ line 2 remark rule-id 268438530: RULE: GRE Tunnel Rule
access-list CSM_FW_ACL_ line 3 advanced trust gre any any rule-id 268438530
event-log both (hitcnt=3) 0xbc125eb0
access-list CSM_FW_ACL_ line 4 remark rule-id 268438529: PREFILTER POLICY: Custom
Tunnel and Prefilter Policy
access-list CSM_FW_ACL_ line 5 remark rule-id 268438529: RULE: DEFAULT TUNNEL ACTION RULE
access-list CSM_FW_ACL_ line 6 advanced permit ipinip any any rule-id 268438529
(hitcnt=0) 0xf5b597d6
access-list CSM_FW_ACL_ line 7 advanced permit 41 any any rule-id 268438529
(hitcnt=0) 0x06095aba
access-list CSM_FW_ACL_ line 8 advanced permit gre any any rule-id 268438529
(hitcnt=0) 0x52c7a066
access-list CSM_FW_ACL_ line 9 advanced permit udp any eq 3544 any range 1025 65535
rule-id 268438529 (hitcnt=0) 0x46d7839e
access-list CSM_FW_ACL_ line 10 advanced permit udp any range 1025 65535 any eq 3544
rule-id 268438529 (hitcnt=0) 0xaf1d5aa5
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=16) 0xa1d3780e
>
Analyzing Packet Flows
The packet flows between 192.168.1.1/24 and 192.168.100.1/24 are the same in all three scenarios in this chapter—regardless of any action you apply on the tunnel traffic—because these hosts transfer traffic over a non-encapsulated path. However, in Scenario 3, FTD allows the traffic between the hosts 192.168.2.1/24 and 192.168.200.1/24 to bypass inspection, because these hosts transfer traffic over the GRE encapsulated tunnel.
Example 13-16 shows the capture of encapsulated packets with GRE headers (IP number 47). Due to the Fastpath rule trust gre any any, FTD bypasses them without any further inspection.
Example 13-16 Analyzing the Bypassing of a GRE-Encapsulated Packet
> show capture gre_traffic
49 packets captured
1: 01:17:27.046475 203.0.113.1 > 203.0.113.100: ip-proto-47, length 48
2: 01:17:27.048871 203.0.113.100 > 203.0.113.1: ip-proto-47, length 48
3: 01:17:27.050397 203.0.113.1 > 203.0.113.100: ip-proto-47, length 44
.
.
<Output Omitted for Brevity>
> show capture gre_traffic packet-number 1 trace
49 packets captured
1: 01:17:27.046475 203.0.113.1 > 203.0.113.100: ip-proto-47, length 48
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 trust gre any any rule-id 268438530 event-log both
access-list CSM_FW_ACL_ remark rule-id 268438530: PREFILTER POLICY: Custom Tunnel
and Prefilter Policy
access-list CSM_FW_ACL_ remark rule-id 268438530: RULE: GRE Tunnel Rule
Additional Information:
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 131, packet dispatched to next module
Result:
input-interface: INSIDE_INTERFACE
input-status: up
input-line-status: up
Action: allow
1 packet shown
>
Summary
In this chapter, you have learned how to analyze and block traffic that is encapsulated with the GRE protocol, and how to bypass inspection when the traffic is transferred over a tunnel. This chapter also presents various tools you can use to analyze the actions of the prefilter and access control policies.
Quiz
1. Which of the following statements is true?
a. To analyze any tunnel traffic, you must create and apply a prefilter policy.
b. An access control policy overrides the rules in a prefilter policy.
c. The Fastpath action in a prefilter policy bypasses the rules in an access control policy; however, traffic is still subject to intrusion policy inspection.
d. None of the above.
2. Which of the following tunnel protocols is supported by FTD?
a. GRE
b. IP-in-IP
c. IPv6-in-IP
d. All of the above
3. Which of the following commands confirms whether logging is enabled for the default action in an access control policy?
a. show logging
b. show access-list
c. show default-action
d. show access-control-config
4. The firewall-engine-debug tool shows debug-level messages for which of the following components?
a. A tunnel rule
b. A prefilter rule
c. An access rule