Solved: NAC - Unauthorized status and bad dACL ruining Monitor Mode

vv0bbLeS · ‎11-06-2023

Hello all,

Not sure if this is the right forum or if I should post to the Switching forum, but I'll start here. : )

We're starting to implement NAC in Monitor Mode on several of our switches, and we have a fairly mature ISE instance. We have someone else that handles the ISE part, so I just handle the network part.

I have 2 different scenarios where devices are denied access to the network:

Scenario "Unauthorized" - Device is Unauthorized, and doesn't have access to the network.
Scenario "Bad dACL" - Device is authorized, but gets a generic "restrictive" dACL incorrectly applied from ISE, which essentially denies the device access to the network.

Before we go much further, here is my NAC config on the switch:

+---------------------------+
|   General switch config   |
+---------------------------+
dot1x system-auth-control
aaa authentication dot1x default group radius
aaa authorization network default group radius
aaa authorization auth-proxy default group radius
aaa accounting update periodic 5
aaa accounting dot1x default start-stop group radius
aaa accounting system default start-stop group radius
aaa server radius dynamic-author

  client 10.10.10.11 server-key 6 [supersecretkey]  ! ISE Server 1
  client 10.10.10.22 server-key 6 [supersecretkey]  ! ISE Server 2
  client 10.10.10.33 server-key 6 [supersecretkey]  ! ISE Server 3
  
ip radius source-interface vlan10  ! Data VLAN

radius-server attribute 6 on-for-login-auth
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server dead-criteria time 30 tries 3

radius server ISE-SERVER-1
  address ipv4 10.10.10.11 auth-port 1812 acct-port 1813
  key 7 [IknowType7IsBad]
!
radius server ISE-SERVER-2
  address ipv4 10.10.10.22 auth-port 1812 acct-port 1813
  key 7 [IknowType7IsBad]
!
radius server ISE-SERVER-3
  address ipv4 10.10.10.33 auth-port 1812 acct-port 1813
  key 7 [IknowType7IsBad]
!
radius-server vsa send accounting
radius-server vsa send authentication
!
!
+--------------+
|   Open ACL   |
+--------------+
!
ip access-list extended ACL-ALLOW
 10 permit ip any any
!
!
+----------------------+
|   Interface Config   |
+----------------------+
!
! This config is put on each interface
!
switchport mode access
switchport access vlan 10  ! Data VLAN
switchport voice vlan 20  ! Voice VLAN
spanning-tree portfast
spanning-tree guard root
no mdix auto
!
ip access-group ACL-ALLOW in  ! Pre-auth ACL to allow all traffic by default
!
authentication event fail action next-method
authentication event server dead action authorize voice
authentication event server alive action reinitialize
authentication host-mode multi-auth
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication periodic
authentication timer reauthenticate server
authentication violation restrict
mab
dot1x pae authenticator
dot1x timeout tx-period 10
authentication event server dead action authorize vlan 10  ! Authorize Data VLAN if AAA unavailable
!
authentication open  ! Apply open authentication
!
dot1x max-reauth-req 1
!
!
!
+--------------------------------------------------+
|   Helper IP addresses (to put on L3 interface)   |
+--------------------------------------------------+
!
ip helper-address 10.10.10.11  ! ISE Server 1
ip helper-address 10.10.10.22  ! ISE Server 2
ip helper-address 10.10.10.33  ! ISE Server 3

To try and research this, I've read through these forum posts on NAC and Monitor Mode:

https://community.cisco.com/t5/network-access-control/monitor-mode-pre-requisite-in-ise-and-switch-will-configuring/td-p/3932823

https://community.cisco.com/t5/network-access-control/nac-open-authentication-query/td-p/4138606

I've also read through the below ISE guide section Configure the Switch for Monitor Mode :

https://community.cisco.com/t5/security-knowledge-base/ise-secure-wired-access-prescriptive-deployment-guide/ta-p/3641515#toc-hId-1987655181

From reading that information, I have 3 questions:

It would seem that my "Unauthorized" scenario should not be restricting network access, as I have "authentication open" on the port, so even if my device is unauthorized, my pre-auth ACL-ALLOW should be allowing full network access per "authentication open", is that correct? Or is there some other config I need to apply or remove to make that happen?
For my "bad dACL" scenario, where the device is authorized but our ISE instance applies a generic restrictive dACL to the port, is there any config I could apply to the port to maintain true "Monitor Mode" such that the switch will ignore any dACL pushed down by ISE?
Do I need IP Device Tracking on my access ports for Monitor Mode to work?

0xD2A6762E

Rob Ingram · ‎11-06-2023

@vv0bbLeS

In monitor mode with "authentication open" configured if authentication fails, then the endpoint should still have network access.

If you want to deploy monitor mode you would not push down a DACL.

Device tracking maintains a database of IP and MAC addresses and is required when using DACLs amongst other features such as device sensor for profiling.

View solution in original post

Arne Bier · ‎11-07-2023

Hi,

I agree with @Rob Ingram. In general we don't push a dACL for a session on a switch that is deemed to be in Monitor Mode.

The reason I do it regardless, is due to Layer 8 problems Let me explain.

First of all, applying a fully permissive (permit ip any any) dACL to a session where the switch interface is configured for Monitor mode, has no negative impact. The result is still permit ip any any

Assuming your ISE Policy Set is ready for Low Impact Mode, the move from Monitor Mode to Low Impact Mode usually involves these changes:

You apply a standard interface ingress ACL on the relevant switch interfaces. The is the ACL that gives an unauthorized endpoint the bare minimum access (e.g. DNS, ICMP, DHCP, whatever).
You change the ISE Network Device from "Monitor Mode" to "Low Impact Mode" (can be done in various ways, but let's say you're using Device Type for that purpose) - this tells ISE to treat the switch (or entire switch stack) like a Low Impact switch.
Bounce the interface. This causes the session to be re-started for that interface and endpoint should be processed by ISE Low Impact Mode logic

This process is fairly simple. The reason that I push "permit ip any any" dACL even during Monitor Mode, is that it could happen that someone configured an interface with a pre-auth ACL on a switch that is not yet supposed to be in Low Impact Mode - finger trouble, etc. By applying the "permit ip any any" during the Monitor Mode, you will squash that problem.

it's not much overhead to add this daCL to the Authorization Profile.

I have a naming convention that I use in my Authorization Profiles that indicates Auth Method, NAC Mode and the device type - e.g.

MAB MONITOR WAP (dACL = DACL_MONITOR_WAP)
MAB MONITOR PRINTER (dACL = DACL_MONITOR_PRINTER)

And then I clone those Profiles for the Low Impact Mode, and just change the dACL to something else (if needed) - but by default the "permit ip any any" is there in case you want to re-use it.

MAB LOWIMP WAP (dACL = DACL_LOWIMP_WAP)
MAB LOWIMP PRINTER (dACL = DACL_LOWIMP_PRINTER)

Duplicating these things makes it easy. And best of all, I can use this naming convention in my LiveLogs/Reports filters to find a needle in a haystack sometimes. Having meaningful dACL names is useful also as confirmation on the switch that you've applied the intended dACL.