Assigning fixed IP to generated VDI desktops

[Miloslav Hůla]

Hi,

we are running VMware platform with virtual desktops (VDI) with Windows
7/8.1/10. We are dealing with fixed address asignment by ISC DHCP Server
(4.3.1-6+deb8u2 Debian Jessie) to stations generated with random MAC
addresses.

The basic steps are following:

1) prepare a golden image (the source Windows machine)
2) generate the pool of windows desktops based on the golden

Let's say, we are creating a pool of 50 office desktops. We are telling
to VMware: "Create office-01 to office-50 from golden". The process for
every new station is:

a) Take golden with known MAC1 and hostname 'golden'.
b) Clone golden. The result is a windows machine with new random MAC2,
but hostname is still 'golden'.
c) Boot up new machine and run customization scripts. The result is the
hostname is changed to 'office-01'.
d) Reboot machine (and run some other scripts)
e) Power off the machine. It's done.

We are assigning IP addresses by making classes based on host-name
option matching.

The problem is, that in step b) we have machine with hostname 'golden'
and MAC2. So, DHCP server creates a lease for it from dynamic range.
Then machine reboots and have hostname 'office-01' and still MAC2 in
steps c) and d). Now we need to assign fixed IP by hostname, but there
is already lease for it and DHCP server offers this one.

My question is, is there some kind of prefences we could do? I read in
manual that priorities are host, class, pool, subnet, shared-network.

I read in manual about "host-identifier option option-name option-data"
but it is for DHCPv6. Or it is not? Because I found some posts in this
list pointing to DHCPv4 too.

And another questions, possibly not so related. We are running separated
DHCP server for VDI. And we have a two next DHCP servers in fail-over
mode for the rest of the network. The whole network has about 130
subnets and 100 VLANs. We would like to merge VDI DHCP server with the
two others. The question is, the host-name matching must work only for
VDI VLAN. If I understand manual correctly, class declarations are
global. Could it be done by subclasses?

And the last question. How DHCP server handles requests from DHCP relay?
In log we can see:

- via eth0
- via eth1
- via 10.70.0.1

I guess, that server fetches current eth0 or eth1 IP addresses and match
the subnets according to. Is it the same for the relay? Subnet is
matched by the relay IP address?


Thank you very much and sorry for such long post. We have done some
"working" configuration but every body is affraid to make some change,
because no one of us really knows how it works :)

Kind regards, Milo
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Miloslav Hůla <[hidden email]> wrote:

> The basic steps are following:
>
> 1) prepare a golden image (the source Windows machine)
> 2) generate the pool of windows desktops based on the golden
>
> Let's say, we are creating a pool of 50 office desktops. We are telling to VMware: "Create office-01 to office-50 from golden". The process for every new station is:
>
> a) Take golden with known MAC1 and hostname 'golden'.
> b) Clone golden. The result is a windows machine with new random MAC2, but hostname is still 'golden'.
> c) Boot up new machine and run customization scripts. The result is the hostname is changed to 'office-01'.
> d) Reboot machine (and run some other scripts)
> e) Power off the machine. It's done.
>
> We are assigning IP addresses by making classes based on host-name option matching.
>
> The problem is, that in step b) we have machine with hostname 'golden' and MAC2. So, DHCP server creates a lease for it from dynamic range. Then machine reboots and have hostname 'office-01' and still MAC2 in steps c) and d). Now we need to assign fixed IP by hostname, but there is already lease for it and DHCP server offers this one.

How about having a small pool, and "allow members of golden" where class "golden" is match on hostname="golden" ? Then on first boot, each new machine would get an address from this pool. Once it's changed it's hostname, it will no longer match that class and so will be denied access to that pool - so it will honour other assignments, if you get it all right, this will be your static IP.


> My question is, is there some kind of prefences we could do? I read in manual that priorities are host, class, pool, subnet, shared-network.

Not so much priority, as inheritance. If anything is set in one level, then it will be inherited down the levels until it's either used or over-ridden by being set in a lower level. Thus, for example, you can set name-servers in the global scope and that will apply everywhere - but you could set it again in (say) a subnet declaration and it will apply in that subnet and any pools within it. And you could over-ride it again in a single pool.


> And another questions, possibly not so related. We are running separated DHCP server for VDI. And we have a two next DHCP servers in fail-over mode for the rest of the network. The whole network has about 130 subnets and 100 VLANs. We would like to merge VDI DHCP server with the two others. The question is, the host-name matching must work only for VDI VLAN. If I understand manual correctly, class declarations are global. Could it be done by subclasses?

You will need to ensure that your assignment logic supports it. IFF you can be sure that no other host will have a host name "office-nn" then it is sufficient to define a class matching on that. However, since it is easy to set a hostname then someone could upset that.
Presumably the MAC addresses all fall within one OUI (or a small number of OUIs), so you could extend the matching to that and thus exclude anything not running as a VM with that hypervisor type.


