Cisco Secure Firewall with ISE and SGT Integration

Introduction

Imagine a network where access control decisions are no longer tied solely to IP addresses and port numbers, but instead follow the identity and role of every user and device. That is precisely what Security Group Tag (SGT) integration between Cisco Secure Firewall and Cisco Identity Services Engine (ISE) delivers. The Cisco Secure Firewall stands as one of the most critical security controls in the modern enterprise network, and when paired with ISE and SGTs, it enables a powerful identity-based segmentation model that adapts dynamically to your environment.

Managing and troubleshooting the integration between these platforms is essential for maintaining a stable and efficient network. Whether you are preparing for a CCNP Security certification or managing production firewall deployments, understanding how SGT metadata flows through the Cisco Secure Firewall packet processing pipeline will make you a more effective security engineer.

In this article, we will explore how the Cisco Secure Firewall processes packets through its dual-engine architecture, how ISE SGT data is consumed during access control rule evaluation, the troubleshooting tools available for verifying SGT-based policy decisions, the hardware platforms that support these features, and the best practices for optimizing your deployment. Every technical detail in this article is grounded in real-world TAC-level troubleshooting methodology and production deployment experience.

How Does the Cisco Secure Firewall Process Packets?

Before diving into ISE and SGT integration specifics, it is essential to understand the fundamental packet processing architecture of the Cisco Secure Firewall running Firepower Threat Defense (FTD). The firewall operates with two primary processing engines that work in tandem.

The Dual-Engine Architecture

The FTD packet processing pipeline consists of two engines:

LINA Engine (Data Plane) -- The packet enters the ingress interface and is initially handled by the LINA engine. This engine is responsible for connection lookups, NAT processing, ACL evaluation, routing, ARP resolution, and packet forwarding.
Snort Engine (Inspection Engine) -- If the policy dictates inspection, the packet is sent to the Snort engine for deep packet inspection, application identification, intrusion detection, file analysis, and access control rule matching.

The processing flow works as follows:

Packet enters the ingress interface, and it is handled by the LINA engine
If the policy dictates so, the packet is inspected by the Snort Engine
Snort Engine returns a verdict for the packet
LINA Engine drops or forwards the packets based on Snort's verdict

When a packet arrives on the ingress interface, input counters are incremented by the NIC and periodically retrieved by the CPU. The input queue (RX ring) serves as an indicator of packet load, and the overrun counter indicates packet drops, which usually result from packet bursts.

You can verify interface statistics with the following command:

> show interface g1/2 detail
Interface GigabitEthernet1/2 "inside", is up, line protocol is up
  Hardware is Accelerator rev01, BW 1000 Mbps, DLY 10 usec
  IPS Interface-Mode: inline-tap, Inline-Set: Set1
  47770671 packets input, 7620806887 bytes, 0 no buffer
  Received 23734506 broadcasts, 0 runts, 0 giants
  0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
  input queue (blocks free curr/low): hardware (1008/800)

Connection Lookup and Fast Path

The LINA engine checks for existing connections in the connection table. If a match is found, the packet uses the Fast Path, bypassing basic checks:

firepower# show capture CAPO packet-number 2 trace
2 packets captured
2: 12:51:51.094691 192.168.76.14 > 192.168.75.14: icmp: echo reply
...
Phase: 3
Type: FLOW-LOOKUP
Result: ALLOW
Config:
Additional Information:
  Found flow with id 1541, using existing flow

If no existing connection is found, the behavior depends on the packet type. For a TCP SYN or UDP packet, the packet passes to ACL and other policy checks in the Session Manager. For a TCP non-SYN packet, the firewall drops and logs the event.

What Role Does ISE SGT Play in Cisco Secure Firewall Policy Evaluation?

Security Group Tags (SGTs) are numeric identifiers assigned by Cisco ISE to classify users, devices, and endpoints based on their identity and posture. When integrated with the Cisco Secure Firewall, these tags become available as matching criteria within access control rules, enabling identity-based policy enforcement directly in the firewall's inspection pipeline.

How SGT Data Appears in the Packet Processing Pipeline

When the Snort engine evaluates a flow against the Access Control Policy, it considers multiple attributes including zones, geo-location, VLAN, SGT tags, ISE SGT IDs, services, payload, client, user identity, and more. This is clearly visible in the firewall engine debug output:

