Question 1

What ISE feature authenticates non-802.1X capable endpoints, and how do you prevent someone from spoofing a medical device MAC address?

Accepted Answer

The feature is **MAB (MAC Authentication Bypass)**. When ISE detects that a device does not respond to 802.1X EAPOL requests, it falls back to MAB after the authentication timer expires (typically 60-90 seconds). ISE sends the device MAC address to the internal database or an external LDAP/AD server for validation. To prevent MAC spoofing, I implement three controls: (1) **Profiling** — ISE uses the Cisco Feed Service and DHCP/HTTP/CDP attributes to build an endpoint profile. A spoofed MAC from a laptop will not match the Medical-Device profile because the DHCP fingerprint and OUI will differ. (2) **Static MAC bypass with port security** — I configure switchport port-security mac-address sticky on the switch so only the first learned MAC is allowed, and I bind that MAC to a specific interface in ISE. (3) **CoA (Change of Authorization)** — if ISE detects the same MAC appearing on two different switches simultaneously, it sends a CoA to bounce the port and alert the SOC. For critical devices, I also use **SGT (Scalable Group Tags)** to assign a Medical-Device tag that restricts lateral movement even if authentication is bypassed.

Question 2

What FTD-specific behavior differs from ASA regarding DNS resolution for VPN clients, and what is the fix?

Accepted Answer

On ASA, split-tunnel DNS was handled implicitly by the tunnel-group attributes and the ASA itself could proxy DNS queries. On FTD, **split DNS** must be explicitly configured in the Remote Access VPN policy under Advanced > Split Tunneling > DNS. FTD does not automatically forward DNS queries from VPN clients to internal DNS servers unless the Include in Tunnel domain list is populated with the internal domains (e.g., corp.nhprep.com). The fix is to add the internal domains to the DNS Split Tunnel list in the RA VPN configuration and ensure the AnyConnect profile XML includes LocalLanAccess true and SplitDNS entries. I also verify that the FTD has a DNS policy allowing UDP 53 from the VPN pool to the internal DNS servers, and that the Identity NAT or No-NAT rule is in place so DNS traffic is not translated. A common gotcha: FTD uses Snort-based inspection on DNS by default, and if the DNS response is fragmented or uses EDNS0, Snort may drop it. I disable DNS inspection for the VPN zone pair as a test.

Question 3

What is the most likely cause, and which ASA timer or feature is responsible?

Accepted Answer

This is a classic IKE rekey timer alignment issue. Both ASAs have their Phase 1 (IKE) and Phase 2 (IPsec) lifetimes set to the same value (e.g., 86400 seconds / 24 hours). When both sides rekey simultaneously, there is a brief window where neither side has a valid SA, causing a 30-90 second drop. The fix is to **stagger the lifetimes**: set IKEv2 lifetime to 24 hours (86400) and IPsec lifetime to 8 hours (28800), or use randomized jitter if the ASA firmware supports it. I also verify that DPD (Dead Peer Detection) is enabled with dpd 10 retry 3 so the ASA detects the peer is alive faster during rekey. Another possibility is a scheduled backup or snapshot on one ASA that causes a brief CPU spike at 2 AM, delaying IKE processing. I check show cpu usage history and show crypto isakmp sa timestamps. A third cause is CRL/OCSP certificate validation happening at 2 AM if the CA server is unreachable, causing the ASA to tear down the tunnel until the certificate is revalidated. I disable OCSP if the CA is unreliable, or I cache CRLs locally.

Question 4

What three ISE policy elements control guest post-authentication access, and what is the most common misconfiguration?

Accepted Answer

The three elements are: (1) Authorization Profile — determines the SGT, VLAN, and ACL assigned after authentication. Guests typically get Guest-Internet-Only profile with a VLAN like 50 and a dACL that permits only TCP 80/443 to 0.0.0.0/0 and denies RFC 1918. (2) Downloadable ACL (dACL) — pushed from ISE to the WLC or switch. If the dACL is missing a permit for DNS (UDP 53), guests cannot resolve hostnames and appear to have no internet. (3) SGT/SGACL — if the guest SGT is Guest and the SGACL on the firewall only permits Employee SGT to internet, guest traffic is dropped at the firewall. The most common misconfiguration is missing DNS in the dACL. Corporate users often use internal DNS servers that are reachable via the corporate VLAN, but guests on a separate VLAN need public DNS (8.8.8.8) permitted explicitly. I verify with show ip access-list on the switch/WLC and check ISE Live Logs for the authorization result. I also check that the Guest portal is configured to redirect to the correct Redirect ACL on the WLC, and that the Post-Auth URL sends guests to a terms-of-use page before full access is granted.

