Windows 2012 R2 – RRAS DHCPDISCOVER

Through deploying 2012 R2 into my home lab for testing I’ve recognised some “weirdness” with the RRAS requesting 10 DHCP leases when the service is started.

Seems this is normal – RRAS requests 10 IPs (Technet). Keeps the IP/Subnet info but drops everything else offered by the DHCP server such as options. This ensures that dial-in clients have an IP available immediately without needing to await a DHCP response. Clever I guess.. just looks messy on my active leases as they’re all mixed up with my normal network devices. Additionally – my ranges are being consumed by RRAS and creating a lease shortage for the rest of my network.

Now the obvious thing to do here, is increase the size of the range. I know. But that’s far to simple.. What I fancy doing instead.. is creating a New range, and having the RRAS addresses allocated from that. I can tag it within IPAM tool as a RRAS DHCP Range and keep the addresses out of my main network pool.

To do this – I create a new range on my DHCP server (ISC DHCP) with an idea here of associating the DHCPDISCOVER messages coming from the 2012 R2 with this new range in order to keep the RRAS DHCP leases out of my primary range; preventing exhaustion, and making my IP allocation look prettier (it’s important that things look pretty….).

For it to work, I need to establish a way of identifying the request. Let’s take a look at a DHCPDISCOVER message:

192.168.10.80.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:50:56:37:a3:b0, length 319, xid 0xd40c1b0d, Flags [Broadcast] (0x8000)
Client-Ethernet-Address 00:50:56:37:a3:b0
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
CLASS Option 77, length 14: “RRAS.Microsoft
NOAUTO Option 116, length 1: Y
Client-ID Option 61, length 17: ether 52:41:53:20:00:50:56:37:a3:b0:00:00:00:00:00:00
Hostname Option 12, length 10: “MS-Serv001
Vendor-Class Option 60, length 8: “MSFT 5.0”
Parameter-Request Option 55, length 13:
Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
Static-Route, Classless-Static-Route, Classless-Static-Route-Microsoft, Option 252
Vendor-Option
END Option 255, length 0

Few different options here. I’ve made bold, and coloured red to highlight.

Using these I could associate allocation of IPs to the:

MAC address of the sending interface (00:50:56:37:a3:b0)
IP address of the sending interface (192.168.10.80)
The Hostname of the requesting client (MS-Serv001)
The User Class specified by the requesting client (RRAS.Microsoft)

I should note: I did check the hostname option remained consistent across multiple messages, and although a totally viable option – I think I’ll go with the User Class option instead. It’s a nice specific value used to identify requests from the RRAS, and one that won’t be effected by changes to the 2012’s domain or network configuration.

Perfect.

 

Now, the DHCP Service will need to be reconfigured to prevent allocation to the RRAS from the primary pool (192.168.10.100-120), and instead allocated from the new range (192.168.10.81-99).

Matching the User Class is as relatively straight forward once you know the option to use. In this case ‘user-class’. Once determined, choose a name and create the class within the dhcpd.conf as below;

class “Microsoft Routing and Remote Access” {
match if option user-class = “RRAS.Microsoft”;
}

The class name is now Microsoft Routing and Remote Access

Once the class has been created we can then adjust access to the pool using ACLs. The ACLs deny clients matching class defined from the main pool causing it to fall-through to the next pool in the config. On this pool the class is allowed, and addresses will be allocated as required.

pool {
option domain-name-servers 192.168.10.251;
option domain-search “home”;
option routers 192.168.10.254;
option domain-name “lab”;
failover peer “failover-smart-dhcp1.lab”;
deny members of “Microsoft Routing and Remote Access”;allow unknown clients;
range 192.168.10.100 192.168.10.145;
}
pool {
failover peer “failover-smart-dhcp1.lab”;
allow members of “Microsoft Routing and Remote Access”;
range 192.168.10.81 192.168.10.99;
}

Pretty straight forward.

Restart the service and go. You should check the config first but I’m a maverick.. Live life on the edge..

Anyhow.. Looking at the GUI of my DHCP server – it seems the config works well.

Screen Shot 2015-07-09 at 11.42.46My primary scope (192.168.10.100-192.168.10.120) is no longer filled with leases from MS-Serv001! Happy days!!

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*