> system support firewall-engine-debug
192.168.62.3-54650 > 10.123.175.22-22 6 AS 1 I 0 New session
192.168.62.3-54650 > 10.123.175.22-22 6 AS 1 I 0 Starting with minimum 4,
  'inspect', and IPProto first with zones 1 -> 2, geo 0 -> 0, vlan0,
  inline sgttag: untagged, ISE sgtid: 0, svc 0, payload 0, client 0,
  misc 0, user 9999997, icmpType 0, icmpCode 0

Notice the two critical SGT-related fields in this debug output:

inline sgttag -- The SGT tag carried inline within the packet header (using Cisco Meta Data or CMD). When no inline tag is present, this shows as "untagged."
ISE sgtid -- The SGT ID obtained from ISE via the pxGrid or SXP integration. When no ISE mapping exists for the source, this shows as "0."

These fields are evaluated during access control rule matching. The Snort engine uses them alongside other criteria such as source and destination zones, network objects, application identification, and user identity to determine which rule applies to a given flow.

SGT in the System Support Trace Output

The system support trace command provides another view into how SGT data is consumed during policy evaluation:

> system support trace
192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 Starting with minimum 2,
  'Rule1', and SrcZone first with zones -1 -> -1, geo 0(0) -> 0, vlan0,
  inline sgttag: untagged, ISE sgtid: 0, svc 676, payload 0, client 686,
  misc0, user 9999997, url http://192.168.2.40/128k.html, xff
192.168.1.40-32791 > 192.168.2.40-80 6 Firewall: starting rule matching,
  zone -1 -> -1, geo 0(0) -> 0, vlan0, sgt 65535, user 9999997,
  url http://192.168.2.40/128k.html
192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 match rule order 2,
  'Rule1', action Block
192.168.1.40-32791 > 192.168.2.40-80 6 AS 1 I 0 deny action

In this trace, you can see the SGT value being carried through the rule matching process. The sgt 65535 value indicates an untagged or unknown SGT. When ISE integration is properly configured and the source endpoint has an SGT assignment, these fields will reflect the actual tag value, enabling the firewall to match SGT-based access control rules.

Pro Tip: When troubleshooting ISE SGT integration issues, always enable system support firewall-engine-debug to verify whether the firewall is receiving the correct SGT values. If ISE sgtid consistently shows 0 for endpoints that should have SGT assignments, investigate the pxGrid or SXP connectivity between the firewall management center and ISE.

Understanding the Cisco Secure Firewall Access Control Policy with SGTs

The Access Control Policy (ACP) is the central policy construct on the Cisco Secure Firewall. It is configured on the Firewall Management Center (FMC) and pushed as a global ACL (CSM_FW_ACL_) to the LINA engine and as AC rules in the Snort engine.

How Access Control Rules Are Deployed

The ACP supports multiple actions, and the way rules are deployed depends on the conditions used:

Action	LINA Deployment	Snort Deployment
Allow	Permit (sends to Snort)	Allow rule in ngfw.rules
Trust (L4 only)	Trust (bypasses Snort)	Not deployed to Snort
Trust (with App/SI/SSL)	Permit (sends to Snort)	Fastpath in ngfw.rules
Block (L4 only)	Deny	Deny rule in ngfw.rules
Block (with Application)	Permit (sends to Snort)	Deny rule in ngfw.rules
Monitor	Permit (sends to Snort)	Monitor rule

When SGTs are used as a condition in access control rules, the rule must be evaluated by the Snort engine because SGT information is resolved at the application layer. This means SGT-based rules will always require Snort inspection, similar to how application-based rules operate.

You can verify how rules are deployed to the LINA engine:

firepower# show access-list
access-list CSM_FW_ACL_ line 20 remark rule-id 268435460: L7 RULE: ACP_Rule5_Block_Telnet_App
access-list CSM_FW_ACL_ line 21 advanced permit ip host 5.5.5.5 host 6.6.6.6 rule-id 268435460
access-list CSM_FW_ACL_ line 23 remark rule-id 268435464: L4 RULE: ACP_Rule6_Block_Telnet_Port
access-list CSM_FW_ACL_ line 24 advanced deny tcp host 6.6.6.6 host 7.7.7.7 eq telnet rule-id 268435464