Question 5

What FTD clustering mode achieves sub-3-second failover, and what network design change is required?

Accepted Answer

Active/standby failover takes 5-10 seconds because the standby must detect the failure, assume the active role, and send gratuitous ARPs to update the switch MAC table. To achieve sub-3-second failover, I migrate to FTD clustered mode (multi-instance) with stateful failover and Layer 2 port-channel redundancy. In clustered mode, multiple FTD units act as a single logical device with intra-cluster communication syncing connection states in real time. When one unit fails, the others already have the connection table and take over immediately. For network design, I configure the FTD cluster as a vPC (Virtual PortChannel) on Nexus switches or a multi-chassis LAG (MLAG) on Catalyst switches so that links to both cluster members are active simultaneously. I also enable BFD on all routed neighbors so failure detection is sub-second. On the FTD side, I tune the failover poll time to 1 second and hold time to 3 seconds. For even faster convergence, I use ECMP routing to both FTD cluster members so that if one member fails, the router simply stops sending new flows to it. The key interview phrase: Active/standby is for budget; clustered ECMP is for business continuity.

Question 6

What is the fastest way to restore service while maintaining IPS coverage, and what is the long-term tuning strategy?

Accepted Answer

The fastest way is to identify the specific IPS signature blocking the traffic and set it to Alert Only for the affected host or network. In FMC, I go to Analysis > Intrusions > Events, filter by the source/destination IPs, and note the Signature ID. I then create an IPS Override in the access control policy: set the signature to Produce Alert instead of Drop and Generate Events for the Cloud-Storage application or the specific destination IP range. This restores service in under 2 minutes. For long-term tuning, I create a custom IPS policy based on the Connectivity over Security preset for the file server VLAN, and use the Balanced preset for all other VLANs. I also add the cloud storage provider IP ranges to a trusted network object and exclude it from aggressive file-transfer signatures. Additionally, I enable File Policies separately from IPS so that file type inspection (blocking .exe, .dll) still occurs without Snort packet inspection interfering with bulk transfers. I verify with show ips stats on FTD CLI and review the Connection Events in FMC for Intrusion Policy: Drop actions.

Question 7

What Cisco solution replaces DMVPN with per-session identity verification, and what are the two biggest migration challenges?

Accepted Answer

The replacement is Cisco SD-Access with SDA (Software-Defined Access) or Cisco Secure Access by Duo (Zero Trust Network Access). For a router-based WAN, the most direct replacement is Cisco Secure Network Analytics (Stealthwatch) + ISE for microsegmentation, or migrating the WAN to Cisco SD-WAN with ISE SGT enforcement at every branch. In this model, no branch-to-HQ traffic is implicitly trusted. Every session is authenticated via 802.1X or MAB, assigned an SGT, and the SGACL on the branch router or SD-WAN vEdge enforces what the endpoint can reach. The two biggest migration challenges are: (1) Identity integration — every device and user must be in ISE/AD with a valid certificate or credentials. IoT devices that worked anonymously over DMVPN now need MAB profiling and exception policies. (2) Performance impact — SGT propagation via SXP or inline tagging adds CPU overhead. On ISR 4K routers, this is minimal, but on older ISR G2 or ASR 1K without TrustSec hardware acceleration, throughput may drop 10-15%. I mitigate this by deploying Catalyst 9000 switches at branches to handle SGT tagging at Layer 2, leaving the router to focus on routing. For the interview, I also mention Cisco Zero Trust Architecture which combines ISE, Duo, SD-WAN, and Umbrella into a unified policy fabric.

Question 8

What ASA NAT behavior causes this, and how do you write the NAT rule to allow both inbound and outbound?

Accepted Answer

The issue is likely a static NAT (object NAT) that only handles inbound traffic, or a missing twice-NAT / manual NAT rule for outbound. If the ASA has object network WEB-SERVER nat (inside,outside) static 203.0.113.10, inbound traffic to 203.0.113.10 is translated to the internal IP. However, when the web server initiates outbound traffic, the ASA sees the source as the internal IP and may apply dynamic PAT or no NAT at all, depending on the NAT rule order. ASA processes NAT in section order: Section 1 (manual NAT), Section 2 (auto NAT), Section 3 (after-auto manual NAT). If a dynamic PAT rule exists in Section 2, it may not apply because the static NAT in Section 2 takes precedence for that object. The fix is to use twice NAT (manual NAT) in Section 1: nat (inside,outside) source static WEB-SERVER 203.0.113.10 destination static ANY ANY — this ensures both directions use the same translation. Alternatively, I add a separate dynamic PAT rule for the web server internal IP in Section 3. But the cleanest solution is one manual NAT rule with both source and destination specified so the ASA maintains the same xlate for both directions. I verify with show nat detail and show xlate.

