Can anyone shed any light on whether it is possible to ensure that clients that are connected to the VPN, and are using the local Meraki DHCP server to obtain their client IP details (rather than helper set to forward requests to on-prem windows server DHCP server) can be registered somehow within the DNS server that runs on the on-prem Windows server/s (so that they can be managed via their hostname from the LAN referring to their up to date VPN IP address and not their old LAN IP from when they were last in the office and received a IP address from on-prem DHCP server which was of course registered in DNS)
Thanks very much
Solved! Go to solution.
It's possible - I have a similar setup.
These are domain-joined computers?
1) Make sure DNS scavenging is configured and working properly
2) In your VPN connection, look under "Networking | TCP/IP4 Properties | Advanced | DNS" and tick 'Register this connections address in DNS" (my particular setup is not domain joined, so I had to fill in the DNS suffix an tick 'use this connections DNS suffix in registration)
I don't think this will be possible
Thanks for your reply @CptnCrnch . I feared this may be the answer and suspect that the only way to get VPN clients registered in DNS on the Win server may be to change to forwarding DHCP requests for VPN clients to the Win svr DHCP server. Was hoping to avoid this for other config reasons.
@S_Ruffell_SBS wrote:Thanks for your reply @CptnCrnch . I feared this may be the answer and suspect that the only way to get VPN clients registered in DNS on the Win server may be to change to forwarding DHCP requests for VPN clients to the Win svr DHCP server. Was hoping to avoid this for other config reasons.
I don't believe you can change what acts as the DHCP server for VPN clients.
See: ASA where AnyConnect has an ip pool that's defined on the device itself.
It's possible - I have a similar setup.
These are domain-joined computers?
1) Make sure DNS scavenging is configured and working properly
2) In your VPN connection, look under "Networking | TCP/IP4 Properties | Advanced | DNS" and tick 'Register this connections address in DNS" (my particular setup is not domain joined, so I had to fill in the DNS suffix an tick 'use this connections DNS suffix in registration)
Thanks for reply @SJones .
Yes, they are W10 domain joined machines.
Yesterday I checked DNS scavenging enabled but it doesn't scavenge old records as it should (another whole new story - I believe a legacy non-existent DNS server is set as authority currently shown in dnscmd /zoneinfo ) - Joys of recently (just before lockdown) inheriting an organically changed and evolved infrastructure! Bit of tidying up to be done!
Thanks for the tip about adding 'register connection ...' hadn't seen that before. Is showing currently as unchecked so need to think about how best to possibly deploy that setting to remote clients (pretty much all our user-base!), whilst being slightly limited by the original problem and its effect on being able to remote manage/deploy via hostnames that are out of date on DNS. Will do some testing on that.
Thanks @ShenSimps for reply. Assume that is for alluserconnection which I think in our environment it almost certainly will be. Will do some testing on deployment, just hoping that my original quandary wont prevent me from remote execution of powershell command
I had to configure our script for this run the commands by remote PS:
Invoke-Command -ComputerName $Computer -ScriptBlock {"Commands here"}
I'm fairly certain IP address will work. If not, you could always create a hosts file on the machine you're using to run the command. If you have a ton to do, just download the VPN client list as CSV and do a quick edit of that to generate a temporary hosts file.
I am liking that idea @SJones . Thanks. a genius little workaround. then just reinstate empty(ish) hosts file after. Nice
With step 2, is there anyway to automate making that change across multiple laptops? A powershell or cmd script?
> the DNS server that runs on the on-prem Windows server/s
Absolutely. There is nothing special to be done here.
Once a client gets the DNS server address (which should be an AD controller) from DHCP it will send a DDNS packet to the AD controller to update its info.
The client doing this does not care weather this is a WiFi, LAN or client VPN connection.
Thanks for the reply @PhilipDAth . Whilst I certainly agree there isn't normally anything required for this to happen when clients obtain their IP via the LAN DHCP server (eg when connected to LAN or WLAN), I have found in my environment that when clients are connected to the Meraki VPN, and are assigned their IP from the internal DHCP to the Meraki, the on-prem DNS is completely unaware of these clients (even if they conduct DNS lookups via that server on the LAN), unless steps like those highlighted by @SJones and @ShenSimps above (ie force DNS registration with a config change to TCPIP protocol on VPN adapter). In the scenario you describe or have, does the Cisco/Meraki server DHCP ?