ASA-5525x traffic behavior question

[rpierce@kloveair1.com]

So I made an unfortunate blunder in my migration plan - letting support lapse prior to project closure. It was an important line item missed when the migration project timeline was extended. That said, I'm having a weird issue that I can't figure out. We have a HA pair of 5525s working perfectly except one small quirk - traffic to the inside interface is blocked, by rule, on the primary but the same traffic CAN hit the secondary inside interface. This traffic is generated by a Qualys scanner combing for vulnerabilities and this is the last piece of the PCI compliance (these are our firewalls for PCI segmentation at the data center level.

I could use some guidance - I know I'm missing something, probably simple, but it's got me rather puzzled at the moment.

[Richard Burts]

I want to be sure that I am understanding correctly what is going on. You have a pair of 5525 doing HA active/standby. When the primary is active then some traffic from Qualys scanner to the inside interface is blocked. If there is a failover event and the secondary is active then this traffic from Qualys scanner is permitted. That is certainly strange. Where is this traffic coming from? Outside interface? DMZ interface? something else? A starting point in investigating this would be to post the current running config. If there are public IP addresses I suggest that you change the leading octet(s) (10, 172.16, 192.168) depending on class A, class B, class C so that we have some sense of the network relationships.

[rpierce@kloveair1.com]

It doesn't necessarily have to involve a failover event. Even in it's secondary/passive state the inside interface responds to the Qualys scan. Example:

Qaulys Box @ 1.1.1.10 executes a scan targeting CDE segment zones @ 1.1.100.0/24. The inside interface of the primary/active firewall would be 1.1.100.1 while the standby/secondary is @ 1.1.100.2.

1.1.100.1 passes the scan, all scan attempts blocked.

1.1.100.2 fails the scan, allowing traffic to pass.

Configuration is identical, sync'd properly via HA.

Failing over results in the same issue - 10.10.100.1 still blocks traffic (secondary as active now) while 10.10.100.2 (primary as passive) allows it. All other traffic follows the expected ACL path and is properly processed.

I've attached a sanitized copy of the configuration and a quick (re: ugly) map. Black lines mark the "overall" data paths. Red is blocked traffic, green is (of course) allowed