Wireshark is a steep learning curve for me so I went looking for alternatives and found DHCP Test Client at http://www.ingmarverheij.com/read-dhcp-options-received-by-the-client/ .

I connected a PC to my domain, via different ISP, using VPN and it was given an IP 192.168.42.245 in the range controlled by the router as set in PPP General Setup.

The router just issued an IP address but not details of domain DNS / WINS server so the client experience is much different to the one it has when connected directly ( not over VPN )

I then ran DHCP Test Client. It sent out a "DHCP Discover Packet" and received an offer from 192.168.42.2:67 (the router) with 192.168.42.11 (the DHCP server) as the Server Identifier. The WS2012 DHCP did not NAK nor did it register the IP address in local DNS.

The DHCP Test Client output was:

dhcptest v0.7 - Created by Vladimir Panteleev
https://github.com/CyberShadow/dhcptest
Run with --help for a list of command-line options.

Listening for DHCP replies on port 68.
Type "d" to broadcast a DHCP discover packet, or "help" for details.
d
Sending packet:
op=BOOTREQUEST chaddr=22:A3:92:94:87:3B hops=0 xid=49E046C0 secs=0 flags=8000
ciaddr=0.0.0.0 yiaddr=0.0.0.0 siaddr=0.0.0.0 giaddr=0.0.0.0 sname= file=
1 options:
53 (DHCP Message Type): discover
Received packet from 192.168.42.2:67:
op=BOOTREPLY chaddr=22:A3:92:94:87:3B hops=0 xid=49E046C0 secs=0 flags=8000
ciaddr=0.0.0.0 yiaddr=192.168.42.56 siaddr=192.168.42.11 giaddr=192.168.42.2 sname= file=
6 options:
53 (DHCP Message Type): offer
1 (Subnet Mask): 255.255.255.0
58 (Renewal (T1) Time Value): 345600 (4 days)
59 (Rebinding (T2) Time Value): 604800 (1 week)
51 (IP Address Lease Time): 691200 (1 week and 1 day)
54 (Server Identifier): 192.168.42.11


When I connect the PC to the network locally I get a similar output from DHCP Test Client

Listening for DHCP replies on port 68.
Type "d" to broadcast a DHCP discover packet, or "help" for details.
d
Sending packet:
op=BOOTREQUEST chaddr=09:6A:37:D6:ED:5F hops=0 xid=312AEE64 secs=0 flags=8000
ciaddr=0.0.0.0 yiaddr=0.0.0.0 siaddr=0.0.0.0 giaddr=0.0.0.0 sname= file=
1 options:
53 (DHCP Message Type): discover
Received packet from 192.168.42.2:67:
op=BOOTREPLY chaddr=09:6A:37:D6:ED:5F hops=0 xid=312AEE64 secs=0 flags=8000
ciaddr=0.0.0.0 yiaddr=192.168.42.52 siaddr=192.168.42.11 giaddr=192.168.42.2 sname= file=
6 options:
53 (DHCP Message Type): offer
1 (Subnet Mask): 255.255.255.0
58 (Renewal (T1) Time Value): 345600 (4 days)
59 (Rebinding (T2) Time Value): 604800 (1 week)
51 (IP Address Lease Time): 691200 (1 week and 1 day)
54 (Server Identifier): 192.168.42.11

Does that help at all?

billatkins wrote: I connected a PC to my domain, via different ISP, using VPN and it was given an IP 192.168.42.245 in the range controlled by the router as set in PPP General Setup.

The router just issued an IP address but not details of domain DNS / WINS server so the client experience is much different to the one it has when connected directly ( not over VPN )

I then ran DHCP Test Client. It sent out a "DHCP Discover Packet" and received an offer from 192.168.42.2:67 (the router) with 192.168.42.11 (the DHCP server) as the Server Identifier. The WS2012 DHCP did not NAK nor did it register the IP address in local DNS.

To summarise - so I'm clear...

The IP address offered to the VPN client came from the Router's own range, designated for "Dial-In users", rather than the WS2012 DHCP server. However, subsequently running the diagnostic tool elicited the expected response from the WS2012 server, via the DHCP Relay Agent.

This might explain the "NAK" you found in the WS2012's log and why the diagnostic tool didn't generate one...

