NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Objective

In this lesson you will learn how to validate and troubleshoot Security Intelligence (Talos URL feeds) and URL filtering behavior on an FTD-based firewall. We will enable engine-level debugging to observe URL/file lookup events, inspect connection table entries to see how HTTP/HTTPS flows are processed, and use ASP counters to find drops that can masquerade as URL-filtering failures. This matters in production because URL reputation and category lookups must be reliable (and have clear fallbacks) — for example, a corporate web filter denying malicious sites but allowing access if the filter is unreachable.

Quick Recap

Topology from Lesson 1 is reused here. No new devices are added.

ASCII Topology (interfaces show exact IPs):

         R1                      ASA/FTD                  WebSense
     Lo0 1.1.1.1               E0/1 (inside)               NIC
     F0/0 10.1.101.1  -------- 10.1.101.10  (inside)  ----- 10.1.103.100
                                | E0/2 (dmz)               
                                | 10.1.103.10 (dmz)
                                |
     R2                         | E0/0 (outside)
 Lo0 2.2.2.2                    | 10.1.102.10 (outside)
 G0/0 10.1.102.2 ---------------+

Device table / IP addressing:

Device	Interface	IP Address
R1	Lo0	1.1.1.1/24
R1	F0/0	10.1.101.1/24
R2	Lo0 / G0/0	2.2.2.2 / 10.1.102.2/24
ASA/FTD	E0/1 (inside)	10.1.101.10/24
ASA/FTD	E0/0 (outside)	10.1.102.10/24
ASA/FTD	E0/2 (dmz)	10.1.103.10/24
WebSense NIC		10.1.103.100/24

Key Concepts

Security Intelligence (URL feed): a feed (Talos or similar) provides reputational data for URLs. Part of the feed may be cached locally on the appliance and updated daily; for uncached entries the device performs a cloud lookup. In production, local cache reduces latency and cloud lookup preserves coverage for new URLs.
- Real behavior: cached = fast local decision; uncached = cloud lookup (adds latency, requires cloud connectivity).
URL filtering vs. File policy: URL filtering categorizes HTTP/HTTPS destinations and enforces allow/block rules. File policies inspect file contents (SHA256 hashes) and may involve cloud malware lookups. Both may generate debug/log entries that are visible at the firewall engine.
Packet/flow handling and connection state: FTD tracks TCP flows in a connection table. You can view flow state and flags (U = Up, I = Received Initiator data, O = Responder data, a/A = awaiting ACK). URL decisions are applied after flows are classified and inspected.
Accelerated Security Path (ASP) drops: If a packet is dropped in the fast path (ASP), access-control or URL-blocking may seem to "fail" but the root cause can be an ASP issue (routing, invalid headers, RPF). Use ASP counters to separate policy drops from transport/drops.
Analogy: Think of the URL feed like a librarian with a local card catalog (cache). If the book (URL) isn’t in the catalog, the librarian calls the central library (cloud lookup) — if that phone call fails, you need a fallback rule (e.g., allow).

Step-by-step configuration / verification

Note: this lesson focuses on validating Security Intelligence and URL-filtering behavior on the FTD/ASA platform and uses engine-level debugging and show commands to observe actions. Each step contains the exact commands you will run and the expected output to confirm behavior.

Step 1: Enable firewall engine debug to observe URL/File policy events

What we are doing: Enable the firewall engine debug stream to observe file and URL lookup events (File Policy and malware cloud lookups). This helps you see when a file is submitted to the cloud or when a URL lookup occurs — essential to validate Security Intelligence behavior and fallback logic.

system support firewall -engine-debug 10.1.1.2 -16969

What just happened: The command opens an engine-level debug log stream and binds it to the controller (10.1.1.2) on port 16969 so you receive detailed File/URL lookup messages from the engine. You will see lines identifying file hashes, disposal decisions (e.g., Block Malware), and URL lookup results (cache hit/miss, cloud lookup).

Real-world note: Use engine-level debug only in a lab or maintenance window — debug output is verbose and can impact performance in production.

Verify:

10.9.9.9 -80 6 AS 0 I 1 File malware event for 275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f named eicar.com with disposition Malware and action Block Malware

Expected output: a log line like the one above indicates that a file (SHA256) named eicar.com was classified and blocked by the File Policy. If you see similar messages for URL lookup events (e.g., URL reputation or category), your debug stream is capturing Security Intelligence activity.

Step 2: Inspect connection table to confirm HTTP/HTTPS flows are hitting inspection

What we are doing: Use connection table inspection to confirm that HTTP/HTTPS connections are being captured and forwarded to the inspection engine and to see initiator/responder pairs and connection flags. This tells us whether URL decisions will be applied to the flow.

terminal pager 24
show conn detail

What just happened: terminal pager 24 prevents output from over-running your terminal. show conn detail displays active connections, uptime, timeouts, bytes exchanged, and flags that indicate TCP state (U = Up, I = Initiator data, O = Responder data, a/A = awaiting ACKs). For a web flow you should see the inside host as the Initiator and the remote web server as the Responder. The connection entry shows whether inspection modules are in effect.

Verify:

show conn detail
2 in use, 7 most used Inspect Snort: preserve -connection: 1 enabled, 0 in effect, 6 most enabled, 0 most in effect
Flags: A -awaiting responder ACK to SYN, a -awaiting initiator ACK to SYN, B -TCP probe for server certificate, .. 
TCP Inside: 192.168.45.130 /39978 ISP1: 192.168.10.31/21, flags UxION1, idle 19s, uptime 24s , timeout 1h0m , bytes 728, xlateid 0x150406257f80
Initiator: 192.168.45.130, Responder: 192.168.10.31
Connection lookup keyid: 34422758N

Expected output: a connection entry showing the initiator/responder addresses and flags. The presence of inspection flags (e.g., N for inspected by Snort) or similar indicates the flow is sent for inspection; otherwise URL policies may not be evaluated.

Real-world note: When enabling a new URL policy, verify active client flows appear here so you know the policy will be applied immediately or after new connections are created.

Step 3: Filter connection table for a specific IP to focus troubleshooting

What we are doing: Narrow diagnostics to a client IP to see all connections involving that host. This helps isolate behavior for a single user and confirm whether the URL request triggered a lookup or a block.

show conn address 10.1.1.20

What just happened: This command filters the connection table and shows only entries that include the specified IP address. Use it to determine whether the host 10.1.1.20 generated an HTTP/HTTPS flow that reached the firewall and whether the connection has the expected flags.

Verify:

show conn address 10.1.1.20
TCP Inside: 10.1.1.20 /50072 ISP1: 172.18.124.145/21, flags U, idle 12s, uptime 50s, timeout 1h0m, bytes 806
Initiator: 10.1.1.20, Responder: 172.18.124.145
Connection lookup keyid: 14704

Expected output: you will see the connection with initiator 10.1.1.20 and responder 172.18.124.145 and flags indicating connection progress. Correlate this with the engine debug output to find URL lookup events tied to this flow.

Step 4: Check ASP drop counters to rule out transport-level drops

What we are doing: Review ASP (Accelerated Security Path) drop counters to determine whether packets are being dropped for non-policy reasons — e.g., invalid encapsulation, no route, or RPF violations. If URL filtering appears to be not working, an ASP drop might be the true cause.

show asp drop

What just happened: show asp drop presents counters for packet/flow drops at the fast path. The output enumerates counters such as invalid encapsulation, no adjacency, no route, RPF violation, ACL drops, bad TCP checksum, and so on. High counts in certain bins indicate where to focus.

Verify:

show asp drop
Frame drop: Invalid encapsulation (invalid-encap) 10897
Invalid tcplength (invalid-tcp-hdr-length) 9382
Invalid udplength (invalid-udp-length) 10
No valid adjacency (no-adjacency) 5594
No route to host (no-route) 1009
Reverse-path verify failed (rpf-violated) 15
Flow is denied by access rule (acl-drop) 25247101
First TCP packet not SYN (tcp-not-syn) 36888
Bad TCP Checksum (bad-tcp-cksum) 893

