dACL on switches in open mode with pre-auth ACL

[Johannes Luther]

Hi board,

maybe this topic is correct in the switching section of the board as well, but I'll try it here.

Let's assume I'm using open authentication on a switch port along with a pre authentication ACL. Let's call it PORT-PRE-AUTH-ACL

The pre-authentication ACL contains the usual stuff like PXE, DHCP, DNS and so on (yes, we want to do profiling :) )

Now the client behind the port is sucessfully authorized and a dACL is applied to the session. The IP device tracking magic jumps in and adds the IP address of the actual connected client in the source portion of the ACL.

Now the question: What happens with the content of the PORT-PRE-AUTH-ACL on the switch port?

• Is the pre-authentication ACL content gone for the session?
• Are the ACLs concatenated? The static pre-auth ACL comes first and the dACL content comes after that?
• Are the ACLs concatenated? The dACL content comes first and the static pre-auth ACL comes after that?

I think the answer to this question is: It depends - right?

From my point of view this is heavily platform and SW version dependent. Do you agree? Also I think the documentation is very poor in this particular case.

For example on a 2960-X and 2960-S with IBNS2.0 config style running 15.2 code, the behavior is that the

dACL content is put obove the static port ACL. But the static port ACL stays in place.

Why am I asking this question?

• This is relevant when placing explicit deny statements somewhere in the port or dACL
• TCAM resource saving on the switch. For example if I permit DHCP in the pre-auth-ACL, I don't have to allow DHCP in the dACL if the ACLs are concatenated. Therefore I have less ACE entries --> saving of TCAM resources on the switch.

Maybe it's a good idea if we assemble a list from "field experience". I start with the two devices from above:

Platform	Version	Behavior	Remarks
Cat. 2960X	15.2(4)	concat: dACL then port ACL	IBNS2
Cat. 2960S	15.2(2)	concat: dACL then port ACL	IBNS2
Cat. 4500 Sup8	3.7.0E	concat: dACL then port ACL	Updated 2016/03/31 by NicolasDemonty (Thank you)
Cat. 6800	15.2(1)SY2	concat: dACL then port ACL	Updated 2016/08/26 by jcockburn (Thank you)