...the diagnostic tool doesn't actually issue the the DHCP REQUEST - it only goes as far as soliciting OFFERs. But if you were to manually request a lease renewal (using IPCONFIG /RENEW) - or if the VPN client was connected long enough for this to happen automatically - that request would go to the 'wrong' server (i.e. not the one that actually issued it in the first place) and it would NAK it. [The theory being, that at some point after the VPN has connected, the router's DHCP Relay Agent finally kicks into action, so the original DHCP 'server' is no longer available and a new one takes over the role]

If correct, then issuing a "IPCONFIG /RELEASE followed by IPCONFIG /RENEW" after it has been given the wrong IP address might work around things. (Or at least, start to work around things!)

I filtered BOOTP/DHCP in Wireshark and can see the DHCP server offering but then responding to the request with a NAK.

is 105 11.957720 192.168.42.2 192.168.42.11 DHCP 342 DHCP Discover - Transaction ID 0xa
106 11.958227 192.168.42.11 192.168.42.2 DHCP 360 DHCP Offer - Transaction ID 0xa
107 11.958490 192.168.42.2 192.168.42.11 DHCP 327 DHCP Request - Transaction ID 0xa
108 11.958807 192.168.42.11 192.168.42.2 DHCP 342 DHCP NAK - Transaction ID 0xa

There is an entry in the DHCP server log:

15,02/14/18,13:35:59,NACK,192.168.42.53,,020AAA55EF98,,0,6,,,,,,,,,0

This could suggest an alternative theory - that the Router is getting involved, because it "knows" the REQUEST via DHCP Relay was NAK'd

Drilling down into those Wireshark packets, might reveal what is wrong with them - i.e. what the DHCP Server is taking objection to. (On the face of it, it looks odd - because it offers something that it then refuses to honour ... you'd think there must be a reason for that).

There's a concise overview of DHCP Relay Agents here: http://www.itgeared.com/articles/1112-dhcp-relay-agent/ . The video itself is not that pertinent.

To recap on the MAC addresses. We had assumed that the Mac address shown in DHCP logon as NAK’d: 02:0A:AA:55:EF:98 was fabricated by router but Wireshark shows only the Draytek LAN MAC address: 00:1d:aa:55:ef:98 & WS2012 server MAC address: 00:30:18:c1:7e:d1 in the exchange.

The additional info from Wireshark is:

Frame 105: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Draytek_55:ef:98 (00:1d:aa:55:ef:98), Dst: JetwayIn_c1:7e:d1 (00:30:18:c1:7e:d1)
Internet Protocol Version 4, Src: 192.168.42.2, Dst: 192.168.42.11
User Datagram Protocol, Src Port: 67, Dst Port: 67
Bootstrap Protocol (Discover)

Frame 106: 360 bytes on wire (2880 bits), 360 bytes captured (2880 bits) on interface 0
Ethernet II, Src: JetwayIn_c1:7e:d1 (00:30:18:c1:7e:d1), Dst: Draytek_55:ef:98 (00:1d:aa:55:ef:98)
Internet Protocol Version 4, Src: 192.168.42.11, Dst: 192.168.42.2
User Datagram Protocol, Src Port: 67, Dst Port: 67
Bootstrap Protocol (Offer)

Frame 107: 327 bytes on wire (2616 bits), 327 bytes captured (2616 bits) on interface 0
Ethernet II, Src: Draytek_55:ef:98 (00:1d:aa:55:ef:98), Dst: JetwayIn_c1:7e:d1 (00:30:18:c1:7e:d1)
Internet Protocol Version 4, Src: 192.168.42.2, Dst: 192.168.42.11
User Datagram Protocol, Src Port: 67, Dst Port: 67
Bootstrap Protocol (Request)

Frame 108: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: JetwayIn_c1:7e:d1 (00:30:18:c1:7e:d1), Dst: Draytek_55:ef:98 (00:1d:aa:55:ef:98)
Internet Protocol Version 4, Src: 192.168.42.11, Dst: 192.168.42.2
User Datagram Protocol, Src Port: 67, Dst Port: 67
Bootstrap Protocol (NAK)

If we could understand why the WS2012 DHCP is offering to service the Discover request and then NAK'ing but writing a different MAC address in its log it might help. The exchanges between the router and the WS2012 DHCP server are very similar regardless of whether the client is on the LAN or trying to join via VPN.

billatkins wrote: If we could understand why the WS2012 DHCP is offering to service the Discover request and then NAK'ing but writing a different MAC address in its log it might help.

There should be a "> " to the left of Bootstrap Protocol. If you click that, it should spit out an analysis of each of the fields, within the packet. The answer ought to lie somewhere within...