SQUIRRR
asked on
Question About DNS Resolution/Priority
Why do our remote VPN users try to resolve DNS externally (via home router, which does external lookups) before resolving internally within the VPN accessed LAN?
Office set-up: 2 Windows 2003 DCs (SERVER1B, SERVER1L), 1 Windows 2003 Server with Exchange 2003 (EXCHANGE), 2 Windows 2000 Servers as resource servers (SERVER1, SERVER2). The 2 DCs are DNS Servers; SERVER1B is RRAS/VPN server; SERVER1L is DHCP server. SERVER1B's NIC points to SERVER1L for DNS (shouldn't point to itself), SERVER1L's NIC points to SERVER1B for its DNS.
Externally hosted DNS is a service provider, and defines our external facing access (e.g., mail service A and MX records, web site, ftp site, etc.).
Internal units all use internal DNS (1B, 1L) as configured by DHCP. Our DNS servers forward unresolved to our office router; the office router forwards to opendns.com to resolve external domains/addresses. Office Router points incoming VPN/RRAS traffic at SERVER1B.
Remote user has COMPUTER-C (WIN2K Pro), a domain member, at her home, configured for DHCP, with a home router and cable ISP. She VPNs to our Office successfully, receiving a DHCP address from the VPN/RRAS server. She cannot connect to our EXCHANGE server because her COMPUTER-C is going to her cable ISP (via her home router, which forwards unresolved to the ISP) for name resolution before going to the internal DNS servers. At our External DNS, EXCHANGE is configured with our exposed/public IP (e.g., 6.7.8.9) whereas internally it has our NAT address (e.g., 192.168.0.7 ). Naturally, with a resolved address of 6.7.8.9, she cannot reach 192.168.0.7 …
WHY is COMPUTER-C going to the external DNS before resolving its IP needs internally ? With MS VPN, shouldn't all IP traffic be routed through the VPN tunnel first ?
Is there a way to force COMPUTER-C to use, when connected, the internal DNS before using its local LAN/home network's DNS to avoid external resolution ?
Office set-up: 2 Windows 2003 DCs (SERVER1B, SERVER1L), 1 Windows 2003 Server with Exchange 2003 (EXCHANGE), 2 Windows 2000 Servers as resource servers (SERVER1, SERVER2). The 2 DCs are DNS Servers; SERVER1B is RRAS/VPN server; SERVER1L is DHCP server. SERVER1B's NIC points to SERVER1L for DNS (shouldn't point to itself), SERVER1L's NIC points to SERVER1B for its DNS.
Externally hosted DNS is a service provider, and defines our external facing access (e.g., mail service A and MX records, web site, ftp site, etc.).
Internal units all use internal DNS (1B, 1L) as configured by DHCP. Our DNS servers forward unresolved to our office router; the office router forwards to opendns.com to resolve external domains/addresses. Office Router points incoming VPN/RRAS traffic at SERVER1B.
Remote user has COMPUTER-C (WIN2K Pro), a domain member, at her home, configured for DHCP, with a home router and cable ISP. She VPNs to our Office successfully, receiving a DHCP address from the VPN/RRAS server. She cannot connect to our EXCHANGE server because her COMPUTER-C is going to her cable ISP (via her home router, which forwards unresolved to the ISP) for name resolution before going to the internal DNS servers. At our External DNS, EXCHANGE is configured with our exposed/public IP (e.g., 6.7.8.9) whereas internally it has our NAT address (e.g., 192.168.0.7 ). Naturally, with a resolved address of 6.7.8.9, she cannot reach 192.168.0.7 …
WHY is COMPUTER-C going to the external DNS before resolving its IP needs internally ? With MS VPN, shouldn't all IP traffic be routed through the VPN tunnel first ?
Is there a way to force COMPUTER-C to use, when connected, the internal DNS before using its local LAN/home network's DNS to avoid external resolution ?
Last Comment
You can see why you might have issues with the article on this web site.
http://www.isaserver.org/tutorials/work-around-VPN-clients-split-DNS.html
http://www.isaserver.org/tutorials/work-around-VPN-clients-split-DNS.html
ASKER
RDAdams, thanks but no-go. Already did a reasonable web search before coming here, and already viewed the ISA link ... even though we aren't using ISA ... and tried some of those hints.
Please note that RESOLUTION does take place but it gets its ip address from OUTSIDE instead of inside. If I delete the A record from the external DNS host, COMPUTER-C has no choice and then finds the NAT address from the internal DNS.
I'm trying to figure out how to get the remote machine, connected by VPN, to use our internal DNS for resolution exclusively. It should NOT be finding the external IP address via opendns (which goes to our NS and looks up the A record).
In your first answer, we are always using FQDN ... because Outlook, for example, will register the FQDN of the Exchange Server and won't accept any other name ... even if you input the IP address of the server into Outlook's profile, it resolves itself and records the FQDN anyway.
Good try though ... perhaps i underrated/undervalued this question ...
Please note that RESOLUTION does take place but it gets its ip address from OUTSIDE instead of inside. If I delete the A record from the external DNS host, COMPUTER-C has no choice and then finds the NAT address from the internal DNS.
I'm trying to figure out how to get the remote machine, connected by VPN, to use our internal DNS for resolution exclusively. It should NOT be finding the external IP address via opendns (which goes to our NS and looks up the A record).
In your first answer, we are always using FQDN ... because Outlook, for example, will register the FQDN of the Exchange Server and won't accept any other name ... even if you input the IP address of the server into Outlook's profile, it resolves itself and records the FQDN anyway.
Good try though ... perhaps i underrated/undervalued this question ...
ASKER CERTIFIED SOLUTION
THIS SOLUTION IS ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
Run the same tests to see if you have a similar issue.
ASKER
Thanks i will try this. Excerpted from your link, perhaps i can solve it as indicated: "After some further research I was guided to the Microsoft Knowledge Base article 311218 - Cannot Change the Binding Order for Remote Access Connections. That KB holds the key to a workaround. Nevertheless, keep in mind it is still a defect in the Microsoft OS and as far as I know there are no plans to fix it. "
I'll give it a try thanks.
I'll give it a try thanks.
Thanks for the points. Were you able to resolve the issue?
ASKER
Good article RDAdams, exceptionally well documented, thanks. Resolved.
SQUIRRR, thank you for your question, I have the exact same problem
and RDAdams thank you for your link to your solution, it worked and now I am happily VPNed to my work.
Now I need to put the script into Group Policies, so all our users get it.
Thanks again.
and RDAdams thank you for your link to your solution, it worked and now I am happily VPNed to my work.
Now I need to put the script into Group Policies, so all our users get it.
Thanks again.
Networking
Networking is the process of connecting computing devices, peripherals and terminals together through a system that uses wiring, cabling or radio waves that enable their users to communicate, share information and interact over distances. Often associated are issues regarding operating systems, hardware and equipment, cloud and virtual networking, protocols, architecture, storage and management.
102K
Questions
--
Followers
--
Top Experts
Get a personalized solution from industry experts
TRUSTED BY
Can ping FQDN but not host name
Symptoms: after establishing VPN, you can't ping the server name. However, you can ping FQDN, for example, server1.chicagotech.net.
Cause: Missing the DNS suffixes
Can't ping VPN client by name
Symptom: you can ping the vpn client by ip but when attempting to ping a vpn client from remote LAN, you get time out.
Resolution: 1) if you have correct DNS and WINS settings, you should be able to ping vpn client by name.
2) If you get the time out with a different ip (for example, ping ip is 192.168.100.7 and real ip is 192.168.100.13), check the dns and wins records and delete the 192.168.100.7.
3) If the dns and wins records don't show the client record, make sure it points to the same and correct dns and wins.
4) If the VPN client doesn't register its DNS, you may need to go the VPN connection properties>networking>TCP/
5) Also make sure all computers are pointing to the same DNS