×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

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

Unanswered Question
Jul 24th, 2006
User Badges:

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!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3.8 (3 ratings)
Loading.
annnguy Mon, 07/24/2006 - 08:59
User Badges:

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

chalkspray Tue, 07/25/2006 - 05:23
User Badges:

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!

annnguy Tue, 07/25/2006 - 07:22
User Badges:

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

andrewjacobs Fri, 07/28/2006 - 10:52
User Badges:

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.


jafrazie Sat, 07/29/2006 - 08:37
User Badges:
  • Cisco Employee,

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


Thanks,

andrewjacobs Sat, 07/29/2006 - 10:04
User Badges:

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.

andrewjacobs Tue, 08/01/2006 - 09:25
User Badges:

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?

vramanaiah Wed, 09/27/2006 - 07:40
User Badges:

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


green_andrew Sat, 06/02/2007 - 03:55
User Badges:

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

green_andrew Sat, 06/02/2007 - 03:56
User Badges:

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

jafrazie Sat, 06/02/2007 - 07:08
User Badges:
  • Cisco Employee,

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.

chalkspray Sat, 06/02/2007 - 10:24
User Badges:

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.

jafrazie Sun, 06/03/2007 - 19:05
User Badges:
  • Cisco Employee,

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,


green_andrew Sun, 06/03/2007 - 23:34
User Badges:

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

chalkspray Mon, 06/04/2007 - 04:24
User Badges:

Andy,


I'm not sure how the phone is "authenticated"; you'd think they would have thought of MAC spoofing and have some other sort of test it must pass before just being excluded by the MAC.


Everyone,


The whole reason I started this thread was to find out whether or not the PC BEHIND A NORTEL IP PHONE would be able to access the network without being authenticated. No spoofing, no tricks, just plug in and go. What I've been told (and been unable to find anything to prove otherwise) is that Nortel IP phones are not compatible with Cisco NAC and thus WILL NOT pass through the MAC of the PC to a NAC device. Whereas a Cisco IP phone WOULD pass NAC authentication to the PC. So with a Nortel phone, a PC would be able to connect through a phone at any time and could bypass the NAC policy enforcement all together.


We are planning to move to IP phones (most are IP capable already) and we really don't want to re-run CAT6 to all the workstations so that the phones can use their own line, separate from the PC. Not only that, but we'd have to somehow disable the port on the back of the phone so that users would not be able to bypass authentication by connecting through the phone. I imagine this can be done, but I don't manage our phone system, just the network & servers.


Has anyone tried using Cisco NAC with Nortel or other NON-CISCO IP phones?

jafrazie Mon, 06/04/2007 - 17:44
User Badges:
  • Cisco Employee,

Let's be clear on this:


The typical goal for the IP Phone is to "remain unauthenticated". So yes, by default, the phone can access the voice-VLAN, and any PC connecting to the phone must "authenticate" via std process.


Of course this presents risk, but it's no worse off than you were BEFORE you had the NAC-Appliance in place to begin with. Also remember, the appliance can logistically only do so much anyway. It's not typically in the business of anti-spoofing prevention or fine-grained access-control. I mean, it may be more than 1-2 hops away anyway.


If you are worried about an attacker spoofing a MAC of a phone, then I would invite you to look at something like 802.1X for your phones, Multi-Domain-Authentication (MDA) on x-Catalyst switches, along with anti-spoofing data-plance protection techniques like DHCP-Snooping, Dynamic ARP Inspection, IP Source-Guard, etc. All this could be done irrespective of the NAC Appliance for data devices BTW.


In summary though, the PC behind a Nortel IP Phone, any other IP Phone, or a PC plugged directly into a switch should get authenticated "much the same way" WRT the NAC Appliance. I'm not sure how Nortel phones are not compatible, since it's outside of the end devices control as to whether a MAC is passed up anyway.


Hope this helps,

chalkspray Tue, 06/05/2007 - 06:16
User Badges:

