I am trying to use an SA6000 with Network Connect and obtaining an IP address via DHCP. My DHCP server requires a unique MAC address in order to give out an address. The SA6000 generates fake MAC addresses for the DHCP ciaddr field, and a strange client identifier. I am wondering how the SA creates the client identifier and why it creates a fake MAC address for the client rather than passing the client's actual Network Connect Virtual Adapter MAC. Anyone have any ideas?
Well, my guess would be that the SSL-VPN appliance doesn't actually see the MAC address of the client PC as it is generally routed over the Internet. I guess the client could pass it in the login packet or something at the application layer, but I am not sure I see the benefit of doing so.
According to the RFC, the only mandatory requirement is that the client identifier be unique:
"For correct identification of clients, each client's client-
identifier MUST be unique among the client-identifiers used on the
subnet to which the client is attached. Vendors and system
administrators are responsible for choosing client-identifiers that
meet this requirement for uniqueness."
We are ensuring uniqueness by using the user's SID in the client identifier. We are not using type-value pairs. One thing to note is that the IVE is sending these DHCP Discover packets on behalf of the NC clients and does not have the client's hardware address when doing so.
Whose DHCP server are you using? I have not had any issues with the following DHCP servers:
Microsoft DHCP server on WIndows Server 2003
Microsoft DHCP server on WIndows Server 2008
VitalQIP running on Solaris
ISC dhcpd running on CentOS 5
All remote access servers generate virtual MACs for remote clients. I've use Livingston, Gandalf, Juniper and Cisco for remote access and have never had a DHCP server refuse to provide an IP address to an authorized client.
If you watch the log on your DHCP server does it generate a DHCPDENY response to your request?