Resolving hostnames in remote VPN network

  • Thread starter Thread starter Aaron Seet
  • Start date Start date
A

Aaron Seet

Either way when one logs in to the office network via VPN:

1. Logon local machine account first, then connect to VPN.
2. Logon domain account direct by dialling-up VPN.

The DNS/WINS settings of your machine at home (or elsewhere outside) will
tie in with your primary network adapter, and not your VPN PPP adapter (even
when there are settings assigned). Given such you can't resolve and locate
hosts within your office network. Everything will be resolved by your local
or ISP DNS/WINS servers.

How does one overcome this problem? Also, how can one allow NBT broadcast to
get beyond the RRAS server?


Aaron
 
That isn't strictly true. Your client will resolve names using the DNS
server across the link if the client is correctly configured. For this, the
client's connection properties need to have the correct DNS domain
suffix(es) as well as the DNS server IP.

LAN broadcasts do not usually cross WAN links or routers.
 
Take for example, my PC at home. Its network adapter uses ISP nameservers.
I'd of course have to use this network adapter to VPN back to my office. The
resulting PPP adapter does have its internal DNS/WINS servers settings.

However trying to ping an office host like server.internal.office.com will
have the ISP DNS servers try to resolve that, never using the DNS servers at
the VPN end. A trick I discovered to get NBT broadcasts to get through is to
explicitly append the "local" DNS suffix in the advanced DNS TCP/IP
properties. But that's NetBIOS and not DNS.

So how does one controller _which_ DNS server to query when there're
multiple adapters (multihomed)?




That isn't strictly true. Your client will resolve names using the DNS
server across the link if the client is correctly configured. For this, the
client's connection properties need to have the correct DNS domain
suffix(es) as well as the DNS server IP.

LAN broadcasts do not usually cross WAN links or routers.
 
You seem to have a strange idea about how broadcasts work. Adding a DNS
suffix will affect how DNS works, but will have no effect on LAN broadcasts
or Netbios over TCP/IP! Look at WINS. It uses Netbios names and is a "flat"
file. Only the name is significant. The only "suffixes" are the special
Netbios codes like 03 or 1c! (You are probably, in fact, getting a result
from WINS via DNS.)

In any case, if you are using WINS, you are not relying on Netbt
broadcasts for name resolution. Netbios names will be resolved by a direct
name server query to WINS, not by trying to broadcast. Perhaps you could
enable Netmon and have a look at what actually happens.

The problem of which connection is used for DNS was discussed recently
in the windows.server.dns newsgroup. Try posting a query in that newsgroup
on this topic.
 
I added the explicit "local" suffix (previously used "." with partial
success) to prevent the OS from using the domain's DNS suffix in its search.
The deal is this: the domain is like corp.company.com which is private in
the office and not known to the public Internet. However, company.com itself
is public. So when you'd attempt to locate an internal host like
workstation.corp.company.com - that gets resolved by the ISP nameservers at
my home end into the wildcard address for the public company.com and goes to
the IP address of the web server instead. Undesirable.

So now if "workstation.local" can't be resolved by ISP or home DNS servers,
I have seen it attempt to ping it with NetBios name "workstation" alone, and
getting the correct IP address at the office LAN. To correct myself, without
monitoring actual packets transmitted (can't now anyway), it appears the NBT
broadcast did get the VPN connection. But that is still NetBios. I'm at a
loss how one can force queries regarding the internal domain name to the
office internal DNS servers instead (associated with PPP adapter).

This situation also applies to router-router VPNs between 2 domains with
internal naming scheme - how can one network resolve the internal FQDNs of
the other network? Supposing in my current situation (where I control both),
I easily transfer zones mutually and that works nicely. But if I'd attempt
to connect with a client or partner or vendor domain, and zone transfers
aren't allowed?


thanks,
Aaron



You seem to have a strange idea about how broadcasts work. Adding a DNS
suffix will affect how DNS works, but will have no effect on LAN broadcasts
or Netbios over TCP/IP! Look at WINS. It uses Netbios names and is a "flat"
file. Only the name is significant. The only "suffixes" are the special
Netbios codes like 03 or 1c! (You are probably, in fact, getting a result
from WINS via DNS.)

In any case, if you are using WINS, you are not relying on Netbt
broadcasts for name resolution. Netbios names will be resolved by a direct
name server query to WINS, not by trying to broadcast. Perhaps you could
enable Netmon and have a look at what actually happens.

The problem of which connection is used for DNS was discussed recently
in the windows.server.dns newsgroup. Try posting a query in that newsgroup
on this topic.
 
Missed out a word. It should've been

"it appears the NBT broadcast did get through the VPN connection."



it appears the NBT broadcast did get the VPN connection.
 
Rather than a broadcast going through, it probably sent a name request to
your WINS server and got a reply. Requests to WINS servers are directed
requests, not broadcasts. They are not upset by routers or WAN links.

If your clients are configured as WINS clients, they should only try to
broadcast if the WINS request fails.
 
Regarding your router-to-router setup. Do you mean that you make each DNS
server a secondary for the primary zone(s) at the other site? That is the
way I would do it. All your private addresses can then be resolved by the
local server.
 
Yes I do that because I _have_ control of both networks. But what of a
network not under my jurisdiction? Am I to negotiate a zone transfer as a
"must" from the other network admin?

Or the more immediate problem I face - I still don't know how to "force" my
home client machine to use the DNS servers specified in the PPP adapter
settings, rather than the primary network adapter.


Aaron



Regarding your router-to-router setup. Do you mean that you make each DNS
server a secondary for the primary zone(s) at the other site? That is the
way I would do it. All your private addresses can then be resolved by the
local server.
 
As I said earlier, this has cropped up in the dns newsgroup and has been
answered. From memory, it has to do with the binding order of the
interfaces. Try posting that question in that group. There are some pretty
clued-up guys there.
 
There doesn't appear to be a dns group in Microsoft's server.



As I said earlier, this has cropped up in the dns newsgroup and has been
answered. From memory, it has to do with the binding order of the
interfaces. Try posting that question in that group. There are some pretty
clued-up guys there.
 
You can hard code the clients primary network adapter with your internal DNS
server first and their ISP DNS server second.
The DNS newsgroup will tell you the problem is because you have likely
duplicated your namespace internally and externally (yourcompany.com
internally, when yourcompany.com already exists on the Internet).
--

Thanks,
Marc Reynolds
Microsoft Technical Support

This posting is provided "AS IS" with no warranties, and confers no rights.
 
For some reason my OE cannot find these groups, I'd have to try elsewhere.
Thanks.



microsoft.public.windows.server.dns or microsoft.public.win2000.dns
 
Back
Top