Notice the distinction between L7 RULES and L4 RULES. When an access control rule uses SGT as a matching criterion, it is classified as an L7 rule (similar to application-based rules). The LINA engine permits the traffic to reach the Snort engine, where the actual SGT-based matching occurs.

The Prefilter Policy and Its Relationship to SGT Rules

The Prefilter Policy provides Early Access Control (EAC) rules with three possible actions:

Block -- Drops the traffic immediately
Fastpath -- Allows the traffic and bypasses the Snort Engine entirely
Analyze -- Sends the traffic to the Snort Engine for inspection

Prefilter rules are deployed to LINA as L3/L4 ACEs and are placed above the normal L3/L4 ACEs:

firepower# show access-list
access-list CSM_FW_ACL_ line 1 remark rule-id 268434457: PREFILTER POLICY: FTD_Prefilter_Policy
access-list CSM_FW_ACL_ line 2 remark rule-id 268434457: RULE: Fastpath_Rule1
access-list CSM_FW_ACL_ line 3 advanced trust ip host 192.168.75.16 any rule-id 268434457 event-log both (hitcnt=0)

Pro Tip: If you fastpath traffic using the prefilter policy, that traffic will never be evaluated against SGT-based access control rules because it bypasses the Snort engine entirely. Ensure that any traffic requiring SGT-based policy enforcement is not matched by prefilter fastpath rules.

How Does the Cisco Secure Firewall Identity Policy Work with ISE?

The Identity Policy enables user-based authentication on the Cisco Secure Firewall. User information can be obtained through two primary methods:

Passive Authentication

Passive authentication collects user identity without requiring the user to actively authenticate to the firewall. The following sources are supported:

Remote access VPN logins -- User accounts defined in an external authentication server or local user accounts defined in the FDM
Cisco Identity Services Engine (ISE) -- ISE provides user-to-IP mappings via pxGrid
Cisco ISE Passive Identity Connector (ISE PIC) -- Extends passive identity capabilities

Active Authentication

Active authentication requires the user to authenticate directly. The firewall supports:

Captive Portal with Basic, NTLM, or Kerberos authentication methods

When ISE integration is configured, the firewall receives both user identity information and SGT assignments. This data enriches the L7 ACL evaluation, enabling rules based on:

User-based criteria
Application filtering
SGT-based segmentation
SafeSearch enforcement
Intrusion Policy forwarding
File Policy forwarding

For a hands-on deep dive into ISE 802.1X configuration and integration with network security devices, explore the CCNP Security ISE 802.1X Lab course on NHPREP.

Cisco Secure Firewall Troubleshooting Tools for ISE SGT Integration

Effective troubleshooting is fundamental to any successful ISE SGT integration. The Cisco Secure Firewall provides a comprehensive suite of tools that can be used simultaneously to isolate issues.

Packet Tracer

The packet-tracer command simulates a packet through the firewall processing pipeline, showing every phase the packet encounters:

firepower# packet-tracer input outside tcp 10.1.1.1 5555 10.1.10.10 3389 detailed
Phase: 1
  Type: CAPTURE
  Subtype:
  Result: ALLOW
Phase: 2
  Type: ACCESS-LIST
  Subtype:
  Result: ALLOW
  Config: Implicit Rule
Phase: 3
  Type: UN-NAT
  Subtype: static
  Result: ALLOW
  Config:
    nat(outside,dmz) source dynamic any interface
      destination static interface Win7-vm service rdp-outside rdp-outside
...
Phase: 12
  Type: FLOW-CREATION
  Subtype:
  Result: ALLOW
  Config:
  Additional Information:
    New flow created with id 16538274, packet dispatched to next module
Result:
  input-interface: outside
  output-interface: dmz
  Action: allow

Starting with FMC version 7.1, packet tracer enhancements include tab support for running multiple packets, PCAP file input for replaying entire flow traces, REST API support, and detailed Snort 3 phases. In version 7.4.1, connection event data can be loaded directly into Packet Tracer from the Unified Event Viewer.

LINA Captures with Trace

Capture real traffic on ingress and egress interfaces, then trace individual packets through the processing pipeline:

firepower# capture IN interface inside trace trace-count 200 match tcp any any
firepower# show capture inside trace packet-number 4

