Original Message:
Sent: 01-16-2025 07:26
From: Sheetanshu
Subject: VoIP-VLAN Validation Failed
Hi Muhammad,
It's great that it is working. But, this is not exactly how it should be configured in the scenario where you are expected to get the VLAN from the RADIUS dynamically. Here, it works because the VoIP VLAN is statically set on the port-profile and in single supplicant mode (default config), the phone would not even be authenticated by the NAC if the PC is already authenticated on the port.
- If the PC and the IP Phone are connected to the same port, the port profile assigned to the PC+Phone connected port is needed with MAB and multiple supplicant option enabled. The data and the port VLAN configured on this port-profile is significant, if we expect the NAC to return the VLAN values after port authentication.
- The VLAN auth policy label will define the data VLAN on the switch port using the Tunnel-Private-Group-ID RADIUS Attribute.
- The customer vendor specific auth policy label would return the "Juniper-VoIP-Vlan" attribute to define the VoIP vlan on the port.
Regards
------------------------------
Sheetanshu Shekhar
Original Message:
Sent: 01-16-2025 05:52
From: MUHAMMAD SAAD
Subject: VoIP-VLAN Validation Failed
Hi Sheetanshu Shekhar,
The issue has been resolved. Basically on source mgmt nac profile and other data services profile, only data vlan is called and voip network is set to none.
Similarly for IP-Phones profile, VoIP Network VLAN is set to specific VLAN and data VLAN is set to none.
The issue gets resolved in this way and both devices (PC and IP-Phones) were able to get authenticated.
------------------------------
MUHAMMAD SAAD
Original Message:
Sent: 01-15-2025 10:21
From: Sheetanshu
Subject: VoIP-VLAN Validation Failed
Hi Muhammad,
The VLAN label returns the Tunnel-Private-Group-ID attribute which wouldn't work for VoIP VLAN. "Juniper-VoIP-Vlan" attribute is needed for voip VLAN.
I would suggest the following: -
- Enable "multiple supplicant" option under the port profile associated with the port. This will allow the PC and the IP Phone to be authenticated separately. The default supplicant mode is Single, and thus would only authenticate the first supplicant.
- Create a new Auth Policy Label on Mist NAC. Set Label type as "AAA attribute" and Label Values as "Custom Vendor Specific Attributes" and Add attribute.
- Name the attribute as "Juniper-VoIP-Vlan" and value as the name of the voip VLAN.
- Create a separate Auth Policy rule for the IP Phones' MAC list to return the VSA label as a result of authentication action.
Regards
------------------------------
Sheetanshu Shekhar
Original Message:
Sent: 01-15-2025 01:15
From: MUHAMMAD SAAD
Subject: VoIP-VLAN Validation Failed
Hi Sheetanshu,
Please find below the auth policy rule and NAC event details:


We have done troubleshooting and perform some changes and after that the IP Phone is getting authenticated but its respective VLAN is showing at Data VLAN side rather for it to be showing on VoIP VLAN. Due to this issue, IP Phone is not getting the IP address.
Please let us know what minor changes needs to performed now in order for IP Phone to get the IP address.
I am attaching some snaps of the output results.
------------------------------
MUHAMMAD SAAD
Original Message:
Sent: 01-14-2025 14:07
From: Sheetanshu
Subject: VoIP-VLAN Validation Failed
Hi Muhammad,
- Can you also share the Auth policy rule configured on the Mist NAC for the matching MAC address of the phone?
- A search with the MAC address on the "Show NAC Events" option on Mist Auth Policies will also show some insight, if it hit a matching rule.
- Can you also share the output of "show dot1x interface <> detail" of the port that is in the held state?
Regards
------------------------------
Sheetanshu Shekhar
Original Message:
Sent: 01-13-2025 07:03
From: MUHAMMAD SAAD
Subject: VoIP-VLAN Validation Failed
Hello Team,
I am also facing the same issue here that VOIP-Validation failed. I am using a Juniper EX2300 switch and using Mist Auth as an authentication server.
We have connected a PC and IP Phone from same port. The user gets connected via 802.1X authentication with dynamic vlan assignment, but IP Phone is going on connecting and held state again an again. I am sharing some snaps of my configuration.
Kindly some one help and provide the solution.


