Custom Snort 3 Intrusion Policies for Access Control

Multi-layer inspection

Updated: February 4, 2026

Want to summarize with AI?

Provides an overview of the multi-layer inspection feature in Snort 3

The multi-layer inspection feature in Snort 3 enables you to inspect traffic across multiple protocol layers within the same session.

Snort 3 can simultaneously inspect the following layers:

Network layer (L3): IP addresses, fragmentation
Transport layer (L4): TCP or UDP ports, flags, session tracking
Application layer (L7): HTTP, DNS, SMTP, TLS, SIP, and others.
File and payload layer: File extraction, malware signatures, embedded content

Snort 3 supports decoding for a wide range of protocols. It inspects encapsulated protocols and evaluates packet headers to determine policy actions during advanced threat inspection.

Header inspection

On versions earlier than 7.6.4

For encapsulation protocols not supported by Lina, the system initially matches traffic based on the outer IP header. The subsequent evaluation depends on the rule criteria:

Rules without Layer 7 (L7) criteria: If the matched rule does not include L7 criteria (such as URL, application ID, or user identity), the system applies the rule based on the outer IP header.
Rules with Layer 7 (L7) criteria: If the rule includes L7 criteria, the system uses the outer-IP header match as a starting point and then performs an additional evaluation using the innermost header.

This behavior can lead to unexpected results, such as a non-L7 rule matching the outer-IP header taking precedence over a rule matching the inner-IP header located lower in the rule set.

On version 7.6.4 and later

Snort 3 always inspects the innermost header for protocols not supported by Lina, regardless of the presence of Layer 7 rules.
Outer header-based rules alone are not sufficient for policy enforcement for protocols such as VXLAN. Snort 3 disregards connection details for action in such cases, using the actual packet content instead.
For protocols supported by Lina, policy action continues to be based on the innermost header.
If you currently manage encapsulated traffic for protocols not supported by Lina (such as VXLAN) using only outer-IP rules, be aware that on version 7.6.4 or later, this traffic will be handled by the default access control rule. In such a scenario, if your default policy action is set to Block, this may result in the traffic being dropped. We recommend that you review and update access control policies to match the inner IP header for such protocols, in addition to any existing outer IP header configurations.

Layer 7 features

For encapsulated traffic in Layer 7 features, only the innermost IP header must be matched in rules. Outer header-only rules will not apply.

Example scenarios

The following table lists examples based on different parameters.


Protocol	Version	Outer IP rule	Inner IP rule	L7 rule needed	Result
VXLAN (not supported by LINA)	7.6.2	Yes	No	No	Traffic allowed if outer header matches
VXLAN (not supported by LINA)	7.6.4	No	Yes	No	Traffic allowed if inner header matches
GRE (supported by LINA)	7.6.2 and 7.6.4	No	Yes	No	Traffic allowed if inner header matches
VXLAN + L7 feature	7.6.2 and 7.6.4	No	Yes	Yes	Inner header rule required

Note

An outer IP rule matches traffic based on the tunnel endpoints. It evaluates:

Source IP address of the encapsulating device

Destination IP address of the encapsulating device

An inner IP rule matches traffic based on the original IP packet inside the tunnel. It evaluates:

The real client IP address

The real destination server IP address

Encapsulation layer limits and inspection behavior

When managing encapsulated traffic, it is important to understand the processing limits of the system’s two primary inspection engines, Lina and Snort.

LINA: Supports decoding up to 2 layers of encapsulation.
Snort: Supports decoding up to 255 layers of encapsulation (with a default limit of 40).

Supported protocols and inspection capabilities of LINA and Snort 3

LINA

LINA supports decoding for the following protocols across the Data Link (L2), Network (L3), and Transport (L4) layers.


Layer	Supported protocols and headers
Layer 2	Cisco MetaData (CMD), IEEE 802.1Q, IEEE 802.1ad (DOT1AD), and Q-in-Q (EtherTypes 0x9100 and 0x9200). Supports up to three levels of VLAN headers.
Layer 3	IPv4, IPv6
Layer 4	ICMP (v4/v6), ESP, VXLAN, Geneve, GRE, IP-in-IP, and IPv6-in-IPv6. Supports up to 1 level of encapsulation.

For GRE traffic, the system supports decoding for the following protocol types:

Point-to-Point Tunneling Protocol (PPTP)
Web Cache Communication Protocol (WCCP)

The system decodes GRE and ERSPAN (types 1, 2, and 3). To facilitate dispatch layer load-balancing, the system internally skips to the inner headers. Consequently, other modules are unable to inspect ERSPAN headers.

Snort 3

While Snort 3 supports a vast array of protocols, the following list highlights common encapsulation and tunneling protocols supported for inspection:

VXLAN
GRE
Teredo
GTP
MPLS
Geneve
IP-in-IP
- IPv4-in-IPv4
- IPv6-in-IPv4
- IPv4-in-IPv6
- IPv6-in-IPv6

Note

This list is not exhaustive. Snort 3 is designed to decode a wide range of industry-standard protocols.

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.