How the system processes plain-text tunnels

Some protocols, such as GRE, create plain-text (not encrypted) tunnels that contain (or encapsulate) multiple inner connections. These connections might flow between discontinuous networks. These tunnels are especially useful for routing custom protocols over IP networks, IPv6 traffic over IPv4 networks, and so on.

Thus, a plain-text tunnel has two sets of IP headers:

• Outer header—An outer encapsulation header specifies the source and destination IP addresses of the tunnel endpoints—the routed interfaces of the network devices on either side of the tunnel.

  The prefilter policy uses outer headers to handle traffic. You can block or fast path entire plaintext, passthrough tunnels at this stage.

• Inner headers—Inner payload headers specify the source and destination IP addresses of the encapsulated connections' actual endpoints. There are separate headers for each connection contained within the tunnel.

  Any tunnels that you analyze (that is, not block or fast path) have these inner headers exposed for use by the rest of the security policies and other features such as QoS. These features use the innermost detectable level of headers to ensure the most granular level of inspection and handling possible. This ensures that bad actors cannot hide illegitimate traffic within a plain-text tunnel.

For regular, non-tunneled connections, there is only the “outer” header, as the connection does not contain any subordinate connections.

If you do not want to allow plain-text tunnels at all, you can set the default action in the prefilter policy to block all plain-text tunnels. This block does not apply to encrypted tunnels such as VPN.

Alternatively, you can use tunnel zones to re-tag tunneled traffic so that you can write access control rules specifically for select tunnels. This lets you customize intrusion inspection or other layer 7 filtering to connections contained with a tunnel. See Using tunnel zones to apply access control at the tunnel level.