Anybody has Cat6k (ok - it's hard with IBNS2.0 on this platform), Cat4k, Cat3k ?

[Peter Koltl]

Did you conclude that from 

show ip access-list interface Gi1/0/x

output?

[Johannes Luther]

Hi Peter,

the sources are:

• As you already said, the show ip access-list output on the platforms mentioned above
  Example:

Switch#show ip access-lists interface <ID>
     permit icmp host <SOURCE-IP> any echo
     permit icmp host <SOURCE-IP> any echo-reply
     permit icmp host <SOURCE-IP> any time-exceeded
     permit icmp host <SOURCE-IP> any unreachable
     permit udp host <SOURCE-IP> bootpc any eq bootps
Extended IP access list port-acl-default
    10 permit ip any any

At least from the output the dACL comes first, followed by the static port acl. And the port ACL is working, because I can reach any destination with TCP.

• The second source is:
  http://www.cisco.com/c/en/us/support/docs/lan-switching/8021x/119374-technote-dacl-00.html#anc18

Unfortunately, (again platform dependent) both ACLs are concatenated. That happens on Version 15.2.2 on 3750X. That means that for authorized session, both of them are applied. First the DACL and second the interface ACL. That is why when you add explicit "deny ip any any", the DACL will not take into consideration the interface ACL. Usually there is no explicit deny in the DACL and then the interface ACL is applied after that.

The behavior for Version 15.0.2 on 3750X is the same, but the sh ip access-list interface command does not show the interface ACL anymore (but it will still be concatenated with the interface ACL unless explicit deny in the DACL exists).

The "again platform dependent" bugs me a little bit. I want to know which platform with which code version has what kind of behavior.

[NicolasDemonty]

Hi

on cisco 4510R+E (Sup8) (ios 3.7.0E), the show ip access-list command shows the same "concatenated" behaviour. I'm quite sure it is the same for 6k

did you some test to ensure the default port acl is really applied ?

kr

[Johannes Luther]

Hey Nicolas,

thanks für the answer.

I tested it very quickly with a ping to a resource which was allowed by the port ACL but not allowed by the port ACL. Unfortunately this test does not show the order of the ACLs.

I add the Cat 4k to the list above - thanks

[Johannes Luther]

Hi Nicolas,

one follow up on this. Did you use the classical 802.1X/MAB configuration or the new IBNS2 Style using policy-maps?

[Peter Koltl]

What does the new IBNS2 style look like?

[Johannes Luther]

This is the "current" IBNS1.0 Style

interface GigabitEthernet1/0/1
 description ** Access Port **
 switchport access vlan 100
 switchport mode access
 switchport voice vlan 10
 ip access-group IPV4-PRE-AUTH-ACL in
 authentication host-mode multi-auth
 authentication open
 authentication order dot1x mab
 authentication priority dot1x mab
 authentication port-control auto
 mab
 dot1x pae authenticator
 spanning-tree portfast
!

This is an example for the new IBNS 2.0 Style

interface GigabitEthernet1/0/1
 description ** Access Port **
 switchport access vlan 100
 switchport mode access
 switchport voice vlan 10
 ip access-group IPV4-PRE-AUTH-ACL in 
 access-session port-control auto 
 mab
 dot1x pae authenticator
 spanning-tree portfast 
 service-policy type control subscriber POLICY_Gi1/0/1
!
policy-map type control subscriber POLICY_Gi1/0/1
 event session-started match-all
  10 class always do-until-failure
   10 authenticate using dot1x priority 10
 event authentication-failure match-first
  10 class DOT1X_NO_RESP do-until-failure
   10 terminate dot1x
   20 authenticate using mab priority 20
  20 class MAB_FAILED do-until-failure
   10 terminate mab
   20 authentication-restart 60
   30 class always do-until-failure
  10 terminate dot1x
  20 terminate mab
  30 authentication-restart 60
 event agent-found match-all
  10 class always do-until-failure
   10 terminate mab
   20 authenticate using dot1x priority 10
!

Also see the deployment guide for this

http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/identity-based-networking-services/whitepaper_C11-729965.html

From my point of view the strength of the new system are:

• MAB and 802.1X runs parallel instead of sequentially
• In case the RADIUS server is down, the port ACL can be overridden without EEM

Nevertheless I don't think it has an impact on the dACL topic we're discussing here (but I'm not sure)

[jcockburn · Accepted solution]

Hi,

We have 6500's on IBNS1 and 6880's on IBNS2

The same regarding dACLs and PACLs...

dACL is concat'ed on top of PACL.

One thing to note, we have a posture/remediation phase which redirects the client to the portal as well and when we migrated to IBNS2 we found different implementations.

IBNS1 = RACL + dACL + PACL

IBNS2 = dACL + RACL + PACL

so if for some reason you had a deny any in the dACL the RACL will never be matched...just saying.

[Johannes Luther]

Wow - an answer to my old post. Thank you so much (5 stars)! I will update the table in the first topic. Interesing behavior regarding the redirection ACL though and I have to admit I wasn't aware of the fact, that the 6k is IBNS 2.0 capable now. Good to know. What SW versions are you using for the 6800 if I may ask?

[jcockburn]

Hi Johannes,

Our 6500's are still running IBNS1...we are currently in refresh to replace them.

SO only the 6880's are on IBNS2.0.

6880's are running on 12.2(1)SY2

If you are thinking on getting 6880's let me know as there are multiple gotchas on that architecture.

Ciao

JC

[Johannes Luther]

Thank you for the information. I already deployed the 68ks in production as core and distribution platforms - so no user access. So far (for my needed functions) they are working quite well :)

[jcockburn]

Hi Johannes,

I think you should stick to that design with 6800's (6807 or 6880) as core and distris. I believe they are awesome for that function.

We have the 6880's as Instant Access so kind off collapsed access/distribution. For low (under 1000) access port count we have no issues using authentication and posture etc.

Over that we had tons of issues, but hopefully we seem to be fixing that...we just need some downtime to test again...hehe...

[Johannes Luther]

Hi JC,

there was a small typo ... It must be 15.2(1)SY2, right?

So in theory (IBNS2) must work for the 6k with SUP2T as well.

[jcockburn]

Hi Johnannes,

Yes, typo....

You are right, must be 15.2(1)SY2

Quick question if I may, do you run the 6880's in VSS?

If so do you have a dedicated link for dual-active detection? or do you use PAgP for this?

Ciao

JC