CCIE Security Anyone?

[Technical] – Unable to define a source-interface with TACACS+ on the Cisco ASA/PIX

We had a requirement to have an ASA authenticate with 2 geographically dispersed ACS servers for resilience.

• ACS1 is connected via the dmz1 interface.
• ACS2 is connected via the dmz2 interface.
• ACS1 replicates to ACS2.

The Cisco ASA/PIX doesn’t support using a source-interface for TACACS+ like a Cisco IOS based router does. So the ACS sees the request as coming from the IP address of the outgoing interface on the ASA.

The only solution is to configure two IPs within ACS per ASA one that relates to the dmz1 and one that relates to the dmz2 interfaces.

[Technical] - “Flow is denied by configured rule” message with ASA packet-tracer and traffic being dropped at the VPN phase.

I came across an interesting issue today where traffic wasn’t passing across a new IPSec Lan-to-Lan VPN correctly. On both sides were Cisco ASA firewalls 8.0(2), with the local one managed by me and the remote by a 3rd party.

Some traffic was flowing correctly and some wasn’t. A packet trace of a failing stream showed the following:


ASA#packet-tracer input inside tcp 10.1.1.65 16664 20.1.1.1 http

Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Additional Information:
Found no matching flow, creating a new flow

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Additional Information:
in 0.0.0.0 0.0.0.0 outside

Phase: 5
Type: NAT-EXEMPT
Subtype:
Result: ALLOW
Config:
nat (inside) 0 access-list inside_nat0_outbound
match ip inside 10.1.1.64 255.255.255.192 outside 20.1.1.0 255.255.255.0
NAT exempt
translate_hits = 3, untranslate_hits = 0

Phase: 6
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

Clearly the VPN phase shouldn’t have been dropping the traffic.

This was confusing there were no ACLs blocking traffic, the route, nat and crypto acl were all ok. However upon investigation the remote crypto ACL didn’t have an entry for this stream.

Upon modifying them so they were symmetrical the issue was resolved.