Expected output: counters similar to those shown above. Note particularly acl-drop (packets denied by access rules) vs. other transport drops. If acl-drop is high for your client IP, the policy blocking may be coming from an access rule, not URL filtering.

Additional action (if counters need clearing):

clear asp drop

Clearing counters before a test run allows you to capture fresh increments tied to the test.

Real-world note: In a production troubleshooting window, clear counters before reproducing the issue to measure only the test traffic.

Step 5: Observe URL lookup/cache behavior and expected log pattern

What we are doing: Observe example URL lookup messages and understand the fields indicating cache hits/misses, DNS response, and reputation results. This helps determine whether the firewall used a local cache or a cloud lookup and what the reputation verdict was.

(system engine debug output observed from Step 1)

What just happened: Example log fields you will encounter include: InitiatorBytes, ResponderBytes, DNSResponseType, Sinkhole, URLCategory, and URLReputation. Typical lines may show "URLCategory : Unknown" and "URLReputation : Risk unknown" for uncached or new sites, and show cloud lookup attempts. A "Sinkhole" field may be used when the feed directs malicious sites to internal sinkholes.

Verify:

InitiatorBytes : 148, ResponderBytes : 78, DNSResponseType : No Error, Sinkhole: Unknown, URLCategory : Unknown, URLReputation : Risk unknown

Expected output: a debug line similar to above. If you see "URLCategory : " and "URLReputation : ", the feed returned a meaningful result. If a cloud lookup was needed, timestamps and additional log lines may indicate "cloud lookup" activity.

Real-world note: For environments using Talos URL feeds, expect periodic local DB updates (daily). Cloud lookups are expected for newly-seen URLs and require outbound cloud connectivity; plan fallback policies (e.g., allow on lookup failure) depending on business requirements.

Verification Checklist

Check 1: Engine debug is running and shows File/URL events — verify with the sample File malware event line from Step 1.
Check 2: The HTTP/HTTPS flow for the test client appears in show conn detail and show conn address <ip> with expected initiation flags.
Check 3: ASP counters do not show transport-level drops for the test client (use show asp drop and clear asp drop before repeating tests).
Check 4: URL lookup log lines show either a cached category/reputation or indicate a cloud lookup (look for URLCategory and URLReputation fields).

Common Mistakes

Symptom	Cause	Fix
URL lookups always show "URLCategory : Unknown"	Local feed cache empty or cloud lookups failing	Ensure Talos/local feed is populated and FMC/FDM has connectivity to cloud; check engine debug for cloud lookup attempts and network reachability
Client traffic not appearing in connection table	Traffic is not reaching firewall (wrong VLAN/interface) or NAT/ACL prevents connection	Verify interface IPs and VLAN placement; check access-lists and NAT configuration; use `show interface` to confirm IPs
URL blocking seems intermittent	Cloud lookup latency or temporary feed cache miss	Reproduce test and check engine debug for cache hit vs miss; ensure fallback policy (allow/deny on cloud failure) is configured as desired
Tests show drops but no policy logs	Packets dropped in ASP for transport reasons (no route, RPF)	Run `show asp drop` to find drop counters, correct routing or RPF configuration, clear counters and retest

Key Takeaways

Security Intelligence (Talos feed) uses a local cache for speed and cloud lookups for uncached URLs; you must verify both are functioning and plan fallback behavior.
Use engine-level debugging (system support firewall -engine-debug) to see file and URL lookup events — this log is indispensable for validating that URL filtering and file policies are triggering as expected.
The connection table (show conn detail / show conn address <ip>) shows whether flows are being inspected, and ASP counters (show asp drop) tell you whether transport-level issues are responsible for apparent policy failures.
In production, monitor feed sync status and cloud connectivity; treat URL reputation lookups as potentially latency-sensitive and design fallback rules accordingly.

Tip: Always run clear asp drop before a controlled reproduction of a problem so that ASP counters you observe afterward map directly to the test traffic.

This completes Lesson 6: Security Intelligence and URL Filtering — you should now be able to observe URL and file policy decisions, distinguish policy enforcement from transport problems, and interpret engine debug output related to URL category and reputation lookups.