You can also capture traffic post-decryption across a VPN tunnel:

firepower# capture OUT interface outside trace include-decrypted match tcp any any

For high-traffic environments, use headers-only captures with an increased buffer:

firepower# capture capin interface inside headers-only buffer 10000000

System Support Firewall-Engine-Debug

This is the most critical tool for verifying SGT-based rule evaluation. It shows exactly how the Snort engine evaluates each flow against the access control rules, including all SGT-related fields:

> system support firewall-engine-debug
192.168.75.14-36942 > 192.168.76.14-21 6 AS 1 I 0 New session
192.168.75.14-36942 > 192.168.76.14-21 6 AS 1 I 0 using HW or preset rule order 2,
  'Allow Rule1', action Allow and prefilter rule 0
192.168.75.14-36942 > 192.168.76.14-21 6 AS 1 I 0 allow action

When troubleshooting SGT issues specifically, look for the sgttag and ISE sgtid fields in the debug output. If these values do not match your expectations, the problem likely lies in the ISE-to-firewall communication path rather than in the firewall policy itself.

ASP Drop Counters

Monitor packets dropped by the Accelerated Security Path:

> show asp drop
Frame drop:
  Flow is denied by access rule (acl-drop)           25247101
  First TCP packet not SYN (tcp-not-syn)              36888
  No route to host (no-route)                         1009
  Reverse-path verify failed (rpf-violated)           15

Pro Tip: Always clear ASP drop counters before reproducing an issue, then check the counters again afterward. This ensures you are looking at drops related to your specific test rather than historical accumulation: clear asp drop.

Connection Table Analysis

Examine active connections and their flags to understand connection state:

firepower# show conn detail
TCP Inside: 192.168.45.130/39978 ISP1: 192.168.10.31/21,
  flags UxION1, idle 19s, uptime 24s, timeout 1h0m, bytes 728

The N flag indicates the connection is being inspected by Snort, which is required for SGT-based rule evaluation. The 1 suffix means preserve-connection is enabled.

Cisco Secure Firewall Security Intelligence and SGT Synergy

Security Intelligence (SI) provides an additional layer of protection that works alongside SGT-based access control. Understanding how these features interact is important for proper policy design.

IP-Based Security Intelligence

Security Intelligence can blocklist (drop) or do-not-blocklist (allow) IP addresses early in the packet processing lifetime within the Snort engine. The do-not-blocklist overwrites the blocklist. Lists can be populated manually by the FMC administrator or automatically by Intelligence Feeds from Talos or custom sources.

To verify if an IP is on a blocklist:

$ grep -Fr [IP_ADDRESS] /var/sf/iprep_download

DNS-Based Security Intelligence

DNS requests can receive one of the following actions:

Do Not Block
Monitor
Domain Not Found (NXDOMAIN)
Drop (drops the DNS query)
Sinkhole (redirection to a local honeypot IP)

URL-Based Security Intelligence

Works similarly to IP Security Intelligence with three actions: Do-Not-Blocklist, Blocklist, and Monitor. When Talos URL Feed is used, part of the database is stored locally and updated daily. For non-cached URLs, a cloud lookup is performed.

Security Intelligence evaluation happens before access control rule matching. This means that even if a flow has a valid SGT and would match an allow rule in the ACP, Security Intelligence can block it if the IP, DNS, or URL matches a blocklist entry. Keep this order of operations in mind when designing policies that combine SGTs with Security Intelligence.

What Cisco Secure Firewall Platforms Support ISE SGT Integration?

The Cisco Secure Firewall portfolio spans a wide range of hardware platforms, from branch-level appliances to carrier-class modular chassis. Understanding the platform capabilities is essential for planning ISE SGT deployments.

Hardware Platform Overview

