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

[vivarock12]

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.

[Aref Alsouqi]

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.

[vivarock12]

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.

[Aref Alsouqi]

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.