NAP 802.1x, VLAN changes but client does not release / renew address RRS feed

  • Question

  • I am having a problem on Vista (release -- no SP1)  with NAP and 802.1x enforcement.  The VLAN is changing on the switch via the Radius attributes for tunnel type (13 - VLAN), tunnel medium (6 - 802) and tunnel private group ID (VLAN ID)and I can see that the change indeed took place on the switch, however the DHCP client never releases the old address and requests a new one.  If I do this manually then the correct address is received.


    Does the 802.1x enforcement client keep track of the assigned VLAN ID and if so -- shouldn't it be triggering a release / renew operation when it sees this change?


    Is there some configuration I am missing here?

    Thursday, January 10, 2008 6:40 PM


All replies

  • Hi Mike


    The DHCP Server will pick the correct scope based on the GIADDR field in the DHCP packet. Based on the (non-zero) value of the GIADDR field, the client should send a message to the DHCP server via the relay agent requesting a new IP address when it re-authenticates on the new VLAN.


    I assume you have IP helpers configured correctly on each VLAN since you get the correct address when you release/renew. Something you might want to try is disabling fast reconnect and see if this helps. Right-click Local Area Connection, click Properties, Authentication tab, click Settings. In the Protected EAP Properties dialog box, clear the Enable Fast Reconnect check box.


    Let me know if this helps.


    If not, please post the build numbers of Server 2008 and Vista you are using, and the type of switch.






    Friday, January 11, 2008 4:26 PM
  • Hi Greg,


    The switch is a Nortel 5510-24T


    The DHCP server has interfaces on each VLAN so it will determine the address pool based on the subnet the request originated from -- this works fine with manual release/renew.


    The client is Windows Vista Business build 6000 ( with automatic updates applied )

    The DHCP server is Windows Server 2008 build 6001


    I tried disabling the fast reconnect but it did not seem to change the behavior.


    There are some other details that I cannot share in a public forum -- please contact me via e-mail (remove the "nospam-")




    Thanks for your help,




    Friday, January 11, 2008 5:10 PM
  • Hi Mike,


    I'll email you and hopefully we can come up with a solution offline.



    Friday, January 11, 2008 5:16 PM
  • Greg,


    Was this resolved? I'm having the same problem but with a Cisco 1200 Wireless Access Point.





    Thursday, January 17, 2008 12:07 AM
  • Hi,


    The next step is to examine event logs from the DHCP and/or NPS server. On the surface, this seems like it may be a DHCP issue with Vista as it isn't being reproduced on XP.


    Please let me know if there is anything suspicious in the event logs.




    Thursday, January 17, 2008 12:28 AM
  • Greg,


    Thanks for the quick response.


    And yes it is only a Vista issue, just carried out the same tests on XP and it works as it should, i.e. it automatically refreshes the VLan to the quarantine one.





    Thursday, January 17, 2008 12:38 AM
  • Hi,


    I'm not sure if this will fix the issue, but I did find the following knowledge base article about DHCP in Vista. Are you using a Microsoft DHCP server?





    Thursday, January 17, 2008 12:47 AM
  • I am having the same problem with nortel switch and NAC. İs this a DHCP issue ?
    Wednesday, October 8, 2008 11:39 AM
  • rafetilgin said:

    I am having the same problem with nortel switch and NAC. İs this a DHCP issue ?

    Also I am using windows server 2003 server for DHCP.
    Wednesday, October 8, 2008 11:40 AM
    Greg Lindsay said:



    I'm not sure if this will fix the issue, but I did find the following knowledge base article about DHCP in Vista. Are you using a Microsoft DHCP server?





    Hello folks, we've had a similar situation (excuse me for not reading all the posts) - but since the subject may atract others with similar issues, let me share our findings on another situation with the same symptoms.

    DHCP not being renewed while switching VLANS under 802.1x and NAP, typically from a remedation zone to an internal zone or vica versa.

    * NAP enabled clients (XP SP3, or Vista)
    * 802.1x NAP and VLAn switching, 3 zones (Guest/Default, Remediation, ImNternal)
    * DHCP served from a single DHCP server for all 3 zones
    * Access points with DHCP proxy (or other similar mechanism serving DHCP proxy services)

    Issue at hand:
    * When health state is changed, VLAN happens as expected  - while DHCP is not renewed.

    What we discovered under this specific circumstance was that the DHCP proxy always communicated "on behalf of the client" to the DHCP server.
    A DHCP NAK never occured while we used the proxy function on the cisco access point.
    When we turned off the proxy functionality, so that the access point forwarded the request from the client - a DHCP NAK occured.

    The differeantiator was the initial DHCP NAK package - which told the client to do a "DHCP Discovery" instead of sticking with 3 "DHCP Request".

    (Excuse me - Im typing Package Trace from Wireshark from my memory - it might be a bit off)
    More clearly - unwanted behavior, when Health state changed:
    * Client: DHCP Request
    * Client: DHCP Request
    * Client: DHCP Request
    * (No answer, the client starts assuming Auto Assigned IP - it might get a 169.254 adress)
    * DHCP ACK - the server responds "OK, keep that address, I know you - and there's no reason to change address"

    The client keeps the original address
    When turning off the DHP proxy service on the access point - we noticed that the "DHCP server" address on the clienty changed from the proxy address to the true DHCP address.
    And the packet exchange was more like this:
    * Client: DHCP Request
    * Client: DHCP Request
    * DHcp Server: DHCP NAK (your're no longer in the correct scope).
    * Client: DHCp Discovery
    * Server: DHCP Offer

    The DHCP proxy might have been seen as the requestor - and it was still on the same VLAN (no need for the access point to change scope/vlan). Hence the DHCP server might have falsly assumed that there were no real need to reevaluate which address/lease the "client" (the proxy) was looking for.
    Well, some sort of defect must have affected this. I assume it is either by design (for the DHCP servers) or a Cisco defect.

    When the proxy was turned of, and forwarding took over - the request was forwarded in a manner that the DHCP server could detect the change.

    Please excuse me - but I have not done any study of the DHCP request exchange, so my assumptions may be off quite a bit.
    However - if you do have some sort of DHCP proxy / forwarders - try to change the bahavior, use a packet sniffing tool and inspect the packets so ou can see who's truly sending the DHCP Requests. :)

    There's no such issues if you do use a different DHCP server for each scope - since the "other" DHCP server doesn't know about the "previous/old" DHCP scope that the client is trying to "keep". Hence a DHCP NAK occurs imediatly, without further delay.
    So if you look for a simple solution - use 3 different DHCP servers (if you have that many) - one for each VLAN. You'll get the DHCP NAK, and the change to the correct VLAN should happen pretty quickly.

    Sincerly, Jon E. Carlsen
    • Edited by Jon E. Carlsen Saturday, October 11, 2008 12:56 AM Different DHCP servers addendum
    Saturday, October 11, 2008 12:53 AM
  • Hello,

    We are having the same issues deploying our new 802.1x wireless solution.

    Our Symptom:
    DHCP not being renewed when switching VLANs after authenicating from one role to another. IP release and renew will obtain the correct IP.

    Aruba 6000 Wireless Controller
    AP 70 Thin APs
    Windows XP SP3 Clients
    DHCP served from two windows DHCP servers with split scopes.
    I am not sure if our issue is related to http://support.microsoft.com/kb/928233  because we are not running Vista or SP2.

    Monday, December 29, 2008 9:29 PM
  • Hello All,

    I'm not having any luck in the XPSP3 thread so hopefully someone here can help.

    This behaviour is happening on XPSP2 with eapol supplicant reg settings also

    To reiterate:
    Client starts in VLAN B
    Client dhcp VLAN B = ok (172.x)
    Client auth EAP-TLS = success (switch port changes to VLAN A)
    Client dhcp VLAN A = doesn't happen (stuck with 172.x should be 10.x)
    Client group policy/logoin etc. fail = no domain controller visible.

    if i login with local credentials, ipconfig /renew  = it gets the correct IP address.

    I've tried http://support.microsoft.com/kb/928233
    ..even scrapped the DHCP-Helper on "VLAN B" out of desperation (even though the 2K3R2 DHCP server lives in VLAN A) and replaced it with a standalone DHCP server.

    • Proposed as answer by chememar Monday, January 18, 2010 2:39 PM
    Friday, March 6, 2009 2:31 AM
  • Hi all,
    I have the same problem and in my opinion one solution could be force a dhcp discovery reacting to an EAP-success message. When you implement the 802.1x standard on the switch all the possible scenarios terminate with an EAP-success message even if the authentication fails and the client is authorized in failed-vlan.

    Did someone find any solution for the problem?

    I’m running Window$ XP sp3.




    Monday, January 18, 2010 2:45 PM
  • Does anybody know how to solve this issue in windows 7?
    Thursday, September 23, 2010 2:17 PM
  • You can carefully try to construct a balanced 802.1x environment using 802.1x timeout values on the switch.
    The sample below is intended to allow for PXE network boot to access the 'default VLAN' while Windows should have enough time to start up and authenticate for internal VLAN.

    There are several factors for success:
    1. Switch configuration, timing
    2. 802.1x GPO configuration values
    3. Removing the auth-failure block-timer in Windows.

    Here's a sample config we use for Cisco, remember to read the config and replace values where needed:

    Per switch:
    aaa new-model
    aaa authentication dot1x default group radius
    aaa authorization network default group radius
    dot1x system-auth-control
    radius-server host <RADIUS-ip> auth-port 1812 acct-port 1813
    radius-server key <PAssword>
    dot1x guest-vlan supplicant
    errdisable recovery cause udld
    errdisable recovery cause bpduguard
    errdisable recovery cause security-violation
    errdisable recovery cause dhcp-rate-limit
    errdisable recovery cause storm-control
    errdisable recovery interval 1800
    mac address-table notification change
    mac address-table notification mac-move
    ip tcp synwait-time 10
    ip tcp path-mtu-discovery
    ip ssh version 2

    Per if-port:
    interface FastEthernet0/6
     description <descr>
     switchport mode access
     switchport nonegotiate
     switchport block multicast
     switchport port-security
     switchport port-security violation restrict
     no logging event link-status
     dot1x pae authenticator
     dot1x port-control auto
     dot1x timeout tx-period 10
     dot1x reauthentication
     dot1x critical recovery action reinitialize
     dot1x guest-vlan <VLAN_ID>
     dot1x auth-fail vlan <VLAN_ID>
     dot1x auth-fail max-attempts 1
     dot1x critical vlan <VLAN_ID>
     storm-control broadcast level 10.00 5.00
     storm-control multicast level 90.00 60.00
     storm-control unicast level 90.00 70.00
     spanning-tree portfast
     spanning-tree bpduguard enable
     ip dhcp snooping limit rate 3

    As for the 802.1x group policy settings, since we use 802.1x + NAP:
    Wired Profile, Security:
    - Auth method: Microsoft Protected EAP
    - Auth mode: Computer only.
    - Max failures: 3
    Advanced Security, Enforce advanced 802.1x settings
    - Max Eapol Start Msg: 3
    - Held Period: 1 sec
    - Start Period: 5 Secs
    - Auth Period: 20 secs
    Eapol-Start Message: Transmit per IEEE 802.1x

    Lastly, the settings for the blocktimer:

    I hope you are able to get a balanced startup for your clients. Good luck. :)


    Sincerly, Jon E. Carlsen
    Thursday, September 23, 2010 7:39 PM