Platform Series	NGFW Throughput (1024B)	Key Characteristics
1010/1010E	Up to 0.85 Gbps	Desktop form factor, 8x1G, 8GB RAM
1100 Series (1120/1140/1150)	2-5 Gbps	1RU, 8x1G copper + 4x SFP
1200 Compact (1210CE/CP, 1220CX)	6-9 Gbps	Desktop, ARM SoC, up to 300k sessions
1200 Series (1230/1240/1250)	9-18 Gbps	1RU, ARM SoC, up to 1M sessions
2100 Series (2110-2140)	2.5-10 Gbps	1RU, NPU-based
3100 Series (3105-3140)	17-45 Gbps	1RU, FPGA flow offload, clustering up to 16 nodes
4200 Series (4215/4225/4245)	65-145 Gbps	1RU, advanced FPGA, up to 16-node clustering
4100 Series (4112-4145)	19-53 Gbps	1RU, Smart NIC + crypto HW
9300 Series	Up to 64 Gbps per SM	3RU modular chassis, up to 3 security modules

Flow Offload Considerations for SGT-Based Policies

The Cisco Secure Firewall supports Flow Offload, which bypasses both the LINA and Snort engines completely. L2/L3 rewriting is handled by a special network adapter in the security engine blade. There are two types:

Static Flow Offload -- Connections that are fastpathed by the prefilter policy
Dynamic Flow Offload -- Inspected flows that the inspection engine decides no longer need inspection (supported by 3100/4100/9300 platforms)

You can view offloaded flows using:

> show flow-offload flow detail

Since offloaded flows bypass the Snort engine, they will not be evaluated against SGT-based access control rules. This is an important consideration when designing policies: if you need SGT enforcement on specific traffic, ensure that traffic is not being offloaded.

Firewall Management Center Appliance Scale

FMC Model	Max FTD Sensors	Max IPS Events	Max Network Hosts
FMCv2	2	10 million	5,000
FMC 1700	50	30 million	5,000
FMC 2700	300	60 million	12,000
FMC 4700	1,000	400 million	30,000

The FMC is where ISE integration is configured and where SGT-based access control rules are authored. Ensure your FMC model can handle the number of managed sensors and the event volume your deployment will generate.

Performance Optimization for Cisco Secure Firewall with SGT Policies

Running SGT-based policies adds inspection overhead because these rules require Snort engine evaluation. Optimizing your deployment for performance is critical.

Configurable CPU Core Allocation

Starting with FTD 7.3, administrators can change the allocation of CPU cores between the Data Plane (LINA) and the inspection engine (Snort). Several profiles are available:

Profile Name	Data Plane Cores	Snort Cores	Use Case
Default	Normal balanced allocation	Normal	Balanced FTD system
VPN heavy with prefilter	90%	10%	VPN headend with prefilter
VPN heavy	60%	40%	VPN-heavy deployment
IPS heavy	30%	70%	Heavy IPS and file inspection

For SGT-heavy deployments that rely extensively on Snort-level inspection, consider the IPS heavy profile to allocate more cores to the Snort engine. This is configured under Devices > Platform Settings > Performance Profile in FMC.

Access Control Rule Optimization

As your SGT-based policy grows, ACL expansion can consume significant memory. Two optimization features help:

Object Group Search (OGS) -- Available from FTD 6.6+, OGS installs a single rule instead of expanding Access Control Elements. Starting from FTD 7.2, OGS is enabled by default on greenfield deployments. The implementation was upgraded in 7.6 to handle more corner cases and provide hit counters on folded entries.
Interface Object Optimization (IOO) -- Available from FTD 6.7+, the object-group CLI is enhanced to support interface type, reducing rule expansion when multiple interfaces are used.

Elephant Flow Management

Large, long-lived flows (elephant flows) can overload a single Snort instance because a single stateful flow must be processed by one processor core at a time. The firewall provides detection and remediation:

Detection: Configurable thresholds for bytes and time duration, per-flow CPU utilization, and percentage of packets dropped by Snort
Remediation: Bypass inspection (set flag to bypass flow from Snort) or throttle flows (apply rate limit and continue inspecting)

> system support elephant-flow-detection enable
> show elephant-flow detection-config
bytes_threshold = 1024, time_threshold = 10
> show elephant-flow status
Elephant flow inspector is enabled

Pro Tip: Elephant flow detection is supported with Snort 3 only. Bypass and throttle remediation actions are not supported on Firepower 2100 series platforms.

Connection Logging Best Practices

Connection logging affects both CPU and memory. Follow these guidelines:

