Thanks. I am new to Wireshark. I have expanded the Bootstrap Protocol parts of packets 107 & 108. 107 was requesting 192.168.42.53 which is the next IP the WS2012 DHCP server had to offer. 108 replies with a NAK. Can you see why?

Frame 107:
Bootstrap Protocol (Request)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x0000000a
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0
Your (client) IP address: 0.0.0.0
Next server IP address: 0.0.0.0
Relay agent IP address: 192.168.42.2
Client MAC address: MS-NLB-PhysServer-10_aa:55:ef:98 (02:0a:aa:55:ef:98)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Request)
Length: 1
DHCP: Request (3)
Option: (50) Requested IP Address
Length: 4
Requested IP Address: 192.168.42.53
Option: (255) End
Option End: 255
Padding: 0f2ce2ee98335e4c94cf1b04ca2a816122eaad7ff1bc5d34...


Frame 108:
Bootstrap Protocol (NAK)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x0000000a
Seconds elapsed: 0
Bootp flags: 0x8000, Broadcast flag (Broadcast)
1... .... .... .... = Broadcast flag: Broadcast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0
Your (client) IP address: 0.0.0.0
Next server IP address: 0.0.0.0
Relay agent IP address: 192.168.42.2
Client MAC address: MS-NLB-PhysServer-10_aa:55:ef:98 (02:0a:aa:55:ef:98)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (NAK)
Length: 1
DHCP: NAK (6)
Option: (54) DHCP Server Identifier
Length: 4
DHCP Server Identifier: 192.168.42.11
Option: (255) End
Option End: 255
Padding: 000000000000000000000000000000000000000000000000...

Expansion of the Bootstrap Protocol of the Request packet of the same client negotiating with the WS2012 DHCP when connected directly (not over VPN). The Request has more information in it about the client. Over VPN there are only three options (53, 50 & 255). In the Request over the LAN there are eight options (53, 61, 50, 12, 81, 60, 55 & 255). Option 55 has 13 parameter requests.

Bootstrap Protocol (Request)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0xa6310e0e
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0
Your (client) IP address: 0.0.0.0
Next server IP address: 0.0.0.0
Relay agent IP address: 192.168.42.2
Client MAC address: LiteonTe_bb:bd:fc (68:a3:c4:bb:bd:fc)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Request)
Length: 1
DHCP: Request (3)
Option: (61) Client identifier
Length: 7
Hardware type: Ethernet (0x01)
Client MAC address: LiteonTe_bb:bd:fc (68:a3:c4:bb:bd:fc)
Option: (50) Requested IP Address
Length: 4
Requested IP Address: 192.168.42.77
Option: (12) Host Name
Length: 15
Host Name: PROBOOK-4530S-B
Option: (81) Client Fully Qualified Domain Name
Length: 34
Flags: 0x00
0000 .... = Reserved flags: 0x0
.... 0... = Server DDNS: Some server updates
.... .0.. = Encoding: ASCII encoding
.... ..0. = Server overrides: No override
.... ...0 = Server: Client
A-RR result: 0
PTR-RR result: 0
Client name: PROBOOK-4530S-B.yyy.uk.com
Option: (60) Vendor class identifier
Length: 8
Vendor class identifier: MSFT 5.0
Option: (55) Parameter Request List
Length: 13
Parameter Request List Item: (1) Subnet Mask
Parameter Request List Item: (3) Router
Parameter Request List Item: (6) Domain Name Server
Parameter Request List Item: (15) Domain Name
Parameter Request List Item: (31) Perform Router Discover
Parameter Request List Item: (33) Static Route
Parameter Request List Item: (43) Vendor-Specific Information
Parameter Request List Item: (44) NetBIOS over TCP/IP Name Server
Parameter Request List Item: (46) NetBIOS over TCP/IP Node Type
Parameter Request List Item: (47) NetBIOS over TCP/IP Scope
Parameter Request List Item: (121) Classless Static Route
Parameter Request List Item: (249) Private/Classless Static Route (Microsoft)
Parameter Request List Item: (252) Private/Proxy autodiscovery
Option: (255) End
Option End: 255

Whatever it is, it's not obvious, is it?

The REQUEST from the LAN is obviously much more comprehensive than the one from the VPN - it makes you wonder how much information would make it through the Relay Agent, even if it were to complete. As an aside, did you try the "IPCONFIG /RELEASE + IPCONFIG /RENEW", when connected by VPN?. I'm now very doubtful it would work, but it's one more to tick off.

