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:
 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?