topic Re: ise 3.3 Posture not changing quarantine VLAN after upgrade in Network Access Control

ise 3.3 Posture not changing quarantine VLAN after upgrade

vivarock12 — Wed, 29 Jan 2025 01:02:30 GMT

after an upgrade from 2.7 to 3.3 p4 im trying to do posture, and a PC that already in the database connects and gets to compliant but for some reason is not changing the Quarantine vlan for the new one.

The authorization rule sets a DACL and a new vlan(non quarentine vlan).

if i run a show authent sess int gix/x/x de i can see that the DACL is getting assined on the SW(and on the ise radius logs too), but for some reasong the vlan wont change.

any idea why that migth happend?

here a config of the port at the moment were using authentication open. and the port its un trunk because of a phone that dont support voice vlan.

thanks for the help

Re: ise 3.3 Posture not changing quarantine VLAN after upgrade

Rob Ingram — Sat, 25 Jan 2025 12:14:51 GMT

@vivarock12 which VLAN ID are you expecting the quarantined user to be placed in to? The command "authentication event server dead action authorize vlan 1244" will only apply if the RADIUS server is dead, it is not used for quarantine if thats what you were thinking.

If you want to quarantine the endpoint in a different VLAN, then use dynamic VLAN assignment. Dynamic VLAN example - https://integratingit.wordpress.com/2018/05/07/configuring-cisco-ise-dynamic-vlan-assignment/

Or just apply a DACL and restrict what the quarantined device can actually communication with.

Re: ise 3.3 Posture not changing quarantine VLAN after upgrade

vivarock12 — Sat, 25 Jan 2025 12:27:26 GMT

The quarantine vlan should be the 44 and passing to vlan 128 after the compliant is completed but is not assigning the vlan 128 after the posture is compliant.

Re: ise 3.3 Posture not changing quarantine VLAN after upgrade

Rob Ingram — Sat, 25 Jan 2025 12:35:15 GMT

@vivarock12 Please provide a screenshot of your relevant ISE configuration that assigns the VLAN.

Is CoA setup correctly on the switch?

Provide the output of "show authentication session interface gig 1/0/41 detail" after the device is posture compliant.

Re: ise 3.3 Posture not changing quarantine VLAN after upgrade

Aref Alsouqi — Sat, 25 Jan 2025 13:52:05 GMT

You seem to be using VLAN 44 for voice instead of as your data quarantine VLAN. But regardless of this, if you have VLAN 128 configured in the authorization profile that is associated to the Compliant authorization rule in ISE it should work. As @Rob Ingram suggested, please share some screenshots of ISE authorization rules and authorization profiles and also ISE live log for that session for review.

Re: ise 3.3 Posture not changing quarantine VLAN after upgrade

vivarock12 — Sat, 25 Jan 2025 22:55:32 GMT

sorry for the late reply:
the policy rule
!

it matches the wired 802.1x authentication profile

!
!

this is the authorization rule it matches, as you canse it al ready is compliant.

!
and the authorization result does this basicaly assing a new vlan.

from what i se the OA configure has expected, hers the sw config:

!
aaa group server radius ISE-Group-RAD
server name ISE-2
!
aaa group server tacacs+ ISE_GROUP-TACA
server name ISE-2
!
aaa authentication login default none
aaa authentication login VTY group radius local
aaa authentication login AAA group ISE_GROUP-TACA local
aaa authentication enable default group ISE_GROUP-TACA enable
aaa authentication dot1x default group ISE-Group-RAD
aaa authorization config-commands
aaa authorization exec default none
aaa authorization exec VTY group radius local
aaa authorization exec AAA group ISE_GROUP-TACA local
aaa authorization commands 0 AAA group ISE_GROUP-TACA local
aaa authorization commands 1 AAA group ISE_GROUP-TACA local
aaa authorization commands 15 AAA group ISE_GROUP-TACA local
aaa authorization network default group ISE-Group-RAD
aaa accounting dot1x ISE start-stop group ISE-Group-RAD
aaa accounting exec default start-stop group ISE_GROUP-TACA
aaa accounting commands 1 default start-stop group ISE_GROUP-TACA
aaa accounting commands 15 default start-stop group ISE_GROUP-TACA
!
!
aaa server radius dynamic-author
client 192.168.252.242 server-key 7 SD2174QW3ASDF4603A256SD5F4333455C5C540F656E
!
interface GigabitEthernet1/0/2
switchport trunk allowed vlan 44
switchport mode access
switchport voice vlan 44
device-tracking
ip access-group PreAuth-ACL in
authentication event fail action next-method
authentication event server dead action authorize vlan 1244
authentication event server alive action reinitialize
authentication host-mode multi-domain
authentication open
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication violation replace
mab
snmp trap mac-notification change added
snmp trap mac-notification change removed
dot1x pae authenticator
spanning-tree portfast
spanning-tree bpduguard enable
!
!