Question 9

What are the three most likely certificate-related causes, and how do you verify each in ISE and Active Directory?

Accepted Answer

First, expired or revoked machine certificates. The Windows update may have triggered a certificate renewal that failed, or the CA issued a new CRL that revoked old certs. I verify in ISE under Operations > Authentications > Failed, filter by Failure Reason: 12514 Certificate Validation Failed, and check the certificate expiry date in the details. In AD, I run certutil to find expired certs. Second, missing Intermediate CA certificate on ISE. If the machine cert was issued by a sub-CA and ISE only trusts the root CA, validation fails. I check Administration > System > Certificates > Trusted Certificates in ISE and ensure the full chain is present. Third, SCEP/NDES profile misconfiguration. If the Windows update changed the certificate template or CSP (Cryptographic Service Provider), the machine may have a cert with an unsupported key algorithm (e.g., RSA-PSS instead of RSA-PKCS1). ISE 3.1+ supports RSA-PSS, but older versions do not. I verify the certificate signature algorithm with openssl x509. The fix is to update the AD Certificate Template to use a compatible algorithm, or upgrade ISE. I also check that the certificate subject matches the machine name in AD — a name mismatch causes EAP-TLS failure.

Question 10

What is the fastest remediation path, and how do you prevent false positives from impacting business-critical apps?

Accepted Answer

The fastest remediation is a URL override in FMC. I navigate to Policies > Access Control > URL, find the blocked URL or domain, and create an override that recategorizes it as Business and Economy or adds it to a custom Allow-List category. This takes effect immediately without waiting for Cisco Talos to update the global database. For prevention, I create a custom URL category called Business-Critical-SaaS and populate it with all approved SaaS domains during onboarding. In the access control policy, I place an allow rule for Business-Critical-SaaS above the URL filtering rule so these apps are never subject to category-based blocking. I also implement application-based rules instead of URL-based rules where possible — FTD App-ID can identify Microsoft 365, Salesforce, and Zoom by signature rather than URL category, reducing false positives. For apps that use CDN domains (e.g., cdn.salesforce.com), I add wildcard entries to the custom category. I verify with show url-filter statistics and check the URL Filtering Events in FMC to confirm the override is hitting. I also open a Talos reputation case for persistent miscategorizations.

Question 11

What is the safest phased deployment strategy for 802.1X on a large switch fleet, and what monitoring ensures no outages?

Accepted Answer

A big bang 802.1X deployment causes outages because unknown devices (printers, IP phones, IoT) get blocked. The safest strategy is Monitor Mode -> Low Impact -> Closed Mode over three phases. Phase 1 (Days 1-10): Deploy 802.1X in Monitor Mode — authentication open allows all traffic but logs authentication attempts to ISE. I run reports in ISE to identify which MAC addresses are not in the database and build an exception list. Phase 2 (Days 11-20): Low Impact Mode — authentication port-control auto with authentication order dot1x mab and a Low Impact ACL that permits limited traffic (DHCP, DNS, TFTP) for unauthenticated hosts while denying access to corporate resources. This gives users a grace period to enroll devices. Phase 3 (Days 21-30): Closed Mode — remove authentication open so only authenticated/authorized devices pass traffic. For monitoring, I use ISE pxGrid to stream authentication events to Splunk and create a dashboard showing: ports in Auth Success, Auth Fail, MAB Bypass, and Unknown states. I also configure SNMP traps on switches to alert the NOC when a port enters err-disabled due to security violations. For critical infrastructure (datacenter uplinks, management ports), I exempt them from 802.1X using authentication port-control force-authorized and document them in the audit report.

Question 12

What ASA command reveals the exact ACL, NAT, and routing decision for a specific flow, and how do you use it?

Accepted Answer

