Showing posts with label Cisco PIX. Show all posts
Showing posts with label Cisco PIX. Show all posts

Wednesday, 5 March 2008

[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.

Thursday, 7 February 2008

[Technical] - How to Static NAT two Public IPs to 1 Private IP?

A common question I get is can I NAT more than one public IP to a private IP using the Cisco ASA (or PIX) firewall.

The simple answer is yes, but you can't using the "static" command as you would expect or else you'll get the error "ERROR: duplicate of existing static".

So the following configuration will fail;
static (Inside,Outside) 201.10.10.2 10.10.10.1 netmask 255.255.255.255
static (Inside,Outside) 100.20.30.3 10.10.10.1 netmask 255.255.255.255


However using policy NAT on the PIX/ASA using code 7.x and beyond (Tested on 8.x) the following will work.
access-list policy_1 extended permit ip host 10.10.10.1 any
access-list policy_2 extended permit ip host 10.10.10.1 any
static (Inside,Outside) 201.10.10.2 access-list policy_1
static (Inside,Outside) 100.20.30.3 access-list policy_2


Interestingly if you ping 100.20.30.3 from the outside you see the echo-reply come from 201.10.10.2. ICMP isn't stateful through the firewall so the Policy NAT will use the first IP in the list as the source address of any outgoing initiated flow.

Bob