ip access-list extended PreAuth-ACL
10 permit udp any any eq domain
20 permit udp any eq bootpc any eq bootps
30 permit tcp any host 192.168.252.241
40 permit tcp any host 192.168.252.242
50 deny ip any any
!

tacacs server ISE-1
address ipv4 192.168.252.241
key 7 13546ASD65F6H656SD321FSD986421SDFWEFD21
tacacs server ISE-2
address ipv4 192.168.252.242
key 7 54547321SDFSD75SD1FSD79WE231SDF879465SDF
!
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 ISE-1
address ipv4 192.168.252.241 auth-port 1645 acct-port 1646
key 7 698749321ASDAFASDFG87ADF2GDF46D5F4GSD32F41SD3F5
!
radius server ISE-2
address ipv4 192.168.252.242 auth-port 1645 acct-port 1646
key 7 546ASDD5A3S2D1DFS75A65AS564G65F46321DF698D321AS
!
!

Re: ise 3.3 Posture not changing quarantine VLAN after upgrade

Rob Ingram — Sat, 25 Jan 2025 23:33:03 GMT

@vivarock12 in your Authorisation Profile you have set the VLAN as 410, but you said the VLAN should be 128. So if you send the wrong VLAN ID which does not exist on the switch, it won't work.

FYI, You could use a name instead of the ID numbers, the same name could be used over multiple switches but with a different ID number. That makes it more scalable.

Provide the output of "show authentication session interface gig 1/0/41 detail" if you still have a problem.

Re: ise 3.3 Posture not changing quarantine VLAN after upgrade

vivarock12 — Sun, 26 Jan 2025 01:33:22 GMT

Sorry I mistaken the vlan before, tomorrow where going back to the site I'll upload the command as fast as possible, but it looks like the ise is not sending the coa to the switch.

Re: ise 3.3 Posture not changing quarantine VLAN after upgrade

Aref Alsouqi — Sun, 26 Jan 2025 12:19:12 GMT

Also you seem to have the CoA configured on the switch only for ISE2 but not for ISE1. You should add the CoA for ISE1 as well via the command:

aaa server radius dynamic-author
client 192.168.252.241 server-key < your RADIUS key >

Re: ise 3.3 Posture not changing quarantine VLAN after upgrade

vivarock12 — Sun, 26 Jan 2025 12:38:22 GMT

I have only upgraded the ise 2 were doing a backup restore method.

ISE 1 is working in it's previous version still.

Saying that should I change the ACL on the port?
And should I check the client provisioning portal?

I was wondering if that might be the reason.

Re: ise 3.3 Posture not changing quarantine VLAN after upgrade

Rob Ingram — Sun, 26 Jan 2025 12:51:00 GMT

@vivarock12 please provide the output of "show authentication session interface gig 1/0/41 detail" - from after the user is posture compliant.

Enable debug radius on the switch, authenticate and observe the output when the user is compliant, you should see Tunnel-Private-Group (amongst others) being sent to the switch, this will tell you if the VLAN is received by the switch. If it does not, have you confirmed in the actual ISE Live Logs the user is matching the correct rule?

I assume the VLAN is actually created on the switch already?

Re: ise 3.3 Posture not changing quarantine VLAN after upgrade