Access Control Rules with Allow and Trust actions should have logging enabled for the beginning or end of connection, not both
Logging at the end of the connection contains more data than logging at the beginning
Logging the beginning of an allowed or trusted connection is typically only used for troubleshooting purposes
Avoid double inspection (inspecting the same traffic twice)
Place block rules at the top of the access control policy for efficient ordering

Cisco Secure Firewall Clustering and High Availability with SGT Policies

For large-scale deployments requiring ISE SGT integration, clustering and high availability provide the necessary resilience and scale.

High Availability (Active/Standby)

FTD inherits failover infrastructure from ASA. It replicates full NGFW/NGIPS configuration and opaque flow state, supports all interface modes, and monitors both interface and Snort instance health (at least 50%). SGT-based policies are replicated along with the complete configuration.

Clustering (All Active)

Clustering provides true horizontal scaling. With every device added, you add capacity to handle traffic. Key characteristics:

Up to 16 nodes in a cluster
All packets for a flow are redirected to the connection Owner
Supports zero-downtime upgrades for most applications

Clustering throughput examples for 3140 FTD:

Cluster Size	NGFW Throughput	Max Connections	CPS
1 node	45 Gbps	10M	300k
4 nodes	144 Gbps	24M	600k
16 nodes	576 Gbps	96M	2.4M

Theoretical maximum throughput with 16-node clusters:

16x 3140: 0.57 Tbps
16x 4245: 1.79 Tbps

Multi-Instance for Multi-Tenancy

For environments requiring separate SGT policies per tenant, Multi-Instance capability allows multiple logical FTD instances on a single appliance. Each instance can have its own ISE integration, SGT policies, and management separation. Supported on 3100, 4100, 4200, and 9300 series with up to 34 instances on the 4245.

Isolating Cisco Secure Firewall Issues in ISE SGT Deployments

When troubleshooting connectivity issues in an ISE SGT deployment, follow a systematic approach to isolate whether the firewall is causing the problem.

Step-by-Step Isolation Methodology

Understand the topology and identify where SGT tagging occurs
Understand the packet flow through the firewall
Simultaneously collect the following at the time of the issue:
- Packet Tracer
- Captures: ASP drops, Capture with Trace
- System support trace (firewall engine debug)
- Connection events
- Syslogs

Bypassing Snort for Isolation

To determine if the issue is caused by Snort (and by extension, SGT-based rules):

Use prefilter policy with Fastpath action. If traffic is prefiltered and the issue persists, the problem is not related to the Snort side (and therefore not related to SGT evaluation).

TCP State Bypass

To bypass all security checks on LINA, use TCP state bypass. Connections using state bypass are not inspected by any inspection engines and bypass all TCP state checking and TCP normalization. This is configured under Policies > Access Control > Access Control > edit the access control policy > Advanced > Threat Defense Service Policy.

Syslog Configuration

Configure syslogs to record connections through the firewall:

firepower# show run logging
logging enable
logging trap informational
logging host outside 10.1.0.1

Connection events can also be sent as syslogs from the Snort engine, configured from the FTD Platform settings and the Access Control Policy logging tab.

Pro Tip: Troubleshooting files and show tech outputs must be collected before rebooting the device. Once you reboot, critical diagnostic data may be lost.

File Policy and Intrusion Policy Interaction with SGT-Based Rules

SGT-based access control rules can be enhanced with additional inspection policies that are tied to each rule.

File Policy

File Policy provides several functionalities within an access control rule:

Detect Files -- Checks the first 1460 bytes of a file, determines the type, and generates a log
Block Files -- Blocks the file based on the first 1460 bytes
Malware Cloud Lookup -- Sends the SHA-256 hash to the cloud for analysis
Block Malware -- Blocks files identified as malware by cloud analysis

If File Policy does not work properly, verify:

Malware license is installed on FMC and applied on the Secure Firewall
File Policy is attached to the Access Control Policy
File Policy has proper actions configured
Connectivity between FMC and cloud (US or Europe)
Files over approximately 100 MB or under approximately 6K will not be sent for dynamic analysis

Intrusion Policy

The intrusion policy before access control rule match can drop traffic before an AC rule is even matched. This is an important consideration for SGT deployments:

> system support firewall-engine-debug
192.168.62.3-54650 > 10.123.175.22-22 6 AS 1 I 0 Deleting session
  [!Session was deleted because we hit a drop IPS rule and blocklisted
  the flow. This happened before AC rule was matched (Intrusion policy
  before AC rule match dropped). Firewall engine will re-evaluate from
  top of AC policy to find a rule for logging decision]

