Avaya IP Phones block PC from getting authenticated and experienced one-way issue (ISE 2.1)

[ozy.djohan21]

Hi All,

We are currently migrating users from NAC to ISE and experienced an issue with Avaya IP Phones.

The Avaya IP phones is configured to be automatically profiled and allowed in VOICE domain using MAB while the PC gets authenticated by the ISE using 802.1x. On the PC, we use AnyConnect ISE Posture Module to do the posturing and AnyConnect Network Access Manager (NAM) to provide the 802.1x authentication.

We are authenticating the users against AD and in normal condition when the PC connects to the ISE for the first time, the NAM module would pop a small window for user to input their AD credential information and after that the ISE Posture modue would do the posturing properly.

We have no problem with the PC behind Cisco IP Phones. However when the PC is behind an Avaya IP Phone, the small pop-up window from NAM wouldn't show up and the PC couldn't get authenticated using 802.1x. The live logs on the ISE showed that the PC is authenticated using MAB and authorized with the default authorization policy (which we configured with explicit deny).

The Avaya IP Phone itself was authenticated, profiled, and authorized perfectly. However, when we tried to make a call with the phone, we experienced one-way problem. The Avaya phone could send voice and be heard by the user on the other end, but couldn't hear anything as a reply.

We tried to remove the Avaya phone and connect the PC directly to 802.1x enabled port and the PC was authenticated perfectly. The NAM module popped-up the small window and users were able to input their credential information.

Do we need to configure something on the phone? Any help would be very appreciated.

Thanks in advance,

Ozy

P.S. Here is our port configuration, we are using C4507R+E as the authenticator

ip access-group acl_default in
authentication event fail action next-method
authentication event server dead action reinitialize vlan X
authentication event server dead action authorize voice
authentication host-mode multi-auth
authentication open
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication periodic
authentication timer reauthenticate server
mab
dot1x pae authenticator

[Rahul Govindan]

Are you pushing any DACL for the Avaya phones after authorization or is it just Access-Accept and Voice Domain? Can you check the "show authentication session interface <> details" to see if this has been applied correctly? I would also run a "show ip access-list interface <>" post-authorization to confirm that this has taken effect.

Also, what is your default ACL on the interface? Is it a permit ip any any or does it have specific rules?

From the PC side, do you see it run through dot1x before falling into MAB? You can run a "debug dot1x all" to confirm this.

I have deployed a similar setup with Avaya Phones and Windows with Anyconnect NAM (EAP-chaining) and posture. I have not run into this issue before.

[ozy.djohan21]

Hi Rahul,

Yes, we are pushing a DACL to the phones to allow traffic for the voice segment. The "show auth session int detail" displayed that the voice got the correct DACL as shown below:

---------------------------------------------------------------------------

sh auth ses int gi7/3 d
Interface: GigabitEthernet7/3
MAC Address: XXXX.XXXX.XXX
IPv6 Address: Unknown
IPv4 Address: 10.x.x.x // correct IP address
User-Name: XX-XX-XX-XX-XX-XX // same as MAC address, should be AD cred
Status: Authorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: both
Session timeout: N/A
Restart timeout: N/A
Common Session ID: 0A15180400001C452FD1A200
Acct Session ID: 0x00017499
Handle: 0x5F000830
Current Policy: POLICY_Gi7/3

Local Policies:
Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)
Security Policy: Should Secure
Security Status: Link Unsecure

Server Policies:
ACS ACL: xACSACLx-IP-Deny_Default_ACL-584a630d

Method status list:
Method State

dot1x Stopped
mab Authc Success

----------------------------------------
Interface: GigabitEthernet7/3
MAC Address: XXXX.XXXX.XXX
IPv6 Address: Unknown
IPv4 Address: 172.x.x.x
User-Name: XX-XX-XX-XX-XX-XX
Status: Unauthorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: both
Session timeout: N/A
Restart timeout: N/A
Common Session ID: 0A15180400001C462FD1F728
Acct Session ID: 0x0001749A
Handle: 0x1C000831
Current Policy: POLICY_Gi7/3

