Cisco – How does group-policy inheritance work for a Cisco ASA

My understanding is that when using the SDI protocol for RSA integration, you cannot pass group/class info. However, if you reach the RSA server using RADIUS, then the RSA server can be configured to return a RADIUS Class attribute of the format "OU=group-policy-name;" which is then used to match a group-policy name in the ASA config. I've done it this way with another customer. For example:

aaa-server RSA protocol radius
aaa-server RSA (inside) host 10.1.1.50
 key *****
 authentication-port 1812
 accounting-port 1813

Then, you would have a group-policy that fails closed (I usually call it "NOACCESS") that sets "vpn-simultaneous-logins" to 0 which drops the connection, like so:

group-policy NOACCESS internal
group-policy NOACCESS attributes
 vpn-simultaneous-logins 0

You would then have one or more group-policies that describe your VPN users and override the "vpn-simultaneous-logins" value with a non-zero value (I usually set it back to the default value of 3), like this:

group-policy Users internal
group-policy Users attributes
 vpn-simultaneous-logins 3
 <other VPN policy settings go here>

Finally, your tunnel-group would be set to use the RSA server (via RADIUS) for the authentication server, and then the default group policy is set to the "NOACCESS" group to force the group to fail closed if the RADIUS Class value isn't returned:

tunnel-group RA-VPN type remote-access
tunnel-group RA-VPN general-attributes
 authentication-server-group RSA
 default-group-policy NOACCESS

The important notes with this solution are:

• The Class attribute returned by RADIUS must be (without quotes, note the very important semi-colon) "OU=group-policy-name;"
• The "group-policy-name" returned in the Class attribute must be an exact match for the group-policy name configured in the ASA, including matching case.

The behavior is that the user's session will inherit the default group-policy value of "NOACCESS" and be assigned the attribute of "vpn-simultaneous-logins 0" if no matching RADIUS Class attribute is returned. If a Class attribute which matches the name of a group-policy in the ASA is returned, the user session is assigned that group-policy instead, which then overrides the inherited default "vpn-simultaneous-logins" value and allows them to continue their login.

I've used this RADIUS configuration regularly for years, and a customer I worked with discovered the RSA requirement that RADIUS be used to pass the Class attribute for group assignment. Unfortunately I do not know the RSA setup to do the group mapping or return the attributes, but this thread and this thread may prove helpful there.

The easiest way to figure out why your ASA drops traffic:

• If it's a routed ASA firewall, use packet-tracer
• Both routed and transparent ASA firewalls can use capture [NAME] asp-drop

Using packet-tracer (only on routed ASA firewalls):

Routed firewalls give us the most information when we need to figure out why something was dropped; it's best to use packet-tracer to figure out why the routed firewall dropped something (although it won't catch every possible case).

I'm assuming 172.16.1.5's source port is 1024 for the purposes of getting a diagnosis... The syntax is packet-tracer input INSIDE tcp [SRC_HOST] [SRC_PORT] [DST_HOST] [DST_PORT]

asa-fw# packet-tracer input INSIDE tcp 172.16.1.5 1024 4.2.2.2 9000

!!! output truncated

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: DROP                                            <---- ASA Dropped the traffic
Config:
access-group INSIDE_in in interface INSIDE
access-list INSIDE_in extended deny ip any4 any4 log    <---- This rule denied the traffic
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   <----

asa-fw#

Using capture [NAME] asp-drop (routed or transparent ASA firewalls):

Transparent firewalls are trickier to diagnose, but you can still get some useful information with the capture ... asp-drop command. The ASP is the ASA's "Accelerated Security Path"; this is where many drops happen. I have seen some dropped traffic that doesn't show in asp-drop, but usually that's because of an overwhelmed backplane in the ASA.

There are four steps...

1. Configure a packet capture buffer on the ASA. For tcp traffic, the syntax is capture [CAPTURE_NAME] type asp-drop all buffer [BUFFER_SIZE] match tcp host [SRC_HOST] host [DST_HOST] eq [DST_PORT]
2. Wait for the denied traffic
3. show capture [NAME] trace to understand why the traffic was denied.
4. Remove the capture with no capture [CAPTURE_NAME]

This is an example which shows traffic to 4.2.2.2 on tcp/9000 is denied by a configured firewall rule.

asa-fw# capture DENY type asp-drop all buffer 500000 match tcp host 172.16.1.5 host 4.2.2.2 eq 9000


asa-fw# sh capture DENY trace

1 packet captured

   1: 06:13:43.434761       802.1Q vlan#200 P0 172.16.1.5.33489 > 4.2.2.2.9000: S 
   884023774:884023774(0) win 14600 <mss 1460,sackOK,timestamp 67442169 0,nop,wscale 7> 
   Drop-reason: (acl-drop) Flow is denied by configured rule
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

1 packet shown
asa-fw# no capture DENY

When you finish, be sure to unconfigure the capture with no capture DENY