Windows 2019 RRAS Server unable to utilize DHCP server on same subnet to issue to RRAS clients

Tony 21 Reputation points
2020-07-19T19:55:06.02+00:00

Hi,

I've seen this occur twice already when setting up new Windows 2019 servers. Most recently, I introduced a new Windows 2019 to replace an older Windows 2008 R2 server as our RRAS server. Simple setup, with single domain, single subnet, one domain controller, small environment. When moving the RRAS service to the Windows 2019 server, it is not able to retrieve the IP addresses from the DHCP server to allocate to the L2TP/PPTP clients requesting them. When connecting to the server via PPTP/L2TP, the following error would appear on the Windows 2019 server:

RoutingDomainID- {00000000-0000-0000-0000-000000000000}: CoId={156257C0-6202-48A0-9E81-D3A5FCF0A2B9}: The user Domain\kevinr connected to port VPN4-79 has been disconnected because no network protocols were successfully negotiated.

RoutingDomainID- {: No IP address is available to hand out to the dial-in client

Re-installation of the RRAS server on the server did not fix it

I managed to get this to work by manually creating an IP Range within RRAS to hand out, but when doing it this way, I cannot get the appropriate DNS suffix information to be provided to the VPN clients. Thus, they can't access resources by just using the server name, they need to enter in the FQDN, which to non-technical folks, is a sheer pain for them to walk them through and correct.

So far, I've set up two Windows 2019 servers to assume RRAS services in my client environments, and this behavior has occurred on both servers. I tried moving the DHCP services on to the same server as the RRAS service on the Windows 2019 server, but that did not fix it either.

Has anyone experienced this before? I'm wondering is this is a known issue with Windows 2019 RRAS services, and wondering if MSFT has an official fix for this.

Thanks,
T

Windows DHCP
Windows DHCP
Windows: A family of Microsoft operating systems that run across personal computers, tablets, laptops, phones, internet of things devices, self-contained mixed reality headsets, large collaboration screens, and other devices.DHCP: Dynamic Host Configuration Protocol (DHCP). A communications protocol that lets network administrators manage centrally and automate the assignment of Internet Protocol (IP) addresses in an organization's network.
1,021 questions
Windows Server Infrastructure
Windows Server Infrastructure
Windows Server: A family of Microsoft server operating systems that support enterprise-level management, data storage, applications, and communications.Infrastructure: A Microsoft solution area focused on providing organizations with a cloud solution that supports their real-world needs and meets evolving regulatory requirements.
513 questions
Accepted answer
  1. Candy Luo 12,656 Reputation points Microsoft Vendor
    2020-07-20T04:04:16.057+00:00

    Hi ,

    Have you received such error message in Remote Access management console? Or find ACCESS_DENIED or 0xc0000022 in RRAS log?

    12930-3.png

    If yes, service hosts in SVCHOST.EXE are split into separate processes on RS3 and later versions of Windows 10 and Windows Server 2016 and all versions of Windows Server 2019 configured with more than 3.5 GB+ of RAM. Calls to DHCP client API DhcpLeaseIpAddressEx fail with ACCESS_DENIED because the DHCP Client Service process lacks the SeImpersonatePrivilege. Without this privilege, the process can not impersonate credentials.

    As a workaround:

    Add the SeImpersonatePrivilege to the DHCP client service and restart relevant services:

    reg add "HKLM\SYSTEM\CurrentControlSet\Services\Dhcp" /v RequiredPrivileges /d "SeChangeNotifyPrivilege"\0"SeCreateGlobalPrivilege"\0"SeImpersonatePrivilege"\0 /t REG_MULTI_SZ /f

    For your reference:

    https://social.technet.microsoft.com/Forums/en-US/7cbce33b-fe95-4c04-929d-e9b1ed62f944/vpn-connection-fails-with-new-server?forum=ws2019

    Best Regards,

    Candy

    2 people found this answer helpful.
    0 comments

5 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Dave Patrick 426.1K Reputation points MVP
    2020-07-19T21:00:18.293+00:00

    Might try the work-around mentioned here.
    https://social.technet.microsoft.com/Forums/en-US/0270d377-be3a-4b63-82a0-9df076c5e3b3/upgrade-from-2016-to-2019-breaks-dhcp-relay-agent-when-using-rras

    --please don't forget to Accept as answer if the reply is helpful--

    0 comments
  2. Tony 21 Reputation points
    2020-07-22T06:21:00.123+00:00

    Thanks for the feedback.

    I will attempt the workaround this weekend and let you know if it works.

    Thanks

  3. Gary S 1 Reputation point
    2022-10-17T18:46:16.007+00:00

    As much as I hate to revive a thread, I have encountered this issue. I have done an in-place upgrade from Server 2016 to Server 2019. RRAS fails with the exact error shown above. All of my searching has pointed to the same solution -- adding SeImpersonatePrivilege to the RequiredPrivileges key in HKLM\SYSTEM\CurrentControlSet\Services\Dhcp.

    I have added this change. The error persists. I am on Windows Server 2019 Version 1809 (OS Build 17763.3532).

    Are there any additional steps that I need to take? RRAS worked great on my Server 2016 with DHCP not an issue. I only have the "DirectAccess and VPN (RAS)" role installed. I do not have the "Routing" role installed as I did not need it.

    Thank you in advance.

  4. 39675960 0 Reputation points
    2023-01-24T14:19:06.6166667+00:00

    Faced this problem after the last update, fought for two days.

    Accepted answer did not help, everything was the same in the registry, but!

    I found a problem in another branch of the registry, addresses like 169.55.x.x were registered there, deleted it and everything worked fine now.

    Remove "from" and "to" entries and try to connect (No need to restart server or services):
    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ip\StaticAddressPool\0]

    "From"=dword:0a1b2a65

    "To"=dword:0a1b2a96

    0 comments