I have something to add to this article. Tom says that:
quote:
You have the option to create a static address pool of addresses to be assigned to the VPN clients. If you choose to use a static address pool, you will not be able to assign DHCP options to these hosts.
I do not want to contradict Tom since I have a huge respect for him, but the following lines represent what I have observed. I know the article is about ISA 2004 but when writing this I do not have access to an ISA 2004 only to an ISA 2006. However the principles must match at least if I'm not missing something. We can assign any static address pool of addresses to VPN clients and still get DHCP options with the only condition to not overlap this static range with addresses that belongs to other ISA networks. If this static address pool of addresses is on-subnet(with the Internal network) then we must exclude this range from the definition of ISA's Internal network. If this static address pool of addresses is off-subnet what we have to do is to configure a DHCP scope on the DHCP server which will match this range and add there the required options. The VPN client will always issue the DHCPINFORM packet. In this packet the source IP address will be the address of the DHCP relay which is set to use the RRAS Internal interface which in this case has an IP address from our static range. The client IP address will be also from the static range being assigned by RRAS. The DHCP relay knows what server to contact because we did specify this on it. So when this packet will reach the DHCP server(Windows 2003 R2 Ent) it will be answered by this with the Options configured in the new Scope. Note that when looking to the DHCP server we will not see any Addresses Leased because the DHCP Server has not lease any IP addresses to RRAS. The DHCP server will display all the addresses as being available. Let's check RFC2131 for an explanation on the DHCPINFORM packet:
quote:
DHCPINFORM - Client to server, asking only for local configuration parameters; client already has externally configured network address. If a client has obtained a network address through some other means (e.g., manual configuration), it may use a DHCPINFORM request message to obtain other local configuration parameters. Servers receiving a DHCPINFORM message construct a DHCPACK message with any local configuration parameters appropriate for the client without: allocating a new address, checking for an existing binding, filling in 'yiaddr' or including lease time parameters. The servers SHOULD unicast the DHCPACK reply to the address given in the 'ciaddr' field of the DHCPINFORM message.
The server SHOULD check the network address in a DHCPINFORM message for consistency, but MUST NOT check for an existing lease. The server forms a DHCPACK message containing the configuration parameters for the requesting client and sends the DHCPACK message directly to the client.
So this is why the DHCP server still responds to the DHCPINFORM packet although it has not leased any addresses. If the DHCP server is located on the Internal network, the internal clients will not get IP addresses from this new scope because the DHCP server has an IP address configured on its NIC from the Internal network. So they will get IP addresses from the Scope defined for the Internal network. Also if we add another interface for relay on ISA, say DMZ, we will define another scope on the DHCP server to provide IP addresses for that network(another subnet). In this case the DHCP relay's IP address will be the IP address of ISA's DMZ interface. So no interference either. Why I have said that this should apply also to ISA 2004: because the VPN client always sends the DHCPINFORM packet thus the DHCP Relay will pick it up and send it to the DHCP server. ISA will not break this because we have created the required access rules. Best regards!
Can anyone explain why I can get authenticated via VPN, yet be given a 169.254.xxx.xxx address? I thought I should be given an Internal address because of the DHCP Relay Agent I set up...