Sign in with
Sign up | Sign in
Your question

Problem with DNS over VPN

Last response: in Windows 2000/NT
Share
April 16, 2005 3:52:30 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

Domain Name: lenderservices.local
Server: Windows 2003 SBS 192.168.168.2

DNS: Single AD integrated zone lenderservices.local (no . zone)
Configured for forwarding to ISP DNS servers

Location #1 contains the server, subnet 192.168.168.0/24
Location #2 contains no server, subnet 192.168.0.0/24

Location #1 & 2 are connected via a gateway-gateway VPN

Clients at location #2 are configured with static addresses pointing DNS to
192.168.168.2

Clients at location #2 are able to resolve hostnames but not FQDN names
Clients at location #2 are unable to resolve the majority of external DNS
requests

When attempting to NSLOOKUP from a client at location #2, the response is:

DNS request timed out.
timeout was 2 seconds.
*** Can't find server name for address 192.168.168.2: Timed out
*** Default servers are not available
Default Server: UnKnown
Address: 192.168.168.2


Any help would be appreciated. The only temporary resolution I have found
to this is to add a secondary DNS of the local router which resolves the
problem of looking up external addresses but does not resolve the problem
of being unable to resolve FQDN and also seems to prevent them from
accessing the local web server.

More about : problem dns vpn

Anonymous
April 17, 2005 7:54:15 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

"adamofevil" wrote in message
news:Xns963A97500C27Aadamofevil@207.46.248.16...
: Domain Name: lenderservices.local
: Server: Windows 2003 SBS 192.168.168.2
:
: DNS: Single AD integrated zone lenderservices.local (no . zone)
: Configured for forwarding to ISP DNS servers
:
: Location #1 contains the server, subnet 192.168.168.0/24
: Location #2 contains no server, subnet 192.168.0.0/24
:
: Location #1 & 2 are connected via a gateway-gateway VPN
:
: Clients at location #2 are configured with static addresses pointing DNS
to
: 192.168.168.2
:
: Clients at location #2 are able to resolve hostnames but not FQDN names
: Clients at location #2 are unable to resolve the majority of external DNS
: requests
:
: When attempting to NSLOOKUP from a client at location #2, the response is:
:
: DNS request timed out.
: timeout was 2 seconds.
: *** Can't find server name for address 192.168.168.2: Timed out
: *** Default servers are not available
: Default Server: UnKnown
: Address: 192.168.168.2
:
:
: Any help would be appreciated. The only temporary resolution I have found
: to this is to add a secondary DNS of the local router which resolves the
: problem of looking up external addresses but does not resolve the problem
: of being unable to resolve FQDN and also seems to prevent them from
: accessing the local web server.

What local web server. a web server at location #1, is not local if
workstations at location #2 are trying to access it. Is there a reason you
don't have DNS at location #2?

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Online Support for IT Professionals -
http://support.microsoft.com/servicedesks/technet/defau...
How-to: Windows 2000 DNS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;308201
FAQ W2K/2K3 DNS:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;291382
Anonymous
April 17, 2005 8:49:00 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

"adamofevil" <adamofevil@nospam.optonline.net> wrote in message
news:Xns963A97500C27Aadamofevil@207.46.248.16...
> Domain Name: lenderservices.local
> Server: Windows 2003 SBS 192.168.168.2
>
> DNS: Single AD integrated zone lenderservices.local (no . zone)
> Configured for forwarding to ISP DNS servers
>
> Location #1 contains the server, subnet 192.168.168.0/24
> Location #2 contains no server, subnet 192.168.0.0/24
>
> Location #1 & 2 are connected via a gateway-gateway VPN

May we presume the VPN routes in general and is unfiltered?
Ping, telnet server 80, etc.?

> Clients at location #2 are configured with static addresses pointing DNS
to
> 192.168.168.2

So they must get DNS requests fulfilled across the WAN/VPN?

Not illegal but slow probably.

> Clients at location #2 are able to resolve hostnames but not FQDN names

This sounds like they are using broadcasts to resolve the simple
computer names through NetBIOS and failing to resolve DNS
names with suffixes (FQDN means something different that you
believe).

What about the computer DNS names in the System Control panel?
Are they named fully? (Not just "computer" but "computer.domain.com"?)
They need to be.

> Clients at location #2 are unable to resolve the majority of external DNS
> requests

What does the following give:

nslookup DC_NAME.lenderservices.local

(Copy and paste the full answer and request, do not type it, and please
don't use pictures of the screen.)

See if the following is different:
nslookup DC_NAME.lenderservices.local 192.168.168.2

> When attempting to NSLOOKUP from a client at location #2, the response is:
>
> DNS request timed out.
> timeout was 2 seconds.
> *** Can't find server name for address 192.168.168.2: Timed out
> *** Default servers are not available

The above MAY be perfectly normal -- this is an artifact
of the way that NSLookup works in looking up the NAME
of the server that is being used.

All that REALLY matters is if you get the right answer to
the question (so show your commands also).

The following may be part of the above, or an actual problem,
but without the full question/response we cannot tell:

> Default Server: UnKnown
> Address: 192.168.168.2
>

> Any help would be appreciated. The only temporary resolution I have found
> to this is to add a secondary DNS of the local router which resolves the
> problem of looking up external addresses but does not resolve the problem
> of being unable to resolve FQDN and also seems to prevent them from
> accessing the local web server.

Clients must NOT use multiple DNS servers that do not
return the same answer, so your temporary solution is
going to cause trouble even if you fix the real problem.

The following is not specific to your problem (see above),
but it may be of help now or later:

Full checklist for DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2
4) If you have more than one Domain, every DNS server must
be able to resolve ALL domains (either directly or indirectly)

netdiag /fix

....or maybe:

dcdiag /fix

(Win2003 can do this from Support tools):
nltest /dsregdns /server:D C-ServerNameGoesHere
http://support.microsoft.com/kb/q260371/

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Single Label domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]
Related resources
Anonymous
April 18, 2005 3:01:04 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

"Roland Hall" <nobody@nowhere> wrote in
news:o Yr3e#4QFHA.904@tk2msftngp13.phx.gbl:

> "adamofevil" wrote in message
> news:Xns963A97500C27Aadamofevil@207.46.248.16...
>: Domain Name: lenderservices.local
>: Server: Windows 2003 SBS 192.168.168.2
>:
>: DNS: Single AD integrated zone lenderservices.local (no . zone)
>: Configured for forwarding to ISP DNS servers
>:
>: Location #1 contains the server, subnet 192.168.168.0/24
>: Location #2 contains no server, subnet 192.168.0.0/24
>:
>: Location #1 & 2 are connected via a gateway-gateway VPN
>:
>: Clients at location #2 are configured with static addresses pointing
>: DNS
> to
>: 192.168.168.2
>:
>: Clients at location #2 are able to resolve hostnames but not FQDN
>: names Clients at location #2 are unable to resolve the majority of
>: external DNS requests
>:
>: When attempting to NSLOOKUP from a client at location #2, the
>: response is:
>:
>: DNS request timed out.
>: timeout was 2 seconds.
>: *** Can't find server name for address 192.168.168.2: Timed out
>: *** Default servers are not available
>: Default Server: UnKnown
>: Address: 192.168.168.2
>:
>:
>: Any help would be appreciated. The only temporary resolution I have
>: found to this is to add a secondary DNS of the local router which
>: resolves the problem of looking up external addresses but does not
>: resolve the problem of being unable to resolve FQDN and also seems to
>: prevent them from accessing the local web server.
>
> What local web server. a web server at location #1, is not local if
> workstations at location #2 are trying to access it. Is there a
> reason you don't have DNS at location #2?
>

Yes the web server is at location #1 (all services are located on one SBS
server) but all clients home page is http://companyweb which in DNS is
pointing to the private IP 192.168.168.2. So I don't understand why the
computers at location #2 are having trouble getting to it, with their only
DNS server being 192.168.168.2.
April 19, 2005 3:09:16 AM

Archived from groups: microsoft.public.win2000.dns (More info?)

"Herb Martin" <news@LearnQuick.com> wrote in
news:o 7i$ug5QFHA.2356@TK2MSFTNGP14.phx.gbl:

> "adamofevil" <adamofevil@nospam.optonline.net> wrote in message
> news:Xns963A97500C27Aadamofevil@207.46.248.16...
>> Domain Name: lenderservices.local
>> Server: Windows 2003 SBS 192.168.168.2
>>
>> DNS: Single AD integrated zone lenderservices.local (no . zone)
>> Configured for forwarding to ISP DNS servers
>>
>> Location #1 contains the server, subnet 192.168.168.0/24
>> Location #2 contains no server, subnet 192.168.0.0/24
>>
>> Location #1 & 2 are connected via a gateway-gateway VPN
>
> May we presume the VPN routes in general and is unfiltered?
> Ping, telnet server 80, etc.?

Yes. Ping, telnet, RDP and everything else under the sun seems to work
fine through the VPN.

>> Clients at location #2 are configured with static addresses pointing
>> DNS
> to
>> 192.168.168.2
>
> So they must get DNS requests fulfilled across the WAN/VPN?
>
> Not illegal but slow probably.

Well there are only 4 workstations at location #2, so I didn't see the
need to recommend another server at that location. They should still be
able to get DNS over the WAN though, and it just doesn't seem to work
properly.

>> Clients at location #2 are able to resolve hostnames but not FQDN
>> names
>
> This sounds like they are using broadcasts to resolve the simple
> computer names through NetBIOS and failing to resolve DNS
> names with suffixes (FQDN means something different that you
> believe).
>
> What about the computer DNS names in the System Control panel?
> Are they named fully? (Not just "computer" but
> "computer.domain.com"?) They need to be.

They are all computer.lenderservices.local

>> Clients at location #2 are unable to resolve the majority of external
>> DNS requests
>
> What does the following give:
>
> nslookup DC_NAME.lenderservices.local
>
> (Copy and paste the full answer and request, do not type it, and
> please don't use pictures of the screen.)

C:\Documents and Settings\abrass>nslookup server.lenderservices.local
DNS request timed out.
timeout was 2 seconds.
*** Can't find server name for address 192.168.168.2: Timed out
*** Default servers are not available
Server: UnKnown
Address: 192.168.168.2

DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out

C:\Documents and Settings\abrass>

> See if the following is different:
> nslookup DC_NAME.lenderservices.local 192.168.168.2

C:\Documents and Settings\abrass>nslookup server.lenderservices.local
192.168.1
68.2
DNS request timed out.
timeout was 2 seconds.
*** Can't find server name for address 192.168.168.2: Timed out
Server: UnKnown
Address: 192.168.168.2

DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out

C:\Documents and Settings\abrass>

>> When attempting to NSLOOKUP from a client at location #2, the
>> response is:
>>
>> DNS request timed out.
>> timeout was 2 seconds.
>> *** Can't find server name for address 192.168.168.2: Timed out
>> *** Default servers are not available
>
> The above MAY be perfectly normal -- this is an artifact
> of the way that NSLookup works in looking up the NAME
> of the server that is being used.
>
> All that REALLY matters is if you get the right answer to
> the question (so show your commands also).
>
> The following may be part of the above, or an actual problem,
> but without the full question/response we cannot tell:
>
>> Default Server: UnKnown
>> Address: 192.168.168.2

C:\Documents and Settings\abrass>nslookup
DNS request timed out.
timeout was 2 seconds.
*** Can't find server name for address 192.168.168.2: Timed out
*** Default servers are not available
Default Server: UnKnown
Address: 192.168.168.2

> www.macromedia.com
Server: UnKnown
Address: 192.168.168.2

DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out
>

The requests work fine from location #1, just not location #2.

>> Any help would be appreciated. The only temporary resolution I have
>> found to this is to add a secondary DNS of the local router which
>> resolves the problem of looking up external addresses but does not
>> resolve the problem of being unable to resolve FQDN and also seems to
>> prevent them from accessing the local web server.
>
> Clients must NOT use multiple DNS servers that do not
> return the same answer, so your temporary solution is
> going to cause trouble even if you fix the real problem.

Well I needed to get them able to surf the internet until I find a way to
solve this problem. I know exactly what you mean though, and I wish for
this to work properly rather than "jimmy rig" it.

>
> The following is not specific to your problem (see above),
> but it may be of help now or later:
>
> Full checklist for DNS for AD
> 1) Dynamic for the zone supporting AD --- CHECK
> 2) All internal DNS clients NIC\IP properties must specify SOLELY
> that internal, dynamic DNS server (set.) --- CHECK
> 3) DCs and even DNS servers are DNS clients too -- see #2 --- CHECK
> 4) If you have more than one Domain, every DNS server must
> be able to resolve ALL domains (either directly or
> indirectly) --- ONLY ONE DOMAIN
>
> netdiag /fix
>
> ...or maybe:
>
> dcdiag /fix
>
> (Win2003 can do this from Support tools):
> nltest /dsregdns /server:D C-ServerNameGoesHere
> http://support.microsoft.com/kb/q260371/

I'll have to get my hands on these support tools before I can run them as
they dont seem to be installed on the server at the moment. As of yet
nothing else has worked.

> Ensure that DNS zones/domains are fully replicated to all DNS
> servers for that (internal) zone/domain. -- ONLY ONE SERVER
>
> Also useful may be running DCDiag on each DC, sending the
> output to a text file, and searching for FAIL, ERROR, WARN.
>
> Single Label domain zone names are a problem Google:
> [ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]

Will check into this too. Thanks for the advice.
Anonymous
April 19, 2005 7:05:24 AM

Archived from groups: microsoft.public.win2000.dns (More info?)

"adamofevil" <adamofevil@nospam.optonline.net> wrote in message
news:Xns963D15EB26918adamofevil@207.46.248.16...
> "Herb Martin" <news@LearnQuick.com> wrote in

> >> DNS: Single AD integrated zone lenderservices.local (no . zone)
> >> Configured for forwarding to ISP DNS servers
> >>
> >> Location #1 contains the server, subnet 192.168.168.0/24
> >> Location #2 contains no server, subnet 192.168.0.0/24
> >>
> >> Location #1 & 2 are connected via a gateway-gateway VPN
> >
> > May we presume the VPN routes in general and is unfiltered?
> > Ping, telnet server 80, etc.?
>
> Yes. Ping, telnet, RDP and everything else under the sun seems to work
> fine through the VPN.
>
> >> Clients at location #2 are configured with static addresses pointing
> >> DNS
> > to
> >> 192.168.168.2
> >
> > So they must get DNS requests fulfilled across the WAN/VPN?
> >
> > Not illegal but slow probably.
>
> Well there are only 4 workstations at location #2, so I didn't see the
> need to recommend another server at that location.

That makes sense, especially if there are no DCs nor
resource servers local.

What sort of box is the router on the remote end?
(Maybe a secondary or caching only DNS server
there will help to cut down on such problem but this
is not likely your real problem.)

> They should still be
> able to get DNS over the WAN though, and it just doesn't seem to work
> properly.

Yes. That is correct. And within a reasonable
delay it will work that way.

> >> Clients at location #2 are able to resolve hostnames but not FQDN
> >> names
> >
> > This sounds like they are using broadcasts to resolve the simple
> > computer names through NetBIOS and failing to resolve DNS
> > names with suffixes (FQDN means something different that you
> > believe).
> >
> > What about the computer DNS names in the System Control panel?
> > Are they named fully? (Not just "computer" but
> > "computer.domain.com"?) They need to be.
>
> They are all computer.lenderservices.local

In the System control panel?

> >> Clients at location #2 are unable to resolve the majority of external
> >> DNS requests
> >
> > What does the following give:
> >
> > nslookup DC_NAME.lenderservices.local
> >
> > (Copy and paste the full answer and request, do not type it, and
> > please don't use pictures of the screen.)
>
> C:\Documents and Settings\abrass>nslookup server.lenderservices.local
> DNS request timed out.
> timeout was 2 seconds.
> *** Can't find server name for address 192.168.168.2: Timed out
> *** Default servers are not available
> Server: UnKnown
> Address: 192.168.168.2
>
> DNS request timed out.
> timeout was 2 seconds.
> *** Request to UnKnown timed-out

I should have asked you to try to following;
(We could have saved a message round):

nslookup -time=10 server.lenderservices.local

nslookup -time=20 server.lenderservices.local

If the long timeout works then we have a time problem,
but if it fails we (likely) have a true connectivity or firewall
problem.

Also try the same settings with the INTERNAL DNS server
specified using IP address as the DNS Server:

nslookup -time=20 server.lenderservices.local DNS.SRV.IP.ADDR


> > Clients must NOT use multiple DNS servers that do not
> > return the same answer, so your temporary solution is
> > going to cause trouble even if you fix the real problem.
>
> Well I needed to get them able to surf the internet until I find a way to
> solve this problem. I know exactly what you mean though, and I wish for
> this to work properly rather than "jimmy rig" it.

Understood -- just note this is NOT suitable once
the problem is resolved.

And you CANNOT use both the "correct" server and
this external resolving server on the client NIC settings,
and expect reliable results.

Many people try to put both servers one the NIC thinking
both will be used, or thinking the first will always be
used if available -- this is not true. The first will be
preferred but not reliably used. The second will never
be used if the first answers.
April 19, 2005 11:07:48 AM

Archived from groups: microsoft.public.win2000.dns (More info?)

"Herb Martin" <news@LearnQuick.com> wrote in
news:o odBCbLRFHA.3788@tk2msftngp13.phx.gbl:

> "adamofevil" <adamofevil@nospam.optonline.net> wrote in message
> news:Xns963D15EB26918adamofevil@207.46.248.16...
>> "Herb Martin" <news@LearnQuick.com> wrote in
>
>> >> DNS: Single AD integrated zone lenderservices.local (no . zone)
>> >> Configured for forwarding to ISP DNS servers
>> >>
>> >> Location #1 contains the server, subnet 192.168.168.0/24
>> >> Location #2 contains no server, subnet 192.168.0.0/24
>> >>
>> >> Location #1 & 2 are connected via a gateway-gateway VPN
>> >
>> > May we presume the VPN routes in general and is unfiltered?
>> > Ping, telnet server 80, etc.?
>>
>> Yes. Ping, telnet, RDP and everything else under the sun seems to
>> work fine through the VPN.
>>
>> >> Clients at location #2 are configured with static addresses
>> >> pointing DNS
>> > to
>> >> 192.168.168.2
>> >
>> > So they must get DNS requests fulfilled across the WAN/VPN?
>> >
>> > Not illegal but slow probably.
>>
>> Well there are only 4 workstations at location #2, so I didn't see
>> the need to recommend another server at that location.
>
> That makes sense, especially if there are no DCs nor
> resource servers local.
>
> What sort of box is the router on the remote end?
> (Maybe a secondary or caching only DNS server
> there will help to cut down on such problem but this
> is not likely your real problem.)

Both ends are using 10Mb/1Mb cable modem with a gateway<->gateway VPN using
Netgear FVS318 routers. What is unusual is that I had them buy two of the
same brand & model router for the VPN but one of them is v1 and the other
is v3. The v3 seems a bit more configurable with the VPN settings,
especially when it comes to encryption, but this didn't seem to pose any
problems for me. I was able to get the VPN up and running very quickly and
as previously noted there does not seem to be any firewall issues (all
workstation Windows Firewall's are disabled through group policy, which I
verified on each local workstation, and the server Windows Firewall is also
disabled, as the router is fully capable of acting as the firewall) as I am
able to communicate through any desired port (even if I telnet to the
server on port 53 I receive a blank screen which I believe is indicative of
a response). At first I thought maybe there was too much encryption on the
VPN so I lowered it from 3DES to DES, but that did not solve the problem.

>> They should still be
>> able to get DNS over the WAN though, and it just doesn't seem to work
>> properly.
>
> Yes. That is correct. And within a reasonable
> delay it will work that way.
>
>> >> Clients at location #2 are able to resolve hostnames but not FQDN
>> >> names
>> >
>> > This sounds like they are using broadcasts to resolve the simple
>> > computer names through NetBIOS and failing to resolve DNS
>> > names with suffixes (FQDN means something different that you
>> > believe).
>> >
>> > What about the computer DNS names in the System Control panel?
>> > Are they named fully? (Not just "computer" but
>> > "computer.domain.com"?) They need to be.
>>
>> They are all computer.lenderservices.local
>
> In the System control panel?

Yes

>> >> Clients at location #2 are unable to resolve the majority of
>> >> external DNS requests
>> >
>> > What does the following give:
>> >
>> > nslookup DC_NAME.lenderservices.local
>> >
>> > (Copy and paste the full answer and request, do not type it, and
>> > please don't use pictures of the screen.)
>>
>> C:\Documents and Settings\abrass>nslookup server.lenderservices.local
>> DNS request timed out.
>> timeout was 2 seconds.
>> *** Can't find server name for address 192.168.168.2: Timed out
>> *** Default servers are not available
>> Server: UnKnown
>> Address: 192.168.168.2
>>
>> DNS request timed out.
>> timeout was 2 seconds.
>> *** Request to UnKnown timed-out
>
> I should have asked you to try to following;
> (We could have saved a message round):
>
> nslookup -time=10 server.lenderservices.local
>
> nslookup -time=20 server.lenderservices.local
>
> If the long timeout works then we have a time problem,
> but if it fails we (likely) have a true connectivity or firewall
> problem.
>
> Also try the same settings with the INTERNAL DNS server
> specified using IP address as the DNS Server:
>
> nslookup -time=20 server.lenderservices.local DNS.SRV.IP.ADDR

From the internal server the responses are all normal and all lookups are
successful. It is only from workstations on the other side of the VPN that
have this problem. I will try the other 2 commands later this evening and
let you know the results.

>> > Clients must NOT use multiple DNS servers that do not
>> > return the same answer, so your temporary solution is
>> > going to cause trouble even if you fix the real problem.
>>
>> Well I needed to get them able to surf the internet until I find a
>> way to solve this problem. I know exactly what you mean though, and
>> I wish for this to work properly rather than "jimmy rig" it.
>
> Understood -- just note this is NOT suitable once
> the problem is resolved.

I am fully aware of this.

> And you CANNOT use both the "correct" server and
> this external resolving server on the client NIC settings,
> and expect reliable results.

I agree with you wholeheartedly, which is why I am trying to figure out why
my original configuration does not work.

> Many people try to put both servers one the NIC thinking
> both will be used, or thinking the first will always be
> used if available -- this is not true. The first will be
> preferred but not reliably used. The second will never
> be used if the first answers.

I have set up Active Directory many times in larger environments, but there
was always a DNS server at each location. This is my first time attempting
to resolve DNS over a VPN. I appreciate your time and effort.
Anonymous
April 19, 2005 9:48:47 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

> I have set up Active Directory many times in larger environments, but
there
> was always a DNS server at each location. This is my first time
attempting
> to resolve DNS over a VPN. I appreciate your time and effort.

Is there any practical way to make a Secondary DNS
server at the remote site?

On the router? On one of the clients? (You cannot
run MS DNS on a Workstation but BIND will run on
a reliable workstation if you can keep it on.)

Notice that if the LONG time-outs don't work then you
probably don't have a time problem and this is getting
blocked SOMEWHERE.

--
Herb Martin


"adamofevil" <adamofevil@nospam.optonline.net> wrote in message
news:Xns963D670C9526Fadamofevil@207.46.248.16...
> "Herb Martin" <news@LearnQuick.com> wrote in
> news:o odBCbLRFHA.3788@tk2msftngp13.phx.gbl:
>
> > "adamofevil" <adamofevil@nospam.optonline.net> wrote in message
> > news:Xns963D15EB26918adamofevil@207.46.248.16...
> >> "Herb Martin" <news@LearnQuick.com> wrote in
> >
> >> >> DNS: Single AD integrated zone lenderservices.local (no . zone)
> >> >> Configured for forwarding to ISP DNS servers
> >> >>
> >> >> Location #1 contains the server, subnet 192.168.168.0/24
> >> >> Location #2 contains no server, subnet 192.168.0.0/24
> >> >>
> >> >> Location #1 & 2 are connected via a gateway-gateway VPN
> >> >
> >> > May we presume the VPN routes in general and is unfiltered?
> >> > Ping, telnet server 80, etc.?
> >>
> >> Yes. Ping, telnet, RDP and everything else under the sun seems to
> >> work fine through the VPN.
> >>
> >> >> Clients at location #2 are configured with static addresses
> >> >> pointing DNS
> >> > to
> >> >> 192.168.168.2
> >> >
> >> > So they must get DNS requests fulfilled across the WAN/VPN?
> >> >
> >> > Not illegal but slow probably.
> >>
> >> Well there are only 4 workstations at location #2, so I didn't see
> >> the need to recommend another server at that location.
> >
> > That makes sense, especially if there are no DCs nor
> > resource servers local.
> >
> > What sort of box is the router on the remote end?
> > (Maybe a secondary or caching only DNS server
> > there will help to cut down on such problem but this
> > is not likely your real problem.)
>
> Both ends are using 10Mb/1Mb cable modem with a gateway<->gateway VPN
using
> Netgear FVS318 routers. What is unusual is that I had them buy two of the
> same brand & model router for the VPN but one of them is v1 and the other
> is v3. The v3 seems a bit more configurable with the VPN settings,
> especially when it comes to encryption, but this didn't seem to pose any
> problems for me. I was able to get the VPN up and running very quickly and
> as previously noted there does not seem to be any firewall issues (all
> workstation Windows Firewall's are disabled through group policy, which I
> verified on each local workstation, and the server Windows Firewall is
also
> disabled, as the router is fully capable of acting as the firewall) as I
am
> able to communicate through any desired port (even if I telnet to the
> server on port 53 I receive a blank screen which I believe is indicative
of
> a response). At first I thought maybe there was too much encryption on
the
> VPN so I lowered it from 3DES to DES, but that did not solve the problem.
>
> >> They should still be
> >> able to get DNS over the WAN though, and it just doesn't seem to work
> >> properly.
> >
> > Yes. That is correct. And within a reasonable
> > delay it will work that way.
> >
> >> >> Clients at location #2 are able to resolve hostnames but not FQDN
> >> >> names
> >> >
> >> > This sounds like they are using broadcasts to resolve the simple
> >> > computer names through NetBIOS and failing to resolve DNS
> >> > names with suffixes (FQDN means something different that you
> >> > believe).
> >> >
> >> > What about the computer DNS names in the System Control panel?
> >> > Are they named fully? (Not just "computer" but
> >> > "computer.domain.com"?) They need to be.
> >>
> >> They are all computer.lenderservices.local
> >
> > In the System control panel?
>
> Yes
>
> >> >> Clients at location #2 are unable to resolve the majority of
> >> >> external DNS requests
> >> >
> >> > What does the following give:
> >> >
> >> > nslookup DC_NAME.lenderservices.local
> >> >
> >> > (Copy and paste the full answer and request, do not type it, and
> >> > please don't use pictures of the screen.)
> >>
> >> C:\Documents and Settings\abrass>nslookup server.lenderservices.local
> >> DNS request timed out.
> >> timeout was 2 seconds.
> >> *** Can't find server name for address 192.168.168.2: Timed out
> >> *** Default servers are not available
> >> Server: UnKnown
> >> Address: 192.168.168.2
> >>
> >> DNS request timed out.
> >> timeout was 2 seconds.
> >> *** Request to UnKnown timed-out
> >
> > I should have asked you to try to following;
> > (We could have saved a message round):
> >
> > nslookup -time=10 server.lenderservices.local
> >
> > nslookup -time=20 server.lenderservices.local
> >
> > If the long timeout works then we have a time problem,
> > but if it fails we (likely) have a true connectivity or firewall
> > problem.
> >
> > Also try the same settings with the INTERNAL DNS server
> > specified using IP address as the DNS Server:
> >
> > nslookup -time=20 server.lenderservices.local DNS.SRV.IP.ADDR
>
> From the internal server the responses are all normal and all lookups are
> successful. It is only from workstations on the other side of the VPN
that
> have this problem. I will try the other 2 commands later this evening and
> let you know the results.
>
> >> > Clients must NOT use multiple DNS servers that do not
> >> > return the same answer, so your temporary solution is
> >> > going to cause trouble even if you fix the real problem.
> >>
> >> Well I needed to get them able to surf the internet until I find a
> >> way to solve this problem. I know exactly what you mean though, and
> >> I wish for this to work properly rather than "jimmy rig" it.
> >
> > Understood -- just note this is NOT suitable once
> > the problem is resolved.
>
> I am fully aware of this.
>
> > And you CANNOT use both the "correct" server and
> > this external resolving server on the client NIC settings,
> > and expect reliable results.
>
> I agree with you wholeheartedly, which is why I am trying to figure out
why
> my original configuration does not work.
>
> > Many people try to put both servers one the NIC thinking
> > both will be used, or thinking the first will always be
> > used if available -- this is not true. The first will be
> > preferred but not reliably used. The second will never
> > be used if the first answers.
>
> I have set up Active Directory many times in larger environments, but
there
> was always a DNS server at each location. This is my first time
attempting
> to resolve DNS over a VPN. I appreciate your time and effort.
!