locked
Windows (DHCP) Server replying with DHCP NAK (RFC3527 Link Selection sub-option) RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hello. I have a problem with a DHCP server running on Windows Server 2016. I am not verified so I can not insert an image of the topology so I will try to explain as good as I can.

    I am trying to use the RFC3527 Link Selection (option 82) sub-option 5 to relay IP addresses to Cisco Anyconnect VPN clients.

    1) The DHCP server's IP address is 10.99.100.100, it is configured to assign IP addresses from a scope of 192.168.99.0/24 from a range of .10 - .254)

    2) The VPN server and the DHCP server do not share a common L2 network, they are separated by a L3 firewall.

    3) The VPN server's (Cisco ASA FW) inside network IP address is 10.113.212.84. This IP address is used when communicating with the DHCP server.

    4) The VPN server is configured to use Link Selection (option 82, suboption 5: 192.168.99.3) when relaying the DHCP requests from VPN clients to the DHCP server.

    This is how the Wireshark capture looks like on the DHCP server:

    * The DHCP server receives the DHCP discovery (relay agent IP: 10.113.212.84; option82 suboption5 link selection IP: 192.168.99.3)

    * The DHCP server responds with a DHCP offer (client IP address 192.168.99.10; server IP address 10.99.100.100; relay agent IP address 10.113.212.84; option82 suboption5 link selection IP: 192.168.99.3)

    * The relay sends the DHCP request (requested IP address 192.168.99.10; option82 suboption5 link selection IP: 192.168.99.3)

    * The DHCP server replies with a DHCP NAK (nothing useful seen in the DHCP NAK packet; the option82 suboption5 link selection IP: 192.168.99.3 still exists in packet). The DHCP server logs following entry:

    15,01/03/18,17:39:10,NACK,192.168.99.13,,636973636F2D383462382E303237362E663837332D4445534B544F502D4437495442453932302D6D616E6167656D656E7400,,0,6,,,,,,,,,0

    I understand that the link selection configuration should be pretty straightforward but I fail to get it working. If interested, I can provide a Wireshark capture. Any help is most welcome! 

    Best regards, Heiki.


    • Edited by heikis Wednesday, January 3, 2018 4:14 PM
    Wednesday, January 3, 2018 4:11 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi ,

    Based on the complexity and the specific situation, we need do more researches. If we have any updates or any thoughts about this issue, we will keep you posted as soon as possible. Your kind understanding is appreciated. If you have further information during this period, you could post it on the forum, which help us understand and analyze this issue comprehensively.

    Best Regards,

    Candy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, January 4, 2018 8:43 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Got my account verified, so I will add the topology picture. Maybe it will help.

    Thursday, January 4, 2018 9:51 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I have the same issue. Did you come up with a solution?

    Thanks

    Friday, April 6, 2018 9:30 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I am experiencing the same issue with Windows Server 2016 DHCP. Wondering if there is any update on this?

    Thank you.

    Friday, August 10, 2018 8:01 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Yes, I solved the problem by creating a dummy DHCP scope on the network the relay agent sits on. Then excluded all the IP addresses so that none are available to hand out. 

    In the example posted above, you would create a second, dummy DHCP scope on the DHCP server with a range of 10.113.212.1 to 10.113.212.10 then also add in an exclusion range of 10.113.212.1 to 10.113.212.10.

    I don't remember how I came across this solution. But, at the time it made sense.


    Friday, August 10, 2018 8:07 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Yes, I solved the problem by creating a dummy DHCP scope on the network the relay agent sits on. Then excluded all the IP addresses so that none are available to hand out. 

    In the example posted above, you would create a second, dummy DHCP scope on the DHCP server with a range of 10.113.212.1 to 10.113.212.10 then also add in an exclusion range of 10.113.212.1 to 10.113.212.10.

    I don't remember how I came across this solution. But, at the time it made sense.


    I think the solution comes from this MS reference

    https://docs.microsoft.com/en-us/windows-server/networking/technologies/dhcp/dhcp-subnet-options

    There's a specific note that says:

    All relay agent IP addresses (GIADDR) must be part of an active DHCP scope IP address range. Any GIADDR outside of the DHCP scope IP address ranges is considered a rogue relay and Windows DHCP Server will not acknowledge DHCP client requests from those relay agents.

    A special scope can be created to "authorize" relay agents. Create a scope with the GIADDR (or multiple if the GIADDR's are sequential IP addresses), exclude the GIADDR address(es) from distribution, and then activate the scope. This will authorize the relay agents while preventing the GIADDR addresses from being assigned.


    Thursday, August 23, 2018 3:41 PM