1

I'm seeing traffic from numerous internal endpoints where a RST or FIN/ACK is sent by the endpoint to a host on the Internet. These connections are related with a transparent proxy that is not handling these properly. Instead of dealing with them, it simply forwards them to the ASA. The ASA has never observed these connections before.

The ASA (8.2) sees this traffic and generates a 106015 event (no connection) and denies the traffic. This is precisely what I expect. However, the ASA will also log a 106100 event that states the traffic is permitted. There is an ACE that states "permit ip any any log".

Based on traffic captures, it was confirmed that the traffic was denied and not permitted.

Why is the 106100 event happening then? It's completely thrown us for a loop as it appears that the ASA has allowed traffic when in fact it has not. If the ASA drops the traffic due to lack of existing connection, why would it go anywhere near the ACLs, much less generate a permit log?

Here are the logs in questions:

: %ASA-6-106015: Deny TCP (no connection) from 10.x.x.x/62938 to 216.x.x.x/80 flags FIN ACK  on interface inside

: %ASA-6-106100: access-list inside permitted tcp inside/10.x.x.x(62938) -> outside/216.x.x.x(80) hit-cnt 1 first hit [0x62c4905, 0x0]

Timestamps of the two events are identical.

Any advice would be appreciated, thanks.

Edit: Clarification
According to this Cisco article on packet flow. http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113396-asa-packet-flow-00.html

"If packet flow does not match an existing connection, then TCP state is verified. If it is a SYN packet or UDP packet, then the connection counter is incremented by one and the packet is sent for an ACL check. If it is not a SYN packet, the packet is dropped and the event is logged."

Based on this described behavior, I'm still unsure as to why I'm seeing the 106100 log indicating the traffic is permitted.

1

The ACL is being evaluated before the connection tracking and NAT evaluation (check the output of packet-tracer simulating this traffic), and because the traffic hits that rule, it logs as you've instructed it to in permit ip any any log.

6
  • That's the opposite of how I thought it worked. I thought it would check the packet against existing connections prior to applying it to its ACLs as it would be quite a bit faster than applying every packet to the ACL. I'll certainly see how things look with packet tracer though. Thanks for the response. – Sgt B May 13 '14 at 19:58
  • 1
    @SgtB Check out packet-tracer with appropriate fake traffic to see exactly what it's evaluating and in what order. – Shane Madden May 13 '14 at 19:59
  • Will do, thanks Shane. It'll take some doing as I don't have access to the ASA, but it'll certainly help. Thanks – Sgt B May 13 '14 at 20:11
  • Actually how would I use packet-tracer to inject and trace RST or FIN/ACK packets? This behavior only occurs when a RST or FIN/ACK packet is observed that is not associated with an existing connection. – Sgt B May 13 '14 at 20:21
  • 1
    @SgtB I don't think you can, but you can see the order in which the processing occurs. – Shane Madden May 13 '14 at 20:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.