ise 3.3 Posture not changing quarantine VLAN after upgrade

[vivarock12]

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

[Rob Ingram]

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

[vivarock12]

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.

[Rob Ingram]

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

[Aref Alsouqi]

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.

[vivarock12]

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
!
!

[Rob Ingram]

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

[vivarock12]

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.

[Rob Ingram]

@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?

[Aref Alsouqi]

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 >

[vivarock12]

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.

[Aref Alsouqi]

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.

[vivarock12]

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.

[Rob Ingram]

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

[vivarock12]

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.