Aref Alsouqi — Sun, 26 Jan 2025 13:26:44 GMT

Oh I see, thanks for clarifying that. The ACL on the port is not involved in the traffic between ISE and the switch, nor the client provisioning portal. The ACL on the port allows the connected clients to get an IP, send DNS queries, and connect to ISE on any TCP port. The client provisioning portal would be used only if the clients do not have the posture module and they need to download it from the portal.

However, what we are trying to understnad here is if ISE is actually returning the right attribute to the switch, and if the switch receives it. If you believe your authorization profile is configured with the wrong VLAN 410 and that needs to be adjusted to VLAN 128, then that would most likely be the issue. If not I would go with what @Rob Ingram suggested, RADIUS debug should show us what attributes ISE send back to the switch and then will take it from there.

Re: ise 3.3 Posture not changing quarantine VLAN after upgrade

vivarock12 — Mon, 27 Jan 2025 18:57:05 GMT

SORRY FOR THE LATE REPLY.
rigth now were with a case with cisco and yes we have determine that for some reason the pc wont feel, see, or determine that the switch change the vlan has a hole and becasuse of that it doesnt do a new DHCP request or for the new ip address apparently.

so that were we are now and were trying to change parameter on the AnyConnect Posture Profile to double check if that migth be the solution becasue we do double vlan change from a quarentine vlan (when the device in unknow) to a production vlan (whe the device posture is compliant).

any other ideas?

ill be updating in any case.

Re: ise 3.3 Posture not changing quarantine VLAN after upgrade

Rob Ingram — Mon, 27 Jan 2025 19:11:19 GMT

@vivarock12 changing the VLAN of a device after a device already has an IP address can cause issues with clients not requesting an IP address. I generally avoid changing VLAN, applying a DACL to a non-compliant device to restrict access would be better.

Again, please provide the output of "show authentication session interface gig 1/0/41 detail" - from after the user is posture compliant. The output would confirm whether the switch has or has not received the new VLAN, which might indicate to us the client has not requested the new IP address.

Did you run the debug as suggested above? ....does that confirms the VLAN is sent to the endpoint. Provide the output

You may have done this with TAC already, but this is not TAC so we cannot assist if you don't provide us with the outputs to figure out where the problem is.

Re: ise 3.3 Posture not changing quarantine VLAN after upgrade

vivarock12 — Wed, 29 Jan 2025 01:07:42 GMT

here the capture of the show authentication sessions.

the detination vlan es the 410 sorry for the confusion wiith the 128 that the netwrok third prefix.

and here are the logs. just add them at the end.

the and a PCAP with span is avaiable if you want me to shared with you.

sorry for the late reply again.

Re: ise 3.3 Posture not changing quarantine VLAN after upgrade

Rob Ingram — Mon, 27 Jan 2025 21:07:10 GMT

@vivarock12 did you not include all the logs in the output? I can see the VLAN assigned to VLAN 1244, not VLAN 410. By the looks of the output above I can see that ISE has sent VLAN 410 during authorisation.

The logs do confirm that VLAN 1244 is being sent and works during the posture unknown phase (as per output below)?

hp_acc_p100o_192_168_91_36#sh authentication sessions interface gi1/0/1 details 
Interface: GigabitEthernet1/0/1
MAC Address: c018.0389.e5ac
IPv6 Address: Unknown
IPv4 Address: 192.168.144.33
User-Name: rvalencia
Status: Authorized
Domain: DATA
Oper host mode: multi-domain
Oper control dir: both
Session timeout: N/A
Restart timeout: N/A
Periodic Acct timeout: N/A
Session Uptime: 496s
Common Session ID: C0A85B2400000041042B14D9
Acct Session ID: 0x00000161
Handle: 0x34000024
Current Policy: POLICY_Gi1/0/1

Local Policies:
Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)

Server Policies:
Vlan Group: Vlan: 1244
URL Redirect: https://ma-srv-ise2.cableonda.interno:8443/portal/gateway?sessionId=C0A85B2400000041042B14D9&portal=58055550-d262-11e4-9c2b-005056b15681&action=cpp&token=f4c8fc0a793b499e1097b2700c27d7e2
URL Redirect ACL: ACL_Unknown_Redirect