> And the last question. How DHCP server handles requests from DHCP relay? In log we can see:
>
> - via eth0
> - via eth1
> - via 10.70.0.1
>
> I guess, that server fetches current eth0 or eth1 IP addresses and match the subnets according to. Is it the same for the relay? Subnet is matched by the relay IP address?

Correct.
For packets arriving "directly" at the server, it will log "via ethn" and use the subnet(s) defined on that interface to determine an appropriate subnet to consider for address allocation to the client. Where the request is relayed, the relay agent will fill in the GI-Addr (gateway Interface Address) field in the packet and the server will use that. The GI-Addr field *must* be an IP address within the subnet (or shared-network) to which the clients are connected.

For a little light reading :D I strongly recommend The DHCP Handbook by Ralph Droms and Ted Lemon. There's a second edition, but this mostly adds stuff about failover - other than that, the first edition is still very usable. It's both very detailed and very readable - and starts with some history to explain the "WTF did we do it that way" elements of DHCP ! FWIW, both authors are respected in the DHCP field - Ted in particular had a big hand in writing the ISC server, at least the V3 version IIRC, and really knows what he's talking about.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Miloslav Hůla]

Dne 01.11.2016 v 11:47 Simon Hobson napsal(a):

> Miloslav Hůla <[hidden email]> wrote:
>
>> The basic steps are following:
>>
>> 1) prepare a golden image (the source Windows machine)
>> 2) generate the pool of windows desktops based on the golden
>>
>> Let's say, we are creating a pool of 50 office desktops. We are telling to VMware: "Create office-01 to office-50 from golden". The process for every new station is:
>>
>> a) Take golden with known MAC1 and hostname 'golden'.
>> b) Clone golden. The result is a windows machine with new random MAC2, but hostname is still 'golden'.
>> c) Boot up new machine and run customization scripts. The result is the hostname is changed to 'office-01'.
>> d) Reboot machine (and run some other scripts)
>> e) Power off the machine. It's done.
>>
>> We are assigning IP addresses by making classes based on host-name option matching.
>>
>> The problem is, that in step b) we have machine with hostname 'golden' and MAC2. So, DHCP server creates a lease for it from dynamic range. Then machine reboots and have hostname 'office-01' and still MAC2 in steps c) and d). Now we need to assign fixed IP by hostname, but there is already lease for it and DHCP server offers this one.
>
> How about having a small pool, and "allow members of golden" where class "golden" is match on hostname="golden" ? Then on first boot, each new machine would get an address from this pool. Once it's changed it's hostname, it will no longer match that class and so will be denied access to that pool - so it will honour other assignments, if you get it all right, this will be your static IP.

We have separated IP pools already. One with public IP adresses for
office-XX machines and one with private IP addresses for temporary
in-the-middle-of-cloning machines. The private pool is defined with
'deny members of "office-01"; deny members od "office-02"; ...'. It is
hard to maintain. Thanks for the tip to do matching by contraries. Seems
like good idea.

>> My question is, is there some kind of prefences we could do? I read in manual that priorities are host, class, pool, subnet, shared-network.
>
> Not so much priority, as inheritance. If anything is set in one level, then it will be inherited down the levels until it's either used or over-ridden by being set in a lower level. Thus, for example, you can set name-servers in the global scope and that will apply everywhere - but you could set it again in (say) a subnet declaration and it will apply in that subnet and any pools within it. And you could over-ride it again in a single pool.
>
>
>> And another questions, possibly not so related. We are running separated DHCP server for VDI. And we have a two next DHCP servers in fail-over mode for the rest of the network. The whole network has about 130 subnets and 100 VLANs. We would like to merge VDI DHCP server with the two others. The question is, the host-name matching must work only for VDI VLAN. If I understand manual correctly, class declarations are global. Could it be done by subclasses?
>
> You will need to ensure that your assignment logic supports it. IFF you can be sure that no other host will have a host name "office-nn" then it is sufficient to define a class matching on that. However, since it is easy to set a hostname then someone could upset that.
> Presumably the MAC addresses all fall within one OUI (or a small number of OUIs), so you could extend the matching to that and thus exclude anything not running as a VM with that hypervisor type.

That's the plan. But it is still weak place for security, mainly for
WiFi access. On the other hand, WiFi is in another VLAN so attacker will
be without connectivity with such stolen IP.

>> And the last question. How DHCP server handles requests from DHCP relay? In log we can see:
>>
>> - via eth0
>> - via eth1
>> - via 10.70.0.1
>>
>> I guess, that server fetches current eth0 or eth1 IP addresses and match the subnets according to. Is it the same for the relay? Subnet is matched by the relay IP address?
>
> Correct.
> For packets arriving "directly" at the server, it will log "via ethn" and use the subnet(s) defined on that interface to determine an appropriate subnet to consider for address allocation to the client. Where the request is relayed, the relay agent will fill in the GI-Addr (gateway Interface Address) field in the packet and the server will use that. The GI-Addr field *must* be an IP address within the subnet (or shared-network) to which the clients are connected.
>
> For a little light reading :D I strongly recommend The DHCP Handbook by Ralph Droms and Ted Lemon. There's a second edition, but this mostly adds stuff about failover - other than that, the first edition is still very usable. It's both very detailed and very readable - and starts with some history to explain the "WTF did we do it that way" elements of DHCP ! FWIW, both authors are respected in the DHCP field - Ted in particular had a big hand in writing the ISC server, at least the V3 version IIRC, and really knows what he's talking about.