Local Policies:
Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)
Security Policy: Should Secure
Security Status: Link Unsecure

Server Policies:
ACS ACL: xACSACLx-IP-acl_voice_traffic_avaya-583c0100

Method status list:
Method State

dot1x Stopped
mab Authc Success

-------------------------------------------------------------------------------------

As you can see above, the dot1x authentication had stopped for the PC and failing to MAB. I can't understand why the dot1x wouldn't run with Avaya connected while it worked like a charm when we connect the PC directly to the dot1x enabled port without Avaya in between.

As for the debug dot1x which you suggest, I couldn't do it because this is a customer's network and permission is difficult to get. I'll give it a try as soon as the permission to debug is granted.

Thanks for your suggestions,

Ozy

[ozy.djohan21]

*** UPDATE ***

The Avaya phone type which caused the issue is Avaya 4622SW IP Telephone. We tried to replace the phone with another type, in this case we use the Avaya 16161-I, and the dot1x authentication for the PC worked.

Is it possible that particular type of phone (4622SW) is blocking the dot1x? Is there any possible workaround to get the PC authenticated with dot1x while using the 4622SW phone?

[Peter Koltl]

Avaya IP telephones support three 802.1X operational modes. The operational mode can be changed by pressing “mute80219#” (“mute8021x”).

Pass-thru Mode – Unicast supplicant operation for the IP telephone itself, with PAE multicast pass-through for the attached PC, but without proxy Logoff (default).

Pass-thru with logoff Mode (p –t w/Logoff) – Unicast supplicant operation for the IP telephone itself, with PAE multicast pass-through and proxy Logoff for the attached PC. When the attached PC is physically disconnected from the IP telephone, the phone will send an EAPOL-Logoff for the attached PC.

Supplicant Mode – Unicast or multicast supplicant operation for the IP telephone itself, without PAE multicast pass-through or proxy Logoff for the attached PC.

Since most 802.1X clients use the Multicast MAC address for the EAPOL messages, the IP telephone must be configured to the pass-thru or p-t w/Logoff mode to pass-through these Multicast messages. It is recommended to use the p-t w/Logoff mode. When the phone is in the p-t w/Logoff mode, the phone will do proxy logoff for the attached PC when the PC is physically disconnected.

https://downloads.avaya.com/css/P8/documents/003896223

[jai_chandra2001]

Thanks Peter, 

We encountered the same issue, after enabling the "pass-through with proxy logoff" enabled hte EAPOL packets to reach the switch. When machines connected to the Phones were disconnected/logged-off/powered-off, the avaya was able to pass on the messages to Switch and the "show authentication session interface Gx/0/x details" was not showing an active sessions anymore. We enabled value (DOT1X=1) and it worked.

https://downloads.avaya.com/elmodocs2/one-X_Deskphone_Edition/R1.5/output/16_300698_4/admn079.html

*************************

## SET DOT1X 0

*************************

Thanks for your write-up

[Sylvia]

Hello @ozy.djohan21

How did you specify the voice VLAN id on ISE for Avaya phones as in my case i have different VLANs for data and voice. I enabled Voice Domain Permission but my Avaya phone is not getting an IP due to not having the correct voice VLAN pushed to the port. If i configure the voice vlan under the port it works, but I want the VLAN to be pushed from ISE. 

Do you have any insights regarding this issue?

[lenwood.spotts]

That's an easy fix.

Under the authorization profile that you set, you have to have the Voice Domain Permission checked, and then check the VLAN option. Once you do that you're presented with the option to put in the vlan id or vlan name. you put in the vlan data there. ISE will then push the VLAN id/Name from itself, rather then you having the add it to the port.

[ozy.djohan21 · Accepted solution]

Hi Sylvia,

I'm sorry I really forgot about this thread to give it an update. No we didn't configure the VLAN from the ISE and use the voice vlan configuration on the interface.

The root cause of the issue is caused by out of date firmware of the Avaya phones. After we upgrade it the authentication worked successfully for both the phones and the PC.

[Harvey.Reed]

What model of phone are you using?  I am having the same issue using Avaya 1120e?