cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2167
Views
11
Helpful
21
Replies

Will NAC work with non-Cisco IP phones & the devices behind it

chalkspray
Level 1
Level 1

I've been told that when you implement Cisco NAC and are using non-Cisco IP phones, the device will authenticate the phone but not the pc plugged into it. Is this true or was it true and if so, is there a fix or a workaround? Nortel has been using this as one of their key points to discourage us from buying all Cisco routers and implementing NAC.

We are using Nortel phone systems right now but they aren't IP based. However, it seems it would be cheaper to upgrade those instead of replacing them with Cisco units.

Thanks!

21 Replies 21

annnguy
Level 1
Level 1

The issue that is of concern with regard to 802.1x and IP phones is that port authorization is triggered by the state of the link on the switch (or receipt of an EAPOL start message). Unfortunately, for the most part, switches are unable to determine what type of device is being plugged into a specific port; if a phone is able to authorize that port, it will remain open regardless of what traffic passes through it.

To address this, the switch will actually have both a Voice VLAN (which passes voice traffic) and a data vlan (which passes data traffic--ie. traffic from a PC plugged behind the phone). In order to distinguish itself as a phone, the Cisco IP phones send CDP packets to the switch. Therefore, the switch will then know to exempt all traffic passed through the Voice VLAN, but require authentication for data traffic before allowing traffic to pass.

Essentially to answer your question, the IP phone that you are using needs to be able to send CDP packets identifying itself as an IP phone, and have the ability to send voice traffic through the Voice VLAN and data traffic through the data vlan. As far as I am aware, this is only available on Cisco IP Phones at the present time.

Sincerely,

Annie

Hmm, I wasn't aware that the phone had to support CDP. That was not mentioned in any of the articles I've read. My understanding is that its an 802.1x issue.

Anyone else...? If we buy Nortel IP phones, and someone plugs in their laptop to the port on the IP phone. Will NAC authenticate the laptop behind the phone or not?

Thanks!

I apologize, I actually just assumed you were doing a L2 802.1x deployment for NAC. If this is the case, then unfortunately the port will already be authenticated by the phone and hence not authenticate the PC behind the phone (unless CDP is involved).

If you are doing a NAC L3 deployment (on a router or VPN concentrator), then NAC is triggered by traffic hitting the outside interface from a specific source IP address. It works similar to auth-proxy in the sense that traffic from that source IP is intercepted on the ingress interface and prompted for authentication. The user can even be multiple L3 hops away.

On the other hand, there is also L2 IP NAC on switch, which uses DHCP snooping or ARP inspection to trigger the NAC posture validation process for a specific host. Once validated, the user will be given a downloadable ACL in order to restrict access to the network depending on what token they receive. Others can chime in with other opinions, but my take on it is that NAC L2 IP may be your best bet.

Sincerely,

Annie

I'm researching implementing 802.1x with a Cisco switch (4006 with a Sup III and IOS 12.2(25)EWA) and Nortel wired IP phones (1140E's). I found a solution that seems to work, although I'm not sure if it's a bug or desired behavior on the switch's part.

With 802.1x enabled on a switched port with both an access and voice VLAN configured and the Nortel IP phone plugged it, the only way I found for it to "bypass" authentication and force authentication on the phone's PC port is to manually set the voice VLAN in the phone itself.

By doing this, the initial DHCP request from the phone is tagged to go to the voice VLAN where for some reason 802.1x doesn't function so DHCP and all other traffic works like a charm. 802.1x does work, however, on the access VLAN. As a result, traffic from a computer plugged into the back of the phone is requires authentication because its traffic is untagged and goes to the access VLAN where 802.1x is enforced.

Although for my situation I'm glad it works this way, I don't quite understand why 802.1x isn't enforced on the voice VLAN on an 802.1x enabled port. Couldn't a client conceivably connect to the port, tag its traffic with the voice VLAN and bypass all authentication? Doe this mean that Cisco IP phones only use CDP to discover the voice VLAN dynamically and not to authorize the phone to communicate on the voice VLAN? Maybe someone can shed some light on this subject for me.

From my tests I conclude that any IP phone should work fine with 802.1x if you (1) have both an access as well as a voice VLAN configured and (2) statically set the voice VLAN on the phone.

Hope that helps.

Can you let me know what switch and code rev you're experiencing this operation with?

Thanks,

Catalyst 4006 with a Supervisor III and IOS 12.2(25)EWA (the latest greatest)

I plan on testing this on a 3550 to see if it is a bug with the 4006 or deliberate behavior. I'll let you know what I find.

I did the tests with a 3750 and a 2950 and neither of them allowed access on the voice VLAN before 802.1x authentication succeeded. Looks like what I was seeing earlier was just a bug in the IOS on the 4006.

But now the question is, what do people do who have non-Cisco IP phones and Cisco switches and want to require 802.1x authentication on the PC port of the phone? I'd be happy to just disable 802.1x altogether on the VVID and leave it on the PVID if I could, but that doesn't seem to be an option in the IOS. Are the only solutions to wait for Cisco to support 802.1ab (LLDP) or mutiple 802.1x authentications on a single port (instead of having one device authenticate the entire port for all connected devices as it currently does)?

Annie, I looked into NAC L2 IP, but if I understood it correctly, it doesn't support identity at all, just posture. So I'm not sure how that could be used to give IP phones access to the voice VLAN without authenticating and force devices on the PC port to authenticate (using EAP-TLS).

Are there any other options here I'm missing?

I assume the above discussion is w.r.to NAC framework..

What is the situation in a case of a NAC appliance deployment in L2 OOB mode.. Did anyone succeed making it work with Nortel phones.. ?

Hi

Did you manage to find an answer to this problem? I am in a similar situation and would be very grateful for any light you can shed on this issue.

Thanks very much

Andy

Hi Andrew

Did you manage to find an answer to this problem? I am in a similar situation and would be very grateful for any light you can shed on this issue.

Thanks very much

Andy

Is this a question about 802.1X? The "NAC" sentiment is throwing me a bit, since there's more than one way to do this.

No, this is not a question about 802.1x. We're looking into the Cisco NAC framework using the NAC Appliance. To answer Andy's question, no, I did not find an answer to the question. In fact I just attended a NAC seminar hosted by an IT solutions provider at one of the Cisco offices on Wednesday (which turned out to be a complete waste of time) and they didn't know. None of them could answer the question. More or less, they skirted the issue which tells me that this is still a problem. They obviously don't have an issue with Cisco IP phones but it seems there's still an issue with Nortel IP phones. They tried to blame the issue on Nortel.

Not sure what the issue is, but if you support NAC trigger via mac-notifications, and input MACs of phones to ignore traps from said phones, you should be fine, irrespective of the phone vednor.

Hope this helps,

Thanks for the responses.

'...if you support NAC trigger via mac-notifications, and input MACs of phones to ignore traps from said phones, you should be fine, irrespective of the phone vednor.'

So therefore the phone remains unauthenticated but can access the voice VLAN, and the PC connecting via the phone to the data VLAN is authenticated?

If I have this correct, surely this presents a risk, in that an attacker could spoof the MAC of a phone to gain unauthorised access and launch an attack? Say a DOS attack?

Thanks again.

Andy

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: