all 9 comments

[–]Epic800 1 point2 points  (1 child)

See what Snort is doing with the traffic.

  1. CLI into FTD logical device
  2. Run the following command:

system support firewall-engine-debug

  1. Put in the parameters for your traffic
  2. You will be able to determine if Snort is dropping the traffic due to a configured rule with this debug output

[–]tolegittoshit2A+/N+/S+/CCNA 0 points1 point  (0 children)


system support firewall engine debug - this form of troubleshooting nips everything in the bud and helps you get to the root issue very fast...i found it in the ftd book by nazmul, then confirmed its widely used with cisco tac support when i have issues.

[–]ccie39206 0 points1 point  (4 children)

I would try creating a fast path rule so that the connection doesn't get passed through the rest of the firepower packet processing steps. That should eliminate most other features from affecting the traffic flow.

[–]sg4rb0sss[S] 0 points1 point  (1 child)

fast path rule

Do you know where I can find the 4150 documentation for the fastpath rule.

[–]sg4rb0sss[S] 0 points1 point  (0 children)

It's okay, I've done it. Testing now.

[–]sg4rb0sss[S] 0 points1 point  (0 children)

Would you happen to know if there is a way to see on the firepower device if it's the MPF blocking the traffic in the logs? When I do a packet-tracer input command, it actually shows the traffic passing as ACCEPT and FORWARD at the end. But in the actual logs of the firewall, it is showing as packets are being denied.

[–]xeon65 0 points1 point  (0 children)

Fastpath doesn't work on 4150 platform, you have to use prefilter now.

[–]Kayami 0 points1 point  (1 child)

ASA software has protocol inspection turned on for port 1521 by default. Protocol inspection is in effect even if you have a rule permitting all access. Try disabling this inspection and see if the connectivity issues are resolved. It is possible that there are commands happening over port 1521 that the protocol inspection does not know how to handle and the connections are being dropped.

More info is available here:


[–]kaisero 0 points1 point  (0 children)

He is using FTD and not ASA, so that configuration guide won't help

@sg4rb0sss - try disabling sqlnet inspection using the following command on your active firewall:

> configure inspection sqlnet disable

If that doesn't help create a packet capture for asp drops so we can see exactly why the traffic is dropped (the following command will capture packet headers for all traffic going from your src to dst port tcp/1521 with max. buffer size of 3MB

> capture ASP-DROP type asp-drop all headers-only buffer 33554432 match tcp host <client-ip> host <server-ip> eq 1521

You can use the "show capture ASP-DROP" command to verify if anything is captured. In case you are running an older version ( < 6.2.3) do NOT clear the capture using "capture ASP-DROP /clear" when the buffer is full... there is a bug that will cause the firewall to reboot... if you need to clear the buffer delete the capture using "no capture ASP-DROP" command.