When setting up an L2TP VPN service for remote access on Windows Routing and Remote Access, we ran into an odd problem with setting options on the connecting clients. The way to provide these settings to L2TP clients in RRAS in through DHCP (MS doc) - an L2TP client sends a DHCPInform packet, which then applies the settings from DHCP options (option 15 for the DNS search suffix, and option 121 for split tunnel routes).
In most L2TP client VPN endpoints like Cisco ASAs, the L2TP service crafts the DHCP response with the DNS and routing settings configured - but in RRAS, you use the DHCP relay built into RRAS, or a DHCP server on the local subnet - but these options must be set in DHCP, not via RADIUS attribute or RRAS setting or anything else. (for too much detail on how the DHCPInform works and why it's so necessary, follow this crazy thread between a couple of our Server Fault regulars)
We found that no Mac (or iOS, for that matter) clients would successfully retrieve these options on our newly configured Windows Server 2016 VPN server, instead timing out on their attempts to get DHCP from the VPN server (from /var/log/ppp.log after turning on verbose logging):
...
Fri Dec 1 12:09:18 2017 : sent [IP data <src addr 192.0.2.8> <dst addr 255.255.255.255> <BOOTP Request> <type INFORM> <client id 0x08000000010000> <parameters = 0x6 0x2c 0x2b 0x1 0xf9 0xf>]
Fri Dec 1 12:09:21 2017 : sent [IP data <src addr 192.0.2.8> <dst addr 255.255.255.255> <BOOTP Request> <type INFORM> <client id 0x08000000010000> <parameters = 0x6 0x2c 0x2b 0x1 0xf9 0xf>]
Fri Dec 1 12:09:24 2017 : No DHCP server replied
Watching the RRAS server as this happens, the DHCP Relay seems to see these packets, but oddly, reports them as discarded (the numbers in the circled columns both increment immediately when the client logs the DHCP requests being sent):
After turning up the RRAS logging knobs to the max, I expected the Windows event log to shed some light on the reason for the discards (since the documentation exists for all of these events), but none of these events began logging. Finally, after turning on the RRAS tracing logs, C:\Windows\system32\tracing\IPBOOTP.LOG finally provided a hint as to why the Mac's DHCP packets were unacceptable:
[9712] 12:09:10: dropping REQUEST with secs-since-boot 0 on interface 42 (192.0.2.8)
Why won't the RRAS DHCP Relay do its job and send these VPN clients' DHCP packets to the DHCP server?
As it turns out, the defaults for the DHCP relay agent simply don't work for some L2TP clients.
When you set up an interface for DHCP relaying in RRAS (on the "Internal" interface, where VPN clients go), the default options look like this:
It looks unassuming, but the cause of this entire issue is the "Boot threshold" setting. The documentation makes it sound so helpful!
Obviously that option sounds like it only has bearing on when you're doing actual DHCP relaying inside your network. Not even the most verbose of Microsoft's guides for using the DHCP Relay for VPN options have any mention of needing to pay attention to the boot threshold setting.
But, the logs don't lie, and
dropping REQUEST with secs-since-boot 0seemed like a clear indication that the DHCP relay agent itself was at fault. That error pointed me to a blog post from a helpful admin in Lichtenstein, which finally showed me what was going on.The "Boot threshold" DHCP relay option isn't a delay, as the documentation implies - it's a hard packet filter, and will drop all DHCP packets under the threshold. Setting this to anything higher than 0 makes no sense when using the DHCP relay for VPN clients (on the "Internal" interface), and will break many L2TP client implementations' ability to retrieve DHCP options, despite there being no indication of this behavior in the documentation.
After setting the boot threshold on the DHCP Relay to 0, Mac L2TP clients successfully retrieve settings from DHCP options 15 (DNS suffix) and 121 (split tunnel routes).