> ## Content Index
> Fetch the complete content index at: https://www.pinglabz.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# FTD Access Control Policy in FDM: Rule Order and packet-tracer
- URL: https://www.pinglabz.com/ftd-access-control-policy-fdm-packet-tracer/
- Published: 2026-10-18T22:36:49.000Z
- Updated: 2026-10-18T22:36:49.000Z
- Description: Fix an FDM access rule blocked by rule order. Follow real FTD packet-tracer, system support trace and acl-drop evidence, then verify recovery.
- Author: Jaime
- Tags: Firewall, Security, Network Security, Troubleshooting, Cisco

![FTD access control fault diagram: Block-Lab-Subnet deployed above Allow-Web, so HTTP from 10.19.10.10 to 10.19.30.10 drops in LINA with acl-drop on rule 268435458](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-acp-topology.png)

HTTP worked. Then a new access rule went in, and the same client could no longer reach the same web server. The specific Allow-Web rule was still present in FDM.

This home lab reproduces that failure on FTDv 10.0.0 build 140 with local FDM. A broad subnet block placed above Allow-Web catches the connection first. Moving the existing allow back to the top and deploying restores HTTP, while a second TCP service stays blocked.

The useful part is proving where the decision happened. The working flow reaches Snort and produces pass verdicts. The faulted flow stops at LINA's access-list check. An FTD `acl-drop` and a Snort inspection verdict tell different parts of the story.

## Topology and addressing

The data path has four nodes: Alpine client → routed FTDv → IOL upstream router → Alpine server. The server runs HTTP on TCP 80 and a separate `nc` listener on TCP 8080\. Both Alpine endpoints use 3.24.2; the IOL router runs 17.18.02.

| Node     | Lab link interface → device interface | Address        | Interface name / security zone |
| -------- | ------------------------------------- | -------------- | ------------------------------ |
| client   | eth1                                  | 10.19.10.10/24 | Client LAN                     |
| ftd      | eth1 → Ethernet0/0                    | 10.19.10.1/24  | inside / inside\_zone          |
| ftd      | eth2 → Ethernet0/1                    | 10.19.20.1/24  | outside / outside\_zone        |
| upstream | eth1 → Ethernet0/1                    | 10.19.20.2/24  | FTD transit link               |
| upstream | eth2 → Ethernet0/2                    | 10.19.30.1/24  | Server LAN                     |
| server   | eth1                                  | 10.19.30.10/24 | HTTP 80 and TCP 8080           |

The links are client eth1 ↔ ftd eth1, ftd eth2 ↔ upstream eth1, and upstream eth2 ↔ server eth1\. MAC checks confirmed the FTD mapping. The CLI names for those data interfaces are **Ethernet0/0 and Ethernet0/1** on this image.

There is no NAT. The client routes 10.19.30.0/24 through 10.19.10.1\. FTD sends that subnet to 10.19.20.2 through outside. The upstream router sends 10.19.10.0/24 back through 10.19.20.1, and the server uses 10.19.30.1 for that client subnet. These specific routes keep the test on the data interfaces. The upstream router has no default route.

Management is separate. The FTD guest management NIC is 10.0.0.15/24 with gateway 10.0.0.2 inside the VM's virtual networking. SSH and HTTPS reach it through the surrounding container and host forwards. Those addresses do not belong on the client-to-server route, and LINA's diagnostic management view is a separate view.