So the issue is not that ISE is not sending the VLANs, nor the switch applying the correct VLAN to the session, but the client is not getting an IP address in VLAN 410?

Does VLAN 410 work with NAC applied?

Again, I wouldn't recommend changing VLANs, but use a DACL to restrict access.

Re: ise 3.3 Posture not changing quarantine VLAN after upgrade

vivarock12 — Mon, 27 Jan 2025 21:27:17 GMT

yes the issue is that after the ISE applies the configuration to the switch and the switch applies the config to the port the PC makes a new DHCP request (suppostly) but gets the same ip address from the curantine vlan 1244, not the one from vlan 410

Again, I wouldn't recommend changing VLANs, but use a DACL to restrict access. yes im with you in this but the deployment was working like that on 2.6 but after the upgrade to 3.3 and we are working anymore, that why we were trying to solve that problem. after that the direction is disable this double vlan.

Re: ise 3.3 Posture not changing quarantine VLAN after upgrade

Aref Alsouqi — Tue, 28 Jan 2025 09:29:32 GMT

It does seem that the client don't even try to get a new IP address for some reason. This behaviour is expected with MAB authentications, not with dot1x. With dot1x the supplicant should take care of triggering the whole authentication process. One thing you might try to do to workaround this is to place the switch port in the quarantine VLAN (1244), not to change it during the unknown phase, and then you only apply VLAN (410) for the compliant authorization rule. That way the switch port pre authentication will already be in the quarantine VLAN and will remain into that VLAN until the client pass the posture check.

Re: ise 3.3 Posture not changing quarantine VLAN after upgrade

vivarock12 — Wed, 29 Jan 2025 01:01:09 GMT

ok guy just to update you, the thing is wokring rigth now, how i have doubts but we have determine whats making it work.
!

por configuration

VLANs

The port configuration is access on vlan 1, vlan 1 does not give any DHCP ipaddres.

Quarentine vlan is 1244, dhcp addressing

Compliant vlan is 410. reserved DHCP addressing

So the flow would be PC Connects to the network > eap validates the 802.1x, on vlan 1 >

posture starts and puts you on unknow, and gives you the vlan 1244, till the posture result is define (at that point the PC should do a DHCP DORA and get and DHCP ip address) >

If the ise determine that you were POSTURE COMPLIANT, ISE send the switch a DACL and the vlan 410 (at that point the PC should do a DHCP DORA and get and DHCP reserved ip address, and the switch port shows that the correct vlan was already in the port).

image of the last part ^

the trouble was that on the last part the ISE determine that the device was Compliant and send to the switch the respective DACL and the vlan, but the pc dindt start a DHCP DORA process and stuck with the ip addressing of the quarentine vlan(1244).

if we did a reselection of the network on the NAM module of the anyconnect, the pc begings with the DHCP DORA and got and ip address of the posture compliant vlan (410), if we dindt do that the pc would remain stuck on quarentine vlan.

!
!
!
here the strange part>

If we created and interface vlan of the quarentine vlan (1244) on the authenticator SW, the process would automaticly put the pc on the Posture vlan (410) without any reason, the pc just does the DHCP DORA and get the reserved ip address.
if the interface vlan was turned off, the nam reselection was the only solution.

so basically

It Just Works

!
!
firstime seeing thing, i think that itr migth have something to do why the Posture agent profile part and that interface vlan i permiting the vlan validation, for the posture module and making it try againg, not sure but just for you guys to know the conclusion.
!
@Aref Alsouqi
@Rob Ingram

thanks the both of you.

Re: ise 3.3 Posture not changing quarantine VLAN after upgrade

Aref Alsouqi — Mon, 03 Feb 2025 14:37:11 GMT

You're welcome. I think the issue here is that the client for some reason doesn't go through DORA process again, and as you're using NAM I would recommend looking at NAM profile to see if there is any setting that would prevent that from happening.