Thanks for your reply. Andy had brought up the MAC spoofing issue. Although I am concerned with MAC spoofing, I'm not as concerned with it as I am with the NAC appliance being able to cut off the switch port to the PC if the device fails the security check.


Nortel was telling us that Cisco NAC does not support Nortel IP phones and that any PC's connected to those phones would be able to access the network immediately without being authenticated by the NAC device. What you're telling me is that this is not true. Do you have any documentation on Nortel IP phone compatibility?


So far every person I've talked to at Cisco has either not had the answer or has believed that Nortel was correct. In all cases both companies blame the other, which really does nothing for the customer.

green_andrew Tue, 06/05/2007 - 06:21
User Badges:

Hi


I found this on Multi Domain Authentication -


Multi Domain Authentication (MDA)-MDA provides enhanced security for IP phone deployments. This allows an IP phone (Cisco or third-party) and a single host behind the IP phone to independently authenticate using 802.1x. Using this method, a switch can place the host in the data VLAN and IP phone in the voice VLAN, though they appear on the same switch port. Data VLAN can be downloaded from the authentication, authorization, and accounting (AAA) server. For non-802.1x devices, MAC Authentication Bypass (MAB) can be used as the fallback to authenticate using the MAC address of the device. For non-802.1x deployments, MAB can be used to authenticate both IP phones and hosts.


However from my research this is only supported on the Cat 4K, 3750 and 3560... I was hoping for a 65xx solution.


May solve your issue though Chalkspray!


Cheers

Andy

chalkspray Tue, 06/05/2007 - 06:32
User Badges:

Thanks Andy. That's one option, but we really wanted to use the Cisco NAC appliance in our environment as it would be much easier to control our network and would integrate well with our Cisco MARS, IPS, and Firewalls... rather than going to a straight 802.1x solution. Cisco NAC provides so much more. MDA can't decide to not allow a particular PC because of missing patches, because the PC has a virus, or has out of date virus definitions.


802.1x also doesn't work well in environments where there are so many consultants coming in and out each day the company's policy is to not allow ANY network connection (isolated VLAN or not) without being first being checked out by IT personnel.


Additionally, we ran into issues while testing 802.1x where the PC could not be accessed via the network (for patches or remote adminstration) when the user was not logged in to Windows. We were using Windows to pass-through the AD information for 802.1x authentication, rather than going by MAC addresses. Maybe this has been resolved now, but at the time, 802.1x was still fairly new and rarely implemented on wired networks.


So really, I'd love to find out if there's some way to allow complete out-of-band functionality with Cisco NAC using Nortel IP phones. Anyone?


Jeremy

jafrazie Tue, 06/05/2007 - 07:13
User Badges:
  • Cisco Employee,

A few things here:


* Not sure of any docs demonstrating how the NAC Appliance works with IP-Tel, even3rd party IP-Tel. Suffice it to say though, it's just a MAC address, and you can choose to ignore it on the NAC Appliance if you wish to have IP-Tel interop. Not sure why/how this would even have anything to do with Nortel, per se.


* Multi Domain Authentication (MDA). Yes, it's only supported on the switches listed before (Cat 4K, 3750 and 3560). It's around the corner for the 6500, so please contact your account team for an update.


You should be able use the Cisco NAC appliance in your environment either way.


HTH,


tim.riegert Tue, 06/05/2007 - 09:36
User Badges:

Everything Jason is saying makes sense. You enable mac snmp traps on the switch, so the CAS knows when a new mac address is learned (device has come up, even if it is daisy-chained off an IP phone). However, you must configure a filter to ignore the mac-addresses that contain the Nortel IP phone OUI -- so when an IP phone is plugged in, the CAS ignores it.


From what I understand, the only place where you could have a problem is 6500s, which cannot send the mac traps. They can send linkup/down traps, but you would not receive those traps if there is an IP phone on the switchport that is already up. From what I've been told, this will be fixed when Whitney code is released.

Actions

This Discussion