In this scenario, an intrusion policy drops traffic before the SGT-based access control rule can be matched. The firewall then re-evaluates from the top of the AC policy to find a rule for logging purposes, which is why you might see a "Trust" rule matched in the connection event even though the traffic was actually blocked.

Frequently Asked Questions

What is the difference between inline sgttag and ISE sgtid in firewall-engine-debug?

The inline sgttag represents the SGT value carried within the Ethernet frame header using Cisco Meta Data (CMD). This is the tag embedded directly in the packet as it traverses the network. The ISE sgtid represents the SGT value obtained from ISE via pxGrid or SXP integration, where ISE provides IP-to-SGT mappings to the firewall management center. When both values are available, the firewall uses them during access control rule evaluation to match SGT-based policies.

Will SGT-based access control rules work with fastpathed or offloaded traffic?

No. SGT-based access control rules require evaluation by the Snort engine. Traffic that is fastpathed by the prefilter policy or offloaded via static or dynamic flow offload bypasses the Snort engine entirely. Therefore, these flows will never be evaluated against SGT-based rules. If you need SGT enforcement on specific traffic, ensure that traffic is not matched by prefilter fastpath rules and is not eligible for flow offload.

How can I verify that my Cisco Secure Firewall is receiving SGT information from ISE?

Use the system support firewall-engine-debug command and observe the ISE sgtid field in the debug output. If this field shows a non-zero value that matches the expected SGT assignment in ISE, the integration is working correctly. If it consistently shows 0, check the pxGrid or SXP connectivity between the FMC and ISE, verify that ISE is publishing SGT mappings, and ensure the FMC ISE integration configuration is correct.

Does clustering support SGT-based access control policies?

Yes. FTD clustering replicates the full NGFW/NGIPS configuration across all cluster members, including SGT-based access control rules. Each cluster member independently evaluates traffic against the same policy. Since all packets for a flow are redirected to the connection Owner node, SGT evaluation happens consistently on the Owner regardless of which node initially receives the packet.

What happens when an intrusion policy drops traffic before the SGT-based rule is matched?

When the intrusion policy applied before access control rule matching detects a threat and drops the flow, the session is deleted before the SGT-based AC rule can be evaluated. The firewall then re-evaluates from the top of the AC policy to find a matching rule for logging purposes only. This can result in connection events that show an unexpected rule match (such as a Trust rule) even though the traffic was actually blocked by the intrusion policy. This is normal behavior and should not be confused with a policy misconfiguration.

Which Cisco Secure Firewall platforms support the highest policy scale for SGT deployments?

The maximum supported policy sizes vary by platform. The 4245 supports up to 10,000,000 FTD ACEs, the 9300 with SM-56 supports up to 9,500,000 ACEs, and the 4225 supports up to 8,000,000 ACEs. For environments with large SGT-based policies, these higher-end platforms provide the necessary headroom. Object Group Search (OGS) should be enabled to reduce ACL expansion and support higher scale.

Conclusion

Integrating Cisco Secure Firewall with ISE and Security Group Tags transforms your network security posture from a static, address-based model to a dynamic, identity-driven architecture. Throughout this article, we have explored how the dual-engine packet processing architecture handles SGT data, how access control rules consume SGT information during Snort evaluation, and the comprehensive troubleshooting toolkit available for diagnosing integration issues.

The key takeaways are:

SGT evaluation happens in the Snort engine, so traffic must not be fastpathed or offloaded if SGT-based enforcement is required
firewall-engine-debug is your primary tool for verifying SGT values are being received and matched correctly
Access control rule design must account for the interaction between intrusion policies, file policies, Security Intelligence, and SGT-based rules
Platform selection should consider both throughput requirements and policy scale limits
Performance optimization through CPU core allocation, OGS, and proper connection logging practices ensures your SGT deployment scales effectively

For hands-on practice with ISE integration and identity-based access control, the CCNP Security ISE 802.1X Lab course on NHPREP provides practical lab exercises that reinforce these concepts with real configurations and troubleshooting scenarios. Building proficiency in these areas is essential for both certification success and production network management.