VPN client duplicate MAC addresses

Unanswered Question
Jun 3rd, 2008
User Badges:

Hello all,

We have an issue with McAffe EPO engine v3.6.0.574 while rebuilding users' GuIDs for the users connected through VPN with VPN client v4.8.02.0100. The EPO rebuilds the GuID using the user's MAC address. The problem is that the VPN client v4.8.02 assigns the same MAC address (00-05-9A-3C-78-00) to all users.

Can anybody tells us how can we solve this? We have only recently updated the VPN client from v4.6 to 4.8. the same problem was noticed with v4.6.

Is this a known issue with Cisco VPN client?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
aghaznavi Mon, 06/09/2008 - 08:12
User Badges:
  • Silver, 250 points or more

Might be any connectivity issues. Verify the configuration. since this info is just to achieve connectivity between the client, concentrator and the inside LAN

oanetadmin Wed, 06/11/2008 - 06:44
User Badges:

Could you be more explicit please. Our configuration works perfectly well for years causing no VPN connectivity issues.

Actually this problem becomes disturbing only when our ePO server needs to re-build a user profile basing it on the user's MAC address. As the VPN MAC is not unique, the replicated profile is wrong when two users belong to different profile groups.

bducharme72 Wed, 06/18/2008 - 11:44
User Badges:


We had the same problem a couple of weeks ago.

We were not able to solve the problem with Cisco. And until now it's not resolved.

But you can do a workaround.

You can add a key to the EPO server stating that you don't wnat to take care of the MAC adress. EPO will resolve only with the GUID of the client.It is the KB45372 from the McAfee knowledgebase.

Hope it help.

And if you have answers about the MAC from CISCO I would be interested to know.


oanetadmin Fri, 07/04/2008 - 01:19
User Badges:

Ben, Thanks for your tip but our EPO uses MAC address only when GUID gets corrupted.

I have received a reply from CISCO that my problem cannot be solved because there is no workaround for it.

I am still awaiting CISCO statement that this is a well-known issue.



This Discussion