One thing that did strike me, is that this is not the normal scenario for a Relay Agent, because the VPN client isn't on a different subnet to the DHCP Server. I'm wondering if WS2012 DHCP server is also realising this? I'm pondering whether you need a totally different scope for VPN clients, forcing them onto their own subnet? (As in, set the Dial-in users to use a new "LAN", with DHCP Relay Agent configured for that new LAN, instead of your main one).

I note with interest that the Relay Agent's IP address, is still in the REQUEST message from the LAN attached client, probably because it's listening to the LAN and getting involved there as well... It could well be, that some of your LAN clients are getting their leases via that route...it would probably just come down to timing.

Is there anything in the Eventlog from DHCPserver, as a matter of interest?

I came across use of the Microsoft Message Analyzer tool (never heard of it before!), to analyse such problems - but obviously, it would be yet another learning curve.

Have you considered using the WS2012 machine as the VPN end-point; rather than the Vigor? ... I think I would be tempted ...

I'm rapidly coming to the conclusion that this is a Draytek bug...

If I use the SmartVPN client on my Android phone - and target a Dial-in user on a Vigor 2830n, who is configured for [LAN1], it uses the DHCP settings for [LAN1] (The Vigor's own DHCP server, in my case). An IP address is returned from the DHCP range and crucially (for me) the configured DNS server addresses - which are internal to the network. The only slight oddity, is that the Bind to MAC settings aren't honoured - because it uses one of the Router's own MAC addresses for the DHCP request.

If you do the same thing to a Vigor 2860n, the IP address issued might come from the DHCP range, or it might come from the "PPP General Setup" range, seemingly at random. The DNS servers returned are those of my ISP - which I do not use anywhere!

I went a step further and disabled the DHCP server on the 2860n and configured [LAN1] to use a DHCP Relay Agent to another DHCP Server - so this is starting to look more like your setup.

This was completely transparent as far as LAN and WiFi clients were concerned - they should (but may not!) have been finding the new DHCP Server on the LAN directly - but it failed to use it for Dial-in VPN usage.

If I try and set a static IP in the SmartVPN Client, it won't connect at all - I can see the 2860n studiously ignoring it and doing its own thing.

(Fortunately for me, I can manually configure the correct DNS server in the Smart VPN client and the IP address received is not critical...)

This post from Cisco suggests what I am trying to achieve is possible https://www.cisco.com/c/en/us/support/docs/switches/nexus-9000-series-switches/200248-Configuring-Microsoft-Windows-Server-201.html but unfortunately a Nexus 900 Series switch is way over my budget. The article is about virtual servers but if they have got that working then physical servers should be easier.
I have tried IPConfig release and then renew. Also, having a separate LAN/subnet for VPN clients and adding a separate scope on WS2012 DHCP server for them. Still getting IP's from Draytek.
The WS2012 DCHP server trusts the Draytek relay agent enough to respond to a discovery but not enough to issue an IP on the basis of the information contained in the Request. So either I have not set the correct DHCP options or the correct policies on the WS2012 server or the draytek relay agent is not up to negotiating with a WS2012R2 DHCP ( by not sending enough data). To be fair to Draytek it works fine with a non MS DCHP server. But that does not support the outcome I want to achieve of synchronising roaming profiles / WINS etc.
I am going to contact Draytek support and see if I can get anywhere with them. Thanks to your responses I have got a good understanding of the issues. If that is not successful I will look at other routers. I really do not want to use the WS2012 as a VPN endpoint. Too close to home!
I will post again if I have any success. Thanks.

billatkins wrote: This post from Cisco suggests what I am trying to achieve is possible https://www.cisco.com/c/en/us/support/docs/switches/nexus-9000-series-switches/200248-Configuring-Microsoft-Windows-Server-201.html

That post just makes me feel inadequate

He also wrote: The WS2012 DCHP server trusts the Draytek relay agent enough to respond to a discovery but not enough to issue an IP on the basis of the information contained in the Request. So either I have not set the correct DHCP options or the correct policies on the WS2012 server or the draytek relay agent is not up to negotiating with a WS2012R2 DHCP ( by not sending enough data).

I agree.

and in addition, he wrote: To be fair to Draytek it works fine with a non MS DCHP server.

You got further than I managed. My "non MS DHCP Server" was actually an old 2830n, but it wouldn't cooperate.