packet tracer not working well in FMC/FTD

Packet-tracer never worked well with VPN traffic, that was ok but now in FMC/FTD its also not working at all if you have snort or geoblocking rules. You will see an ip any any allow. Instead you must use the system support trace on live traffic. The whole point of packet tracer is that we don't always have live traffic or access to generate live traffic.

From cisco:

Indeed, from the packet tracer side it looks like the packet is going through in that IP permit any any, but that rule in reality does not exist.

Any rule which relies on snort will be classified by the box as a L4 permit ip any any, and unfortunately having a geodb rule looks like a snort rule for the box.

This is documented here:

https://www.cisco.com/c/en/us/support/docs/security/secure-firewall-threat-defense/218196-understand-how-lina-rules-configured-wit.html

Rules with Snort Features Are Deployed As Permit Any Any

When you create a rule with features that are run by Snort side, like Geolocation, URL (Universal Resource Locator) filter, Application detection, etc, they are deployed on Lina side as a permit any any rule.

At a first glance, this can confuse you and make you think that the FTD allows all the traffic on that rule and stops the rule match verification for the rules that follow.

We also have an enhancement request for this: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwd00446

Unfortunately, this breaks the usage of the packet tracer feature, and in this case, you should rather use “> system support trace” if there is live traffic.

packet capture on ASA

access-list CAP_OUT_ACL extended permit tcp host 172.20.178.12 host 172.20.188.12 eq 443
access-list CAP_IN_ACL extended permit tcp host 172.20.188.12 host 172.20.178.12 eq 443
capture CAP_OUT interface WAN access-list CAP_OUT_ACL
capture CAP_IN interface WAN access-list CAP_IN_ACL

clear capture CAP_OUT
clear capture CAP_IN

sh capture
sh capture CAP_OUT

Tip on using packet tracer on Cisco ASA

I use the packet tracer tool quite often on ASA's. A Cisco engineer told me its better to always do the traces from the inside out, because traffic coming from the VPN is encrypted and we cannot inject encrypted traffic. He also said its a good idea to run it twice just incase the VPN isn't up already.

packet-tracer input INSIDE tcp 192.168.10.10 22 172.30.10.10 4444 detailed

instead of

packet-tracer input OUTSIDE tcp 172.30.10.10 4444 192.168.10.10 22 detailed

When we see the follow at the end of our trace

Type: VPN
Subtype: encrypt
Result: ALLOW

We know the data was encrypted and sent over the VPN

I've also seen
Phase: 7
Type: VPN
Subtype: encrypt
Result: DROP

Everything looked good on my end. The other need needed to update the proxy ID's.