For appliance setup, use the sister lab, [bootstrapping FTDv with local FDM in Containerlab](https://www.pinglabz.com/ftdv-fdm-containerlab-bootstrap/), which covers the management-network fault. Here, wrapper startup took 3 minutes 14 seconds, while FDM bootstrap reported success about 11½ minutes after container start. SSH became usable earlier. These are measured timings from this run, so an available CLI alone was not proof that FDM was ready.

## Build the baseline FTD access control policy through the FDM API

All policy changes in this lab used local FDM's REST API under `/api/fdm/latest`. FDM's Allow action is `PERMIT` in this API; Block is `DENY`.

After initial provisioning, the baseline configuration removed the factory DHCP configuration, set the two routed interfaces, assigned their security zones, created the network and TCP service objects, and installed the server-subnet route in the Global virtual router.

| Object                | Type                | Value         |
| --------------------- | ------------------- | ------------- |
| PL19-Server           | Host network object | 10.19.30.10   |
| PL19-Server-Subnet    | Network object      | 10.19.30.0/24 |
| PL19-Upstream-Gateway | Host network object | 10.19.20.2    |
| PL19-HTTP             | TCP port object     | 80            |
| PL19-Other-TCP        | TCP port object     | 8080          |

The relevant API resources were `/devices/default/interfaces`, `/object/securityzones`, `/object/networks`, `/object/tcpports`, and the Global virtual router's `/staticrouteentries` collection. The interface and zone updates used PUT; object and route creation used POST.

The baseline policy, NGFW-Access-Policy, had one explicit rule:

| Evaluation order | Rule           | Match                                                                     | Action |
| ---------------- | -------------- | ------------------------------------------------------------------------- | ------ |
| 1                | Allow-Web      | inside\_zone → outside\_zone; any source; destination 10.19.30.10; TCP 80 | Allow  |
| Last             | Default action | Traffic not matched above                                                 | Block  |

The policy readback confirmed the default action. This is a response excerpt, with omitted lines marked by `...`:

```json
  "name": "NGFW-Access-Policy",
  "defaultAction": {
    "action": "DENY",
    "eventLogAction": "LOG_BOTH",

```

Allow-Web was created with POST to `/policy/accesspolicies/c78e66bc-cb57-43fe-bcbf-96b79b3475b3/accessrules?at=0`. The zero index places it first. This is the complete recorded request body:

```json
{
  "name": "Allow-Web",
  "sourceZones": [
    {
      "id": "90c377e0-b3e5-11e5-8db8-651556da7898",
      "name": "inside_zone",
      "type": "securityzone"
    }
  ],
  "destinationZones": [
    {
      "id": "b1af33e1-b3e5-11e5-8db8-afdc0be5453e",
      "name": "outside_zone",
      "type": "securityzone"
    }
  ],
  "destinationNetworks": [
    {
      "id": "94afca6e-cb40-11f1-ad50-413f46be8201",
      "name": "PL19-Server",
      "type": "networkobject"
    }
  ],
  "destinationPorts": [
    {
      "id": "95301e07-cb40-11f1-ad50-711a29fba30a",
      "name": "PL19-HTTP",
      "type": "tcpportobject"
    }
  ],
  "ruleAction": "PERMIT",
  "eventLogAction": "LOG_BOTH",
  "type": "accessrule"
}

```

The UUIDs identify objects created in this lab. On another appliance, use the IDs returned by its own object and policy queries.

Saving the rule did not deploy it. The lab then used POST `/operational/deploy` and polled GET `/operational/deploy/{id}` until the job reached its completed state. The baseline deployment response included:

```json
  "id": "99887bb5-cb40-11f1-ad50-358ee94a1e2e",
  "statusMessage": "Deployed successfully",
...
  "state": "DEPLOYED",

```

### Verify HTTP and the blocked TCP listener

Run the application tests from the client at 10.19.10.10\. The recorded `curl` tests used `-sS -v`, a fresh source port selected with `--local-port`, `--connect-timeout 4`, and `--max-time 7`. The `-w` option printed the HTTP status after each attempt. The baseline HTTP request used source port 41001 to reach `http://10.19.30.10:80/`:

```text
PingLabz-FTD-ACP-lab

HTTP_STATUS=200

```

The second test targeted `http://10.19.30.10:8080/` from source port 41002\. The `nc` service was separately verified listening on the server, but no baseline rule allowed it:

```text
HTTP_STATUS=000
...
*   Trying 10.19.30.10:8080...
* Local port: 41002
* Connection timed out after 4000 milliseconds
* closing connection #0
curl: (28) Connection timed out after 4000 milliseconds

exit_code=28

```

The timeout shows the client's symptom. The policy and packet evidence below establish why it happened; a timeout by itself cannot identify a firewall rule.

### Read the deployed policy and counters

At FTD's native `>` prompt, run `show access-control-config`. The baseline output showed the default Block and the intended web match:

```text
> show access-control-config
...
===============[ NGFW-Access-Policy ]===============
Description               : 
=================[ Default Action ]=================
Default Action            : Block
...
----------------[ Rule: Allow-Web ]-----------------
    Action                : Allow
...
    Source Zones          : inside_zone
    Destination Zones     : outside_zone
    Destination Networks  : PL19-Server (10.19.30.10)
    Destination Ports     : PL19-HTTP (protocol 6, port 80)
...
    Rule Hits             : 0

```

For LINA's connection table, compiled access list and packet simulation, enter `system support diagnostic-cli` from that native prompt, then use privileged mode. Run `show conn` and `show access-list` there. Detach back to the native CLI with Ctrl-A, then d.

Before packet simulation, the compiled ACL already showed real traffic hitting both the specific permit and the default deny:

```text
access-list NGFW_ONBOX_ACL line 2 remark rule-id 268435457: L5 RULE: Allow-Web
access-list NGFW_ONBOX_ACL line 3 advanced permit object-group |acSvcg-268435457 ifc inside any ifc outside object PL19-Server rule-id 268435457 event-log both (hitcnt=2) (Last Hit=22:14:11 UTC Oct 18 2026) 
  access-list NGFW_ONBOX_ACL line 3 advanced permit tcp ifc inside any ifc outside host 10.19.30.10 eq www rule-id 268435457 event-log both (hitcnt=2) (Last Hit=22:14:11 UTC Oct 18 2026) 
...
access-list NGFW_ONBOX_ACL line 5 remark rule-id 1: L5 RULE: DefaultActionRule
access-list NGFW_ONBOX_ACL line 6 advanced deny ip any any rule-id 1 event-log both (hitcnt=4) (Last Hit=22:13:50 UTC Oct 18 2026) 

```

The native policy view and API hit-count fields initially reported zero while these LINA counters advanced. Treat those as distinct observations. A zero in the FDM/native rule-hit view did not establish that the rule had seen no traffic.

### Follow packet-tracer through the final decision

In the diagnostic CLI, the HTTP simulation used:

```text
# packet-tracer input inside tcp 10.19.10.10 42180 10.19.30.10 80 detailed

```

Selected output from that simulation:

```text
access-list NGFW_ONBOX_ACL advanced permit object-group |acSvcg-268435457 ifc inside any ifc outside object PL19-Server rule-id 268435457 event-log both 
access-list NGFW_ONBOX_ACL remark rule-id 268435457: ACCESS POLICY: NGFW_Access_Policy
access-list NGFW_ONBOX_ACL remark rule-id 268435457: L5 RULE: Allow-Web
object-group service |acSvcg-268435457
 service-object tcp destination eq www 
Additional Information:
 This packet will be sent to snort for additional processing where a verdict will be reached
...
Phase: 10
Type: EXTERNAL-INSPECT
Subtype: 
Result: ALLOW
...
Phase: 12
Type: SNORT
Subtype: firewall
Result: ALLOW
Elapsed time: 1380211 ns
Config:
Network 0, Inspection 0, Detection 0, Rule ID 268435457
Additional Information:
Starting rule matching, zone 2 -> 1, geo 0 -> 0, vlan 0, src sgt: 0, src sgt type: unknown, dst sgt: 0, dst sgt type: unknown, user 9999997, no url or host, no xff
Matched rule ids 268435457 - Allow
...
Action: allow

```

The initial access-list permit sends the packet onward for inspection. Keep reading: EXTERNAL-INSPECT and the SNORT phases follow, the firewall phase identifies numeric rule 268435457, and the final action allows the packet. The complete baseline output also contains SNORT identity and appid phases.

An FTD `packet-tracer` run is a simulation. Pair it with an actual request before treating it as proof that the application works. The [ASA packet-tracer walkthrough](https://www.pinglabz.com/cisco-asa-packet-tracer/) provides useful background on reading phases; this FTD run also includes the Snort path.

For TCP 8080, the simulation stopped at the default action:

```text
# packet-tracer input inside tcp 10.19.10.10 42181 10.19.30.10 8080 detailed
...
access-list NGFW_ONBOX_ACL advanced deny ip any any rule-id 1 event-log both 
access-list NGFW_ONBOX_ACL remark rule-id 1: ACCESS POLICY: NGFW_Access_Policy
access-list NGFW_ONBOX_ACL remark rule-id 1: L5 RULE: DefaultActionRule
...
Action: drop
Time Taken: 41238 ns
Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame snp_classify_table_lookup:6167 flow (NA)/NA

```

Rule 1 is DefaultActionRule in this policy. It is not Allow-Web. This baseline deny occurred before Snort inspection.

### Trace the real HTTP flow with system support trace

Back at the native FTD `>` prompt, run `system support trace`. Enable firewall-engine-debug with `y`, choose `tcp`, use client IP 10.19.10.10, leave the client port blank, and set server IP 10.19.30.10 with server port 80.

Wait until monitoring is active before starting a fresh client request. The successful baseline trace used source port 41280\. Stop the filtered trace with Ctrl-C after collecting the flow.

The real HTTP exchange produced these lines:

```text
10.19.10.10 41280 -> 10.19.30.10 80 6 AS=0 ID=2 GR=1-1 using HW or preset rule order 1, 'Allow-Web', action Allow and prefilter rule 0
...
10.19.10.10 41280 -> 10.19.30.10 80 6 AS=0 ID=2 GR=1-1 Firewall: allow rule, 'Allow-Web', allow
...
10.19.10.10 41280 -> 10.19.30.10 80 6 AS=0 ID=2 GR=1-1 AppID: service: HTTP(676), client: cURL(596), payload: (0), misc: (0)
10.19.10.10 41280 -> 10.19.30.10 80 6 AS=0 ID=2 GR=1-1 Policies: Network 0, Inspection 0, Detection 0
10.19.10.10 41280 -> 10.19.30.10 80 6 AS=0 ID=2 GR=1-1 Verdict: pass

```

This ties the application request to Allow-Web and shows HTTP/cURL identification with a Snort pass verdict. No intrusion policy or file policy was attached to the allow rule, so this is evidence of the inspected allow path, without an IPS signature-block test.

## Introduce the fault: a broad block above Allow-Web

The deliberate fault adds Block-Lab-Subnet at index 0 in the same access-rule collection. Its zone direction matches Allow-Web, but its destination is the entire server subnet and it has no destination-port restriction.

The complete recorded POST body was:

```json
{
  "name": "Block-Lab-Subnet",
  "sourceZones": [
    {
      "id": "90c377e0-b3e5-11e5-8db8-651556da7898",
      "name": "inside_zone",
      "type": "securityzone"
    }
  ],
  "destinationZones": [
    {
      "id": "b1af33e1-b3e5-11e5-8db8-afdc0be5453e",
      "name": "outside_zone",
      "type": "securityzone"
    }
  ],
  "destinationNetworks": [
    {
      "id": "94e99f21-cb40-11f1-ad50-1595956ea2cb",
      "name": "PL19-Server-Subnet",
      "type": "networkobject"
    }
  ],
  "ruleAction": "DENY",
  "eventLogAction": "LOG_BOTH",
  "type": "accessrule"
}

```

After deployment, the ordered access-rule response contained these entries, shown in returned order:

```json
      "name": "Block-Lab-Subnet",
      "ruleId": 268435458,
...
      "ruleAction": "DENY",
...
      "name": "Allow-Web",
      "ruleId": 268435457,
...
      "ruleAction": "PERMIT",

```

That block includes 10.19.30.10 and TCP 80\. FTD rule order now sends the web connection into the broad deny before it can use Allow-Web. The narrower rule's presence does not give it precedence.

There was a useful intermediate observation: while the new block was only pending, the API already listed it first, yet a fresh HTTP request still returned 200\. The running ACL still contained the baseline allow and default deny. Only after deployment did HTTP fail. When an FDM access rule is not working as expected, compare pending configuration with the deployed policy.

With the block deployed, a new HTTP request from source port 41031 produced:

```text
HTTP_STATUS=000
...
*   Trying 10.19.30.10:80...
* Local port: 41031
* Connection timed out after 4001 milliseconds
* closing connection #0
curl: (28) Connection timed out after 4001 milliseconds

exit_code=28

```

TCP 8080 also timed out. The difference from baseline was that the broad rule now caught both services.

## Diagnose the acl-drop and map rule IDs back to FDM

First, repeat the diagnostic-CLI simulation for the failing destination:

```text
# packet-tracer input inside tcp 10.19.10.10 42380 10.19.30.10 80 detailed
...
access-list NGFW_ONBOX_ACL advanced deny object-group |acSvcg-268435458 ifc inside any ifc outside object PL19-Server-Subnet rule-id 268435458 event-log both 
access-list NGFW_ONBOX_ACL remark rule-id 268435458: ACCESS POLICY: NGFW_Access_Policy
access-list NGFW_ONBOX_ACL remark rule-id 268435458: L5 RULE: Block-Lab-Subnet
...
Action: drop
Time Taken: 167187 ns
Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame snp_classify_table_lookup:6167 flow (NA)/NA

```

The output names Block-Lab-Subnet and numeric rule 268435458, then ends with `acl-drop`. Read the named rule as well as the reason. The baseline TCP 8080 failure had the same drop reason but belonged to default rule 1.

Three identifiers need to stay separate:

| Identifier                         | What it identifies in this lab                                                     |
| ---------------------------------- | ---------------------------------------------------------------------------------- |
| API rule UUID                      | The object to GET or PUT, such as Allow-Web's 981feb02-cb40-11f1-ad50-87e27f80c063 |
| Numeric ruleId / rule-id / Rule ID | The policy rule shared across API, compiled ACL and diagnostic evidence            |
| Rule order or ACL line number      | Its position in a particular policy view; movement can change it                   |

GET `/policy/accesspolicies/{policy-id}/accessrules?includeHitCounts=true` returns the rule names, UUIDs and numeric `ruleId` values. Match the numeric value from packet-tracer or trace to that response. The deployed `show access-list` remarks also pair numeric IDs with readable rule names.

| Numeric ID | Rule              |
| ---------- | ----------------- |
| 268435457  | Allow-Web         |
| 268435458  | Block-Lab-Subnet  |
| 1          | DefaultActionRule |

Do not read the trace's `ID=` flow label as the policy rule ID. Likewise, the baseline phrase “rule order 1” describes a position, while Allow-Web's numeric ID is 268435457\. Reordering preserved that numeric ID and its API UUID.

### Where LINA made the decision

A filtered `system support trace` of a real blocked HTTP attempt, using client source port 41380, showed:

```text
10.19.10.10 41380 -> 10.19.30.10 80 6 AS=0 ID=1 GR=1-1 Got start of flow event from hardware with flags start,end,forward and rule id 268435458
10.19.10.10 41380 -> 10.19.30.10 80 6 AS=0 ID=1 GR=1-1 Generating an SOF event with rule_id = 268435458 ruleAction = 4 ruleReason = None

```

The trace reported a start-of-flow event from hardware for rule 268435458 and action value 4\. It did not report a per-packet Snort drop verdict for this attempt.

To inspect the actual packets at the earlier enforcement point, the lab used a narrow LINA capture with tracing enabled:

```text
# capture PL19FAULT interface inside trace match tcp host 10.19.10.10 host 10.19.30.10 eq 80

```

Generate a fresh matching client request, then inspect the capture in the diagnostic CLI. Four real SYNs were captured. The first packet's trace included:

```text
# show capture PL19FAULT trace
...
Phase: 4
Type: ACCESS-LIST
Subtype: 
Result: DROP
Elapsed time: 35460 ns
Config:
access-group NGFW_ONBOX_ACL global
access-list NGFW_ONBOX_ACL advanced deny object-group |acSvcg-268435458 ifc inside any ifc outside object PL19-Server-Subnet rule-id 268435458 event-log both 
access-list NGFW_ONBOX_ACL remark rule-id 268435458: ACCESS POLICY: NGFW_Access_Policy
access-list NGFW_ONBOX_ACL remark rule-id 268435458: L5 RULE: Block-Lab-Subnet
...
Action: drop
Time Taken: 292742 ns
Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame snp_classify_table_lookup:6167 flow (NA)/NA

```

The capture identifies the same broad rule and ends at the access-list drop. Together with the real-flow event and rule counters, this places the fault at LINA's compiled policy enforcement, before per-packet Snort inspection.

Stop the temporary capture when finished:

```text
# no capture PL19FAULT

```

For more context on this reason code, see the [ASA ASP drop troubleshooting lab](https://www.pinglabz.com/cisco-asa-asp-drop/).

### Use counter changes within the same policy state

Immediately before the real blocked request, LINA showed:

```text
  access-list NGFW_ONBOX_ACL line 3 advanced deny ip ifc inside any ifc outside 10.19.30.0 255.255.255.0 rule-id 268435458 event-log both (hitcnt=0) 
...
  access-list NGFW_ONBOX_ACL line 6 advanced permit tcp ifc inside any ifc outside host 10.19.30.10 eq www rule-id 268435457 event-log both (hitcnt=7) (Last Hit=22:15:54 UTC Oct 18 2026) 

```

After that request's four SYNs, and before the subsequent packet-tracer simulations, it showed:

```text
  access-list NGFW_ONBOX_ACL line 3 advanced deny ip ifc inside any ifc outside 10.19.30.0 255.255.255.0 rule-id 268435458 event-log both (hitcnt=4) (Last Hit=22:18:48 UTC Oct 18 2026) 
...
  access-list NGFW_ONBOX_ACL line 6 advanced permit tcp ifc inside any ifc outside host 10.19.30.10 eq www rule-id 268435457 event-log both (hitcnt=7) (Last Hit=22:15:54 UTC Oct 18 2026) 

```

The broad deny rose from 0 to 4\. Allow-Web stayed at 7\. Those measurements support the same diagnosis as the capture: new web SYNs hit the block first.

Collect real-traffic counter snapshots before simulation because packet-tracer can increment ACL hits. Compare changes within a deployed state, too. Moving a rule can rebuild or reset its counter, so a lower count after repair does not mean traffic stopped matching.

![Fix diagram: Allow-Web moved to index 0, HTTP passes with Snort Verdict: pass while TCP 8080 still hits Block-Lab-Subnet](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/10/ftd-acp-fix-2x.png)

## Fix the order and verify both services again

The repair moves the existing Allow-Web rule to index 0\. It keeps the broad block below it and leaves the default action at Block.

The lab used PUT `/policy/accesspolicies/c78e66bc-cb57-43fe-bcbf-96b79b3475b3/accessrules/981feb02-cb40-11f1-ad50-87e27f80c063?at=0` with the existing rule object. The recorded request body included these fields; the omitted match fields remained the same:

```json
{
  "version": "d55svfetgeamg",
  "name": "Allow-Web",
  "ruleId": 268435457,
...
  "ruleAction": "PERMIT",
  "eventLogAction": "LOG_BOTH",
...
  "id": "981feb02-cb40-11f1-ad50-87e27f80c063",
  "type": "accessrule"
}

```

Then POST `/operational/deploy` and poll the returned deployment ID. The fix deployment completed with:

```json
  "id": "00223dc2-cb42-11f1-ad50-c3599dced703",
  "statusMessage": "Deployed successfully",
...
  "state": "DEPLOYED",

```

The rule list now returned Allow-Web before Block-Lab-Subnet:

```json
      "name": "Allow-Web",
      "ruleId": 268435457,
...
      "ruleAction": "PERMIT",
...
      "name": "Block-Lab-Subnet",
      "ruleId": 268435458,
...
      "ruleAction": "DENY",

```

Retest from the actual client. HTTP from source port 41051 recovered:

```text
PingLabz-FTD-ACP-lab

HTTP_STATUS=200

```

The TCP 8080 test from source port 41052 still timed out:

```text
HTTP_STATUS=000
...
*   Trying 10.19.30.10:8080...
* Local port: 41052
* Connection timed out after 4001 milliseconds
* closing connection #0
curl: (28) Connection timed out after 4001 milliseconds

exit_code=28

```

That is the intended result: the specific web exception works while the broader block still protects the rest of the subnet's services.

A separately held TCP 80 connection appeared in `show conn`:

```text
TCP inside  10.19.10.10:38621 outside  10.19.30.10:80, idle 0:00:04, bytes 0, flags U N1

```

The HTTP simulation again reached the Snort firewall match and completed with an allow:

```text
# packet-tracer input inside tcp 10.19.10.10 42580 10.19.30.10 80 detailed
...
Network 0, Inspection 0, Detection 0, Rule ID 268435457
Additional Information:
Starting rule matching, zone 2 -> 1, geo 0 -> 0, vlan 0, src sgt: 0, src sgt type: unknown, dst sgt: 0, dst sgt type: unknown, user 9999997, no url or host, no xff
Matched rule ids 268435457 - Allow
...
Action: allow

```

For TCP 8080, the fixed policy now identified the broad block, rather than the baseline default rule:

```text
# packet-tracer input inside tcp 10.19.10.10 42581 10.19.30.10 8080 detailed
...
access-list NGFW_ONBOX_ACL advanced deny object-group |acSvcg-268435458 ifc inside any ifc outside object PL19-Server-Subnet rule-id 268435458 event-log both 
access-list NGFW_ONBOX_ACL remark rule-id 268435458: ACCESS POLICY: NGFW_Access_Policy
access-list NGFW_ONBOX_ACL remark rule-id 268435458: L5 RULE: Block-Lab-Subnet
...
Action: drop
Time Taken: 41370 ns
Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame snp_classify_table_lookup:6167 flow (NA)/NA

```

Finally, a fresh real HTTP request under `system support trace` identified Allow-Web, HTTP/cURL, and pass:

```text
10.19.10.10 41680 -> 10.19.30.10 80 6 AS=0 ID=2 GR=1-1 Firewall: allow rule, 'Allow-Web', allow
...
10.19.10.10 41680 -> 10.19.30.10 80 6 AS=0 ID=2 GR=1-1 AppID: service: HTTP(676), client: cURL(596), payload: (0), misc: (0)
10.19.10.10 41680 -> 10.19.30.10 80 6 AS=0 ID=2 GR=1-1 Policies: Network 0, Inspection 0, Detection 0
10.19.10.10 41680 -> 10.19.30.10 80 6 AS=0 ID=2 GR=1-1 Verdict: pass

```

Recovery is supported by the application response, deployed rule order, connection table, simulation and real packet verdicts. The cabling, addresses and routes stayed the same throughout the fault and repair.

## Optional finding: Allow and Trust took different paths

A separate recorded comparison changed only Allow-Web's action to Trust and deployed it. Its match criteria and first position stayed the same. HTTP still returned 200, but the inspection evidence changed.

| Observation                              | Allow                             | Trust                              |
| ---------------------------------------- | --------------------------------- | ---------------------------------- |
| HTTP result                              | 200                               | 200                                |
| EXTERNAL-INSPECT phases in packet-tracer | 1                                 | 0                                  |
| SNORT phases in packet-tracer            | 3: identity, firewall, appid      | 0                                  |
| Real trace                               | Per-packet pass and AppID records | Hardware flow events with action 3 |

The Trust simulation contained:

```text
access-list NGFW_ONBOX_ACL advanced trust object-group |acSvcg-268435457 ifc inside any ifc outside object PL19-Server rule-id 268435457 event-log both 
...
Action: allow

```

The real Trust flow included:

```text
10.19.10.10 41780 -> 10.19.30.10 80 6 AS=0 ID=2 GR=1-1 Generating an SOF event with rule_id = 268435457 ruleAction = 3 ruleReason = None

```

The Trust flow module list also omitted `snp_fp_snort`. This demonstrates a different inspection path and less per-packet trace visibility for this simple rule on the tested build. Neither comparison attached an intrusion policy, so the evidence does not establish an IPS signature outcome.

Allow-Web was restored to `PERMIT` and deployed afterward. Final checks again recorded HTTP 200, TCP 8080 blocked, and Snort pass verdicts. GET `/operational/pendingchanges?limit=1000` returned:

```json
{
  "items": [],
  "paging": {
    "prev": [],
    "next": [],
    "limit": 1000,
    "offset": 0,
    "count": 0,
    "pages": 0
  }
}

```

💡

**FTD runs the same packet-tracer and capture commands in its LINA engine.** The free [Cisco ASA Field Reference PDF](https://www.pinglabz.com/cisco-asa-cheat-sheet/#pdf-asa-field-reference) puts the packet pipeline, NAT order, capture commands and a troubleshooting decision tree on nine printable pages. [PingLabz Pro](https://www.pinglabz.com/membership/?plz%5Fplacement=pricing:ftd-access-control-policy-fdm-packet-tracer:mid:v1) unlocks all 68 browser labs, 500 CCNA practice questions and two timed mock exams for $59/year or $7.99/month.

Coming soon · planned price $19

ASA Firewall Field Kit

A troubleshooting runbook for packet flow, packet-tracer, captures, asp-drop, NAT, failover and IPsec, plus the ASAv Containerlab topologies from the PingLabz ASA labs. It isn't built yet.

[See what's planned and join the waitlist](https://www.pinglabz.com/cisco-asa-field-kit/)

## Verification checklist

- Confirm the inside/outside interface mapping and zone membership against the actual appliance.
- Check the forward and return routes; this lab used routing without NAT.
- Read the ordered rules and default action, then confirm deployment completed.
- Test a fresh HTTP connection and the separately listening TCP 8080 service from the client.
- Map packet-tracer's numeric rule ID to the API rule and compiled ACL remarks.
- Read all simulation phases through the final action, including Snort phases where present.
- Start a filtered real-flow trace before generating traffic; use a capture trace to explain an early ACL deny.
- Record LINA counter changes before simulations, and compare them within one policy state.
- After repair, confirm HTTP passes, TCP 8080 remains blocked, and pending changes are empty.

## Related firewall labs

- [FTDv with local FDM in Containerlab](https://www.pinglabz.com/ftdv-fdm-containerlab-bootstrap/): Bootstrap the appliance and diagnose the management-network fault.
- [ASA packet-tracer](https://www.pinglabz.com/cisco-asa-packet-tracer/): Follow simulated packets through firewall decision phases.
- [ASA ASP drop troubleshooting](https://www.pinglabz.com/cisco-asa-asp-drop/): Investigate drop reasons and connect them to packet evidence.
- [ZBF vs ASA vs FTD](https://www.pinglabz.com/zbf-vs-asa-vs-ftd/): Compare the firewall policy models behind these labs.

## FAQ

### Why is my FDM access rule not working even though Allow-Web exists?

In this lab, a broader deployed block matched first. Check rule order, the matching source and destination zones, host/subnet and port criteria, and whether the latest configuration has been deployed. The pending block already appeared in the API before it affected live HTTP.

### Does an FTD acl-drop mean Snort blocked the connection?

The observed denies here stopped at LINA's access-list check. Baseline TCP 8080 matched default rule 1; the faulted HTTP flow matched Block-Lab-Subnet, rule 268435458\. Use the named rule and capture trace to locate the decision. The blocked real HTTP trace contained a hardware flow event, without a per-packet Snort drop verdict.

### Why does packet-tracer say ALLOW before the flow is finished?

An ALLOW applies to that phase. In the working HTTP simulation, the initial ACL permit forwarded the packet to Snort for further processing. Continue through the SNORT phases and final action, then confirm with a real request and a filtered trace.

### Should I change Allow to Trust to restore web access?

Reordering Allow-Web restored HTTP in this experiment. Trust also passed HTTP in a separate comparison, but it removed the observed EXTERNAL-INSPECT and SNORT phases for this match. That changes the inspection path; it does not repair the original rule-order mistake.