ASP Drop (acl-drop)

[dcanady55]

Hello,

FTD 2110 on 7.4.2

I'm investigating why I'm unable to reach a vendor destination off my secondary VPN. I ran an ASP capture and received the following message in bold. However, I can run a packet tracer using the same source and destinations in the ASP message and it comes back as allowed. I am unable to run a debug for this particular destination as its not static. I tried running a debug using any as my destination and the debug session doesn't show any hits to that range of IP's I'm trying to get to. I assume ASP must happen even before debugs and that's why I'm not seeing anything? How else can I determine which ACL is causing the drop? 

Thanks,

Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location:

[ccieexpert]

can you provide more details ?

is the vpn tunnel established ? what is source and destination ? maybe you can attach the config snip..

show crypto ipsec sa peer <remote peer>

i would suggest doing a capture  with "trace detail" at the end to give more details, and then run a ping to the remote subnet.

this link is for ASA, but should be the same for FTD cli:

https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/118097-configure-asa-00.html

get multiple out of the "show crypto ipsec sa peer <peer ip>" so we can see if encrypt or decrypts are happening..

is this a crypto map or VTI ? if its a crypto map, then do you have NAT exemption for this traffic ?

[dcanady55]

I apologize for the confusion, as I should have said AnyConnect. We have two datacenters and accessing the location on the one ravpn works fine. The second datacenter has the correct routes for these subnets and knows it has to send that traffic back to the inside and eventually that would make its way over to the primary DC and out that point to point circuit. The path is in place but the FTD at the secondary DC drops the traffic for Uknown reasons. I have run the trace with details command and everything in there is accurate including found next hop interface Inside. 

[ccieexpert]

please share the output of the capture with trace option on the live traffic from a client..packet tracer is not the most accurate for sslvpn traffic.. run a capture for the actual client anyconnect assigned ip and the destination it is trying to go to.. do that on the outside and also on the inside...

if the packet has left the inside interface then the problem is somewhere else..

[dcanady55]

Here's what I've already done. Hopefully, you can tell me if I'm doing something wrong. The vendor address is three /24 networks so hard to know which IP address is going to be used. You can see that I setup 3 captures and ASP to those networks and try and open the website. ASP capture is the only one that responds. 

Looking at ASP logs it shows me an IP address that falls within one of those 3 networks. 

I took that IP address from the ASP logs and checked the routing table to confirm it knows to send this to the Inside.

I did run the same 3 captures to those networks using the Outside interface to be sure nothing odd was occurring and 0 bytes returned which was expected. At this point I ran the packet tracer only to be surprised when it said allowed and the path was correct. It's at this point I posted my message here asking if there's another way to figure why the FTD is dropping these packets via ASP. 

Thanks,

[MHM Cisco World]

friend run packet-trace 
share result here 

thanks 

MHM

[dcanady55]

here you go.

2110-Primary# packet-tracer input insIDE tcp 10.73.222.23 41505 1.2.3.4 443

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Elapsed time: 30708 ns
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: INPUT-ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Elapsed time: 31561 ns
Config:
Additional Information:
Found next-hop 10.180.0.241 using egress ifc INSIDE(vrfid:0)

Phase: 3
Type: OBJECT_GROUP_SEARCH
Subtype:
Result: ALLOW
Elapsed time: 9553 ns
Config:
Additional Information:

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Elapsed time: 9553 ns
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip any any rule-id 268471308
access-list CSM_FW_ACL_ remark rule-id 268471325: ACCESS POLICY: 2110-ACP - Mandatory
access-list CSM_FW_ACL_ remark rule-id 268471325: L7 RULE: VPN-MDT-RELATED-SERVICES
access-list CSM_FW_ACL_ remark rule-id 268471308: ACCESS POLICY: 2110-ACP - Mandatory
access-list CSM_FW_ACL_ remark rule-id 268471308: L7 RULE: Personal Email Block
Additional Information:
This packet will be sent to snort for additional processing where a verdict will be reached

Phase: 5
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Elapsed time: 9553 ns
Config:
class-map class-default
match any
policy-map global_policy
class class-default
set connection advanced-options UM_STATIC_TCP_MAP
service-policy global_policy global
Additional Information:

Phase: 6
Type: NAT
Subtype: per-session
Result: ALLOW
Elapsed time: 9553 ns
Config:
Additional Information:

Phase: 7
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Elapsed time: 9553 ns
Config:
Additional Information:

Phase: 8
Type: FOVER
Subtype: standby-update
Result: ALLOW
Elapsed time: 54592 ns
Config:
Additional Information:

Phase: 9
Type: OBJECT_GROUP_SEARCH
Subtype:
Result: ALLOW
Elapsed time: 98095 ns
Config:
Additional Information:

Phase: 10
Type: NAT
Subtype: per-session
Result: ALLOW
Elapsed time: 853 ns
Config:
Additional Information:

Phase: 11
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Elapsed time: 853 ns
Config:
Additional Information:

Phase: 12
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Elapsed time: 116861 ns
Config:
Additional Information:
New flow created with id 25216164, packet dispatched to next module

Phase: 13
Type: EXTERNAL-INSPECT
Subtype:
Result: ALLOW
Elapsed time: 18766 ns
Config:
Additional Information:
Application: 'SNORT Inspect'

Phase: 14
Type: SNORT
Subtype: firewall
Result: ALLOW
Elapsed time: 79744 ns
Config:
Network 0, Inspection 0, Detection 2, Rule ID 268471310
Additional Information:
Starting rule matching, zone 2 -> 2, geo 0 -> 0, vlan 0, src sgt: 0, src sgt type: unknown, dst sgt: 0, dst sgt type: unknown, user 9999999, no url or host, no xff
Matched rule ids 268471310 - pending AppID

Phase: 15
Type: SNORT
Subtype: appid
Result: ALLOW
Elapsed time: 10276 ns
Config:
Additional Information:
service: (0), client: (0), payload: (0), misc: (0)

Phase: 16
Type: INPUT-ROUTE-LOOKUP-FROM-OUTPUT-ROUTE-LOOKUP
Subtype: Resolve Preferred Egress interface
Result: ALLOW
Elapsed time: 16207 ns
Config:
Additional Information:
Found next-hop 10.180.0.241 using egress ifc INSIDE(vrfid:0)

Phase: 17
Type: ADJACENCY-LOOKUP
Subtype: Resolve Nexthop IP address to MAC
Result: ALLOW
Elapsed time: 4265 ns
Config:
Additional Information:
Found adjacency entry for Next-hop 10.180.0.241 on interface INSIDE
Adjacency :Active
MAC address 98a2.c017.0945 hits 3774039 reference 284

Result:
input-interface: INSIDE(vrfid:0)
input-status: up
input-line-status: up
output-interface: INSIDE(vrfid:0)
output-status: up
output-line-status: up
Action: allow
Time Taken: 510546 ns

[MHM Cisco World]

Friend packet tracer must be from any IP of anyconnect pool (you must sure that this IP is not use by any anyconnect client)

The interface the traffic enter to is OUT (or name of interface you apply anyconnect on it)

MHM

[dcanady55]

I'm not sure what your asking. The packet tracer has the correct information in it. 

[MHM Cisco World]

What is anyconnect pool subnet?

What is name of interface you use for anyconnect?

MHM

[ccieexpert]

your packet-tracer used the inside ? is that the interface the anyconnect clients connects to 

as i said earlier it is better to do a capture with trace on a real active session to see why the traffic is dropped...

[dcanady55]

Ok, I see my mistake. I ran the tracer with outside as input and used an IP address that wasn't be used. The return shows denied with the following. Thoughts on the rpf-check? 

Thanks,

Phase: 9
Type: NAT
Subtype: rpf-check
Result: DROP
Elapsed time: 5971 ns
Config:
nat (INSIDE,OUTSIDE) source dynamic any interface
Additional Information:

[ccieexpert · Accepted solution]

make sure you put a nat exemption from inside to outside for the ip pool .. otherwise it ill match the NAT that is shown in the packet tracer and block it based on NAT rpf check.

https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/116388-technote-nat-00.html

[dcanady55]

Thanks,

I will review this document, but I have no issue hitting this site on my other FTD and those NAT rules are the same for this FTD. 

[dcanady55]

I found my issue within this document thanks!