The command is packet-tracer. It simulates a packet through the ASA and reports every decision: input interface, ACL match, NAT translation, route lookup, VPN decryption, and output interface. I run: packet-tracer input outside tcp 10.10.10.10 12345 192.168.1.10 80 detailed. The output shows: (1) Phase: 1 — Ingress interface and ACL check. If the new ACL blocks the VPN pool IP, this phase shows DROP. (2) Phase: 2 — NAT lookup. If the VPN traffic should be exempt from NAT, I verify the exemption is still in place. (3) Phase: 3 — Route lookup. If the new ACL changed routing or if a route-lookup rule is missing, the ASA may try to route the decrypted packet back out the outside interface. (4) Phase: 7 — VPN decrypt/encrypt. I check that the VPN filter ACL (group-policy attributes > vpn-filter) is not blocking the flow. The most common cause is that the new ACL was added with a higher priority (lower number) than the VPN permit rule, or the NAT exemption was accidentally removed during the ACL edit. I also use show asp table classify to see the accelerated security path classification for existing flows.

Question 13

What DNS architecture fixes this caching issue, and how does Umbrella intelligent proxy handle HTTPS threats that bypass DNS?

Accepted Answer

The fix is to eliminate local DNS caching and point all branch DNS queries directly to Umbrella anycast resolvers (208.67.222.222 / 208.67.220.220) using DNS forwarding on the branch router or Umbrella Virtual Appliance (VA) deployed locally. The VA acts as a caching resolver that syncs policy changes from Umbrella every 5 minutes, so blocked domains are refreshed faster than a generic BIND/Unbound cache. I also reduce the TTL on the local DNS server to 300 seconds for external domains. For HTTPS threats that bypass DNS (e.g., hardcoded IPs, DoH/DoT), Umbrella uses the Intelligent Proxy. When a user browses to an uncategorized HTTPS site, Umbrella returns the IP of the intelligent proxy instead of the real site. The proxy terminates TLS, inspects the SNI/Host header, and blocks malicious content. For privacy-sensitive enterprises, I deploy the Umbrella Roaming Client or Cisco Secure Client with web security module, which enforces policy at the endpoint regardless of DNS configuration. I also block DNS over HTTPS (DoH) at the firewall by dropping outbound HTTPS to known DoH providers (Cloudflare 1.1.1.1, Google 8.8.8.8) unless they are explicitly allowed.

Question 14

If the firewall rule was correct, what two other security controls failed, and how does microsegmentation prevent this?

Accepted Answer

The firewall rule may have been correct for the primary path, but lateral movement often bypasses perimeter firewalls through: (1) Direct L2 adjacency — if both the workstation and database are on the same VLAN or if VLAN hopping (802.1Q double-tagging) was used, the traffic never reaches the Layer 3 firewall. (2) Compromised admin credentials — the attacker used RDP with stolen domain admin credentials, and the firewall allowed RDP from the Admin-Jump-Box subnet. The workstation was able to reach the jump box, then pivot. The failed controls are VLAN segmentation and privilege-based access control. Microsegmentation using Cisco ISE SGTs prevents this by assigning each endpoint a security tag based on identity and posture. The database server only accepts RDP from endpoints with the Database-Admin SGT. Even if the workstation is on the same VLAN, the SGACL on the switch drops the RDP packet because the source SGT is Employee and the destination SGT is Database-Server with no permit rule for TCP 3389. For east-west traffic between servers, I deploy Cisco Secure Workload (Tetration) or VMware NSX to enforce microsegmentation at the hypervisor level. I also implement Just-in-Time (JIT) access via Cisco Duo or Azure PIM so RDP ports are only open for approved sessions and auto-close after the session ends.

Question 15

What three automated responses form the 10-minute containment playbook, and what triggers each?

Accepted Answer

Trigger: ISE pxGrid detects an endpoint with anomalous behavior (e.g., failed auth attempts > 10/min, posture change to non-compliant, or Stealthwatch flags C2 beaconing). Minute 0-2: Auto-Quarantine. The SIEM (Splunk/Sentinel) invokes the ISE REST API to send a CoA (Change of Authorization) to the switch/WLC, moving the endpoint to a Quarantine VLAN with no access to corporate resources but allowing remediation portal access. Minute 2-5: Containment Verification. An Ansible playbook runs to: (a) add the endpoint IP to a deny list in the FTD Quarantine-ACL, (b) disable the AD account via PowerShell, (c) revoke AnyConnect VPN sessions. Minute 5-10: Forensic Preservation. The playbook triggers an EDR snapshot (Cisco Secure Endpoint) to capture memory dump and file hashes, opens a ServiceNow ticket with all indicators, and schedules a re-image if the device is non-compliant. For critical assets, I also implement SGT blackholing: the endpoint SGT is changed to Compromised and all SGACLs automatically drop traffic to/from that tag. I verify containment with show mac address-table (quarantine VLAN), show access-list (FTD deny hits), and ISE Live Logs (CoA success).