------------------------------
MUHAMMAD SAAD
Original Message:
Sent: 06-04-2024 07:48
From: ASHTON REYNOLDS
Subject: VoIP-VLAN Validation Failed
Good morning,
We are using "set switch-options voip interface" when i removed the switch options it worked! Our phones authenticate again. Super weird as i removed this option before and had no luck. Thank you for all the help!
------------------------------
ASHTON REYNOLDS
Original Message:
Sent: 06-03-2024 13:14
From: Mark Anthony Yeates
Subject: VoIP-VLAN Validation Failed
Ashton,
Are you also statically configuring your VoIP VLAN using the "set switch-options voip interface" command? If so, can you temporarily deactivate and see if the phone will go in the proper VLAN?
If this doesn't help, can you post the VSAs you are pushing from your RADIUS server?
Thanks,
Mark
------------------------------
Mark Anthony Yeates
Original Message:
Sent: 06-03-2024 08:43
From: ASHTON REYNOLDS
Subject: VoIP-VLAN Validation Failed
Good morning,
I went into different logs and watched the authentication process. It reports that it looses responses from the phone and deems is a failed authentication and puts it in "held". We are currently switching our RADIUS server from ISE to Forescout. Both Radius servers do not make a difference regarding the issue. I also see in the logs our Radius server is responding and dynamically assigning our Voice vlan. Our voice vlan and data vlan are completely separated. This is using Mac-radius. Please see below regarding the logs i found and thank you for the response and help!
Received VLAN ID/name Voice_Vlan from authentication server
May 30 19:34:54.772306 Vlan received from radius is configured as static voip-vlan
May 30 19:34:54.772340 Config retries adjusted to 3
May 30 19:34:54.772369 Error in parsing client attributes.
May 30 19:34:54.772417 Error response from authentication client. authd reply code 1 for mac 24:d9:21:4d:de:2e on port 558Message not processed further
May 30 19:34:54.772464 AuthSession node with Mac: 24d9214d-de2e in port session AIP DB found !!!
May 30 19:34:54.774358 BSM moved to state: FAIL !!
May 30 19:34:54.774408 BSM moved to state: IDLE !!
May 30 19:34:54.774475 ASM Called with Event: BKEND_AUTHFAIL in State: Authenticating for Port:558 MAC: 24:d9:21:4d:de:2e Id: 2
May 30 19:34:54.774534 PnacAuthAsmMakeHeld Session 24:d9:21:4d:de:2e Authentication mode: Mac-Radius
May 30 19:34:54.774582 Current authentication mode: Mac-Radius Next authentication mode: Mac-Radius
May 30 19:34:54.774622 Session: 24:d9:21:4d:de:2e previous authentication mode: Mac-Radius current authentication mode: Mac-Radius
May 30 19:34:54.774674 TMR: Quiet While Timer Started for port:558, Duration: 60 !!
May 30 19:34:54.774733 TMR: Timer 4 is started for port 558 duration 60
May 30 19:34:54.774788 ASM moved to state: HELD for Port:558 MAC:24:d9:21:4d:de:2e
------------------------------
ASHTON REYNOLDS
Original Message:
Sent: 05-31-2024 14:42
From: Mark Anthony Yeates
Subject: VoIP-VLAN Validation Failed
Ashton,
Try using the Juniper-VoIP-VLAN VSA in your RADIUS attributes in ISE. Here is an example on how to configure it.
https://www.juniper.net/documentation/us/en/software/nce/nce-213_ex_and_cisco_ise/topics/topic-map/nce-213-ex-series-switch-cisco-ise.html
I believe there was a change between 21 and 22 that is forcing the use of the VSA. Unfortunately, this is not documented and I am putting in a doc PR to get the documentation updated.
Hope this helps.
Thanks,
Mark
------------------------------
Mark Anthony Yeates
Original Message:
Sent: 05-28-2024 08:08
From: ASHTON REYNOLDS
Subject: VoIP-VLAN Validation Failed
Good morning,
We are working on getting our EX3400 switches from 20.4R3-S3.4 to 22.4R3.25. Everything was a working except our Avaya phones are being in a held or connecting state after the upgrade. We noticed when we go to any version of 22 we have this issue. They were authenticating fine before the upgrade, we cannot figure out the problem we see the switch never sends any requests for authentication to the radius server on Wireshark. We run the command show dot1x interface ge-0/0/12 detail and see: Operational state: Held | Held state Reason: VoIP-VLAN validation failed. Any ideas on why a firmware upgrade causes this? We looking all over the internet and we only found server-fail-voip being everyone's problem but unfortunately we do not use that command altogether. Any ideas will be greatly appreciated!
What we use: ex3400 20.4R3-S3.4 to 22.4R3.25. |Phones: Avaya 9611G authenticating with MAB | RADIUS Server: CISCO ISE
------------------------------
ASHTON REYNOLDS
------------------------------