EAPoL forwarding on NEC VoIP phones

A customer is running their PCs behind their VoIP phones. Nothing unusual, most VoIP phones I know have an embedded ethernet switch, so that you only need one cable to connect PC and VoIP phone to your network.

As part of a network security project, my colleague and I implemented IEEE 802.1X port-based Network access control at one of our customers networks. The setup consists of multiple Alcatel-Lucent Enterprise OmniSwitches (6450-P10 and 6860/E) and Aruba ClearPass.

We noticed, that mac-address based authentication worked all the time, but 802.1x fails constantly if the client was connected to a VoIP phone (NEC DT700). The phones does not do any port authentication. We use a device classification rule and User Network Profiles to get them to their correct VLAN. But the connected PCs should do a 802.1x based port authentication.

Wireshark FTW!

We used Wireshark to take a look at the communication. We created a packet trace on a client behind a VoIP phone, and we mirrored the traffic of the port, to which the phone was connected. Our assumption was that the VoIP phones drop the EAP packets from the connected PC.

This is a packet trace from my ThinkPad X250 which was connected to the phone.

You can see the repeating “Request, Identity” from the switch, and the answer from my laptop (Response, Identity). The destination for the response is a multicast mac-address. But this frame was not captured behind the VoIP phone! It was missing. On the packet trace, that was created my mirroring the switch port to which the phone was connected, the “Request, Identity” was seen, but not the “Response, Identity”. The phone was dropping the EAP packets of my laptop!

RTFM!

The customer called the company who was maintaining the phones. But they did not understood our problem, so they enabled 802.1x on the phones. We disabled this instantly again.

I decided to take a look into the manual of the NEC DT700 and I found a point called “EAPoL forwarding” in the advanced network settings. After enabling this setting, EAP started working instantly.

This is again a packet trace from my laptop, taken while it was connected to a VoIP phone. As you can see, the last EAP packet is “Success”!

EAPoL forwarding did the trick. :)