Many thanks for your help and tips!
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Miloslav Hůla <[hidden email]> wrote:

>> You will need to ensure that your assignment logic supports it. IFF you can be sure that no other host will have a host name "office-nn" then it is sufficient to define a class matching on that. However, since it is easy to set a hostname then someone could upset that.
>> Presumably the MAC addresses all fall within one OUI (or a small number of OUIs), so you could extend the matching to that and thus exclude anything not running as a VM with that hypervisor type.
>
> That's the plan. But it is still weak place for security, mainly for WiFi access. On the other hand, WiFi is in another VLAN so attacker will be without connectivity with such stolen IP.

Don't forget that, unless you get the config very badly wrong, a device in a different network just won't match the subnet at all. So if your WiFo users are on a different VLAN (ie different network) then they won't be considered for your VDI pools at all even if they match the class statements. Thus they won't be able to "steal" an IP.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Bill Shirley]

You might try getting the Windows machine to release its lease on shutdown (outside the subnet):
# https://msdn.microsoft.com/en-us/library/cc227278.aspx        release-lease-on-shutdown
option space Win2k;
option Win2k.release-lease-on-shutdown  code 2 = unsigned integer 32;   # use 0 to disable, 1 to enable

and then in the pool:
    vendor-option-space Win2k;
    option Win2k.release-lease-on-shutdown  1;      # enable

Bill

On 11/1/2016 6:25 AM, Miloslav Hůla wrote:

Hi,

we are running VMware platform with virtual desktops (VDI) with Windows 7/8.1/10. We are dealing with fixed address asignment by ISC DHCP Server (4.3.1-6+deb8u2 Debian Jessie) to stations generated with random MAC addresses.

The basic steps are following:

1) prepare a golden image (the source Windows machine)
2) generate the pool of windows desktops based on the golden

Let's say, we are creating a pool of 50 office desktops. We are telling to VMware: "Create office-01 to office-50 from golden". The process for every new station is:

a) Take golden with known MAC1 and hostname 'golden'.
b) Clone golden. The result is a windows machine with new random MAC2, but hostname is still 'golden'.
c) Boot up new machine and run customization scripts. The result is the hostname is changed to 'office-01'.
d) Reboot machine (and run some other scripts)
e) Power off the machine. It's done.

We are assigning IP addresses by making classes based on host-name option matching.

The problem is, that in step b) we have machine with hostname 'golden' and MAC2. So, DHCP server creates a lease for it from dynamic range. Then machine reboots and have hostname 'office-01' and still MAC2 in steps c) and d). Now we need to assign fixed IP by hostname, but there is already lease for it and DHCP server offers this one.

My question is, is there some kind of prefences we could do? I read in manual that priorities are host, class, pool, subnet, shared-network.

I read in manual about "host-identifier option option-name option-data" but it is for DHCPv6. Or it is not? Because I found some posts in this list pointing to DHCPv4 too.

And another questions, possibly not so related. We are running separated DHCP server for VDI. And we have a two next DHCP servers in fail-over mode for the rest of the network. The whole network has about 130 subnets and 100 VLANs. We would like to merge VDI DHCP server with the two others. The question is, the host-name matching must work only for VDI VLAN. If I understand manual correctly, class declarations are global. Could it be done by subclasses?

And the last question. How DHCP server handles requests from DHCP relay? In log we can see:

- via eth0
- via eth1
- via 10.70.0.1

I guess, that server fetches current eth0 or eth1 IP addresses and match the subnets according to. Is it the same for the relay? Subnet is matched by the relay IP address?


Thank you very much and sorry for such long post. We have done some "working" configuration but every body is affraid to make some change, because no one of us really knows how it works :)

Kind regards, Milo
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Miloslav Hůla]

Dne 03.11.2016 v 0:17 Bill Shirley napsal(a):

> You might try getting the Windows machine to release its lease on
> shutdown (outside the subnet):
> # https://msdn.microsoft.com/en-us/library/cc227278.aspx
> release-lease-on-shutdown
> option space Win2k;
> option Win2k.release-lease-on-shutdown  code 2 = unsigned integer 32;
> # use 0 to disable, 1 to enable
>
> and then in the pool:
>     vendor-option-space Win2k;
>     option Win2k.release-lease-on-shutdown  1;      # enable

We are already using this option. It sometimes works, sometimes it doesn't.

When it works, desktop sends DHCPRELEASE and on next boot DHCPDISCOVER.
When it does not work, there isn't any DHCP message and on next reboot
DHCPREQUEST for an old IP.

It's hard to debug why, because it is hard do debug VMware customization
process.

Milo


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users