I'm trying to move away from a software-based VPN (LogMeIn Hamachi) for remote access to an L2TP VPN terminated at a v2762 internet router.
The tunnel works fine but clients cannot resolve device names on the LAN side, e.g. 'svr1' doesn't resolve to 192.168.x.y, whereas name resolution works fine via Hamachi.
To get M$ Remote Desktop to work the client has to specify the IP address of the server and this works fine but I'd like the VPN user to "feel at home" on the VPN.
The router does not run a DHCP server. Instead, addresses are issued by a LAN-side Windows server which issues its own address as the DNS server.

The problem appears to be because the VPN clients are given the router's DNS servers, which are those of the ISP rather than the ones provided by DHCP from the Windows server.
Why would the DrayTek be changing the DNS server addresses? Have I missed something that would make name resolution and Client for Microsoft Networks behave better?

Albertosaurus wrote:
Why would the DrayTek be changing the DNS server addresses? Have I missed something that would make name resolution and Client for Microsoft Networks behave better?

That is impressively weird (I take it the actual client IP address from the Windows DHCP Server is passed through OK)

I encountered a similar bug on the 2860 (now fixed), but in my case, the DHCP server was the router. Even better, though, was the fact that I do not use my ISP's DNS servers anywhere ... yet the VPN client was still given them.

Re: workarounds, you could hard-code the DNS server address on the clients (which would break things when not connected to the VPN) ... or enter the LAN addresses in an olde-worlde LMHOSTS file and distribute it to every client

(If you don't fancy an 80's solution, you could skip forward 10 years and implement a WINS server ... possibly on the machine that is the DHCP server)

Thanks, hornbyp. Maybe I'll exclude a small LAN address sub-range from being issued by DHCP from the Windows server and then enable DHCP on the router. That way I can regain control of everything being passed to the clients.

Maybe, maybe not ... but worth a shot.

I had the same symptoms when using only the Router as DHCP server. The Router itself was configured to use a DNS server on the LAN (which forwarded to OpenDNS). The DHCP scope was configured to specify this same internal DNS server. Yet, for quite a few firmware versions, the VPN clients were being given the ISP's DNS server addresses

Thanks, @hornbyp

Update: I looked into enabling DHCP on the router but found the option 'Enable Relay' in 'DHCP Server Configuration', then specified the Windows server address beneath it. This lets the Windows server assign one of its DHCP scope addresses as usual, with only the following oddities, as shown by ipconfig:
- Autoconfiguration Enabled . . . . : Yes
- Subnet Mask . . . . . . . . . . . : 255.255.255.255 < not so sure about this.
- Default Gateway . . . . . . . . : 0.0.0.0
- DNS Servers . . . . . . . . . . . : ... the Windows server address is the 3rd in the list, after the ISP DNS addresses whereas I would expect it to be first.

Ping of remote IPv4 addresses still works but DNS resolution on the remote network doesn't work, even for FQDN names.
I'll look further...

Yes, I think the Windows DNS servers do need to be listed first, because AIUI, subsequent DNS servers are only queried if there is no response (at all) from the earlier ones.

(So if the ISP DNS server responds and says "non-existent domain", that's the end of the query)