Tunnel Content Inspection Overview
Table of Contents
Tunnel Content Inspection Overview
Your firewall can inspect tunnel content anywhere on
the network where you do not have the opportunity to terminate the
tunnel first. As long as the firewall is in the path of a GRE, non-encrypted
IPSec, GTP-U, or VXLAN tunnel, the firewall
can inspect the tunnel content.
- Enterprise customers who want tunnel content inspection can have some or all of the traffic on the firewall tunneled using GRE, VXLAN, or non-encrypted IPSec. For security, QoS, and reporting reasons, you want to inspect the traffic inside the tunnel.
- Service Provider customers use GTP-U to tunnel data traffic from mobile devices. You want to inspect the inner content without terminating the tunnel protocol, and you want to record user data from your users.
The firewall supports tunnel content inspection on Ethernet interfaces,
subinterfaces, AE interfaces, VLAN interfaces, and VPN and LSVPN
tunnel interfaces. (The cleartext tunnel that the firewall inspects
can be inside a VPN or LSVPN tunnel that terminates at the firewall,
hence a VPN or LSVPN tunnel interface. In other words, when the
firewall is a VPN or LSVPN endpoint, the firewall can inspect the
traffic of any non-encrypted tunnel protocols that tunnel content
inspection supports.)
Tunnel content inspection is supported in Layer 3, Layer 2, virtual
wire, and tap deployments. Tunnel content inspection works on shared
gateways and on virtual system-to-virtual system communications.
The preceding figure illustrates the two levels of tunnel inspection
the firewall can perform. When a firewall configured with Tunnel
Inspection policy rules receives a packet:
- The firewall first performs a Security policy check to determine whether the tunnel protocol (Application) in the packet is permitted or denied. (IPv4 and IPv6 packets are supported protocols inside the tunnel.)
- If the Security policy allows the packet, the firewall matches the packet to a Tunnel Inspection policy rule based on source zone, source address, source user, destination zone, and destination address. The Tunnel Inspection policy rule determines the tunnel protocols that the firewall inspects, the maximum level of encapsulation allowed (a single tunnel or a tunnel within a tunnel), whether to allow packets containing a tunnel protocol that doesn’t pass strict header inspection per RFC 2780, and whether to allow packets containing unknown protocols.
- If the packet passes the Tunnel Inspection policy rule’s match criteria, the firewall inspects the inner content, which is subject to your Security policy (required) and optional policies you can specify. (The supported policy types for the original session are listed in the following table).
- If the firewall instead finds another tunnel, the firewall recursively parses the packet for the second header and is now at level two of encapsulation, so the second tunnel inspection policy rule, which matches a tunnel zone, must allow a maximum tunnel inspection level of two levels for the firewall to continue processing the packet.
- If your rule allows two levels of inspection, the firewall performs a Security policy check on this inner tunnel and then the Tunnel Inspection policy check. The tunnel protocol you use in an inner tunnel can differ from the tunnel protocol you use in the outer tunnel.
- If your rule doesn’t allow two levels of inspection, the firewall bases its action on whether you configured it to drop packets that have more levels of encapsulation than the maximum tunnel inspection level you configured.
By default, the content encapsulated in a tunnel belongs to the
same security zone as the tunnel, and is subject to the Security
policy rules that protect that zone. However, you can configure
a tunnel zone, which gives you the flexibility to configure
Security policy rules for inside content that differ from the Security
policy rules for the tunnel. If you use a different tunnel inspection
policy for the tunnel zone, it must always have a maximum tunnel inspection
level of two levels because by definition the firewall is looking
at the second level of encapsulation.
The firewall doesn’t support a Tunnel Inspection policy rule
that matches traffic for a tunnel that terminates on the firewall;
the firewall discards packets that match the inner tunnel session.
For example, when an IPSec tunnel terminates on the firewall, don’t
create a Tunnel Inspection policy rule that matches the tunnel you
terminate. The firewall already inspects the inner tunnel traffic
so no Tunnel Inspection policy rule is needed.
Although tunnel content inspection works on shared gateways
and on virtual system-to-virtual system communications, you can’t
assign tunnel zones to shared gateways or virtual system-to-virtual
system communications; they are subject to the same Security policy
rules as the zones to which they belong.
Both the inner tunnel sessions and the outer tunnel sessions
count toward the maximum session capacity for the firewall model.
The following table indicates with a check mark which types of
policy you can apply to an outer tunnel session, an inner tunnel
session, and the inside, original session:
Policy Type | Outer Tunnel Session | Inner Tunnel Session | Inside, Original Session |
|---|---|---|---|
App-Override | 
VXLAN
Only | 
|
|
DoS Protection |
|
|
|
NAT |
|
|
|
Policy-Based Forwarding (PBF) and Symmetric
Return |
|
|
|
QoS |
|
|
|
Security (required) |
|
|
|
User-ID |
|
|
|
Zone Protection |
|
|
|
VXLAN is different than other protocols. The firewall can use
either of two different sets of session keys to create outer tunnel
sessions for VXLAN.
- VXLAN UDP Session—A six-tuple key (zone, source IP, destination IP, protocol, source port, and destination port) creates a VXLAN UDP Session.
- VNI Session—A five-tuple key that incorporates the tunnel ID (the VXLAN Network Identifier, or VNI) and uses zone, source IP, destination IP, protocol, and tunnel ID (VNI) to create a VNI Session.
You can View
Inspected Tunnel Activity on the ACC or View
Tunnel Information in Logs. To facilitate quick viewing,
configure a Monitor tag so you can monitor tunnel activity and filter
log results by that tag.
The ACC tunnel activity provides data in various views. For the
Tunnel ID Usage, Tunnel Monitor Tag, and Tunnel Application Usage,
the data for bytes, sessions, threats, content,
and URLs come from the Traffic Summary database.
For the Tunnel User, Tunneled Source IP and Tunneled Destination
IP Activity, data for bytes and sessions come
from Traffic Summary database, data for threats come
from the Threat Summary, data for URLs come
from the URL Summary, and data for contents come
from the Data database, which is a subset of the Threat logs.
If you enable NetFlow on the interface, NetFlow will capture
statistics for the outer tunnel only, to avoid double-counting (counting
bytes of both outer and inner flows).
For the Tunnel Inspection policy rule and tunnel zone capacities
for your firewall model, see the Product Selection tool.
The following figure illustrates a corporation that runs multiple
divisions and uses different Security policies and a Tunnel Inspection
policy. A Central IT team provides connectivity between regions.
A tunnel connects Site A to Site C; another tunnel connects Site
A to Site D. Central IT places a firewall in the path of each tunnel;
the firewall in the tunnel between Sites A and C performs tunnel
inspection; the firewall in the tunnel between Sites A and D has
no tunnel inspection policy because the traffic is very sensitive.
