Can resolve DNS, can ping IP, but can't ping by DNS??

I've been troubleshooting random, intermittent "page not found" errors on a
couple of our intranet sites. Domain with about 30 users, single subnet,
nothing unusual with our DNS config to my knowledge. The problem will
affect an individual user even while other users continue to use the site
without trouble. After a short while (10 mins? 30 mins?) the problem
clears up on its own. After discovering that a reboot fixes the problem, I
dug further, and here's what's happening:

While the problem is occurring, I can ping the target intranet site by IP.
I can resolve the site's dns name using nslookup. But I *can't* ping the
site by DNS name. "Ping request could not find host funtimes. Please check
the name and try again." Ipconfig /flushdns doesn't fix it. However,
ipconfig release & renew (actually just "repair" from the gui) *does* fix
the problem.

In watching the messages that flash by during the repair operation, I'm very
familiar with everything that's taking place except the messages having to
do with NetBT. The Clearing NetBT and Refreshing NetBT messages, iiuc, have
to do with NetBIOS over TCP/IP, but it's not clear to me what netbios name
resolution could have to do with pinging an intranet site by DNS name.

I'm stumped...any takers?

Thanks in advance,

BJ

In news:u9$wmEjPHHA.4424@TK2MSFTNGP06.phx.gbl,
Bryan L <blinton.nospam@connellinsurance.nospam.com> typed:
> I've been troubleshooting random, intermittent "page not found"
> errors on a couple of our intranet sites. Domain with about 30
> users, single subnet, nothing unusual with our DNS config to my
> knowledge.

You might post an unedited ipconfig /all from a DC and from one of your
problem clients.

The problem will affect an individual user even while
> other users continue to use the site without trouble. After a short
> while (10 mins? 30 mins?) the problem clears up on its own. After
> discovering that a reboot fixes the problem, I dug further, and
> here's what's happening:
> While the problem is occurring, I can ping the target intranet site
> by IP. I can resolve the site's dns name using nslookup. But I
> *can't* ping the site by DNS name. "Ping request could not find host
> funtimes. Please check the name and try again."

Hmmm - well, funtimes isn't a 'DNS name' - it's the NetBIOS name of the
server. The fully-qualified name in DNS would be funtimes.domain.whatever.
If you type in funtimes and it doesn't return the name
funtimes.domain.whatever you've got DNS problems.....

> Ipconfig /flushdns
> doesn't fix it. However, ipconfig release & renew (actually just
> "repair" from the gui) *does* fix the problem.
>
> In watching the messages that flash by during the repair operation,
> I'm very familiar with everything that's taking place except the
> messages having to do with NetBT. The Clearing NetBT and Refreshing
> NetBT messages, iiuc, have to do with NetBIOS over TCP/IP, but it's
> not clear to me what netbios name resolution could have to do with
> pinging an intranet site by DNS name.

See above. And if you have NetBIOS over TCP/IP enabled, you should be using
WINS, too -
>
> I'm stumped...any takers?
>
> Thanks in advance,
>
> BJ

Next time it doesn't work,...from the client machine you experience the
problem, run:

c:\> IPConfig /FlushDNS

Does it work immediately after that?

If this command gets it working (even temporarily) then you need to look at
a few things and maybe be prepared to correct a DNS Scheme design flaw in
your LAN. Here is the best pattern for the DNS Scheme:

1. Make sure all machines on the LAN use the AD/DNS Server and *nothing*
else.
2. Make sure the AD/DNS Servers are able to make outbound DNS Queries
3. Make sure the IP# of an external DNS (such as the ISP's) is listed in the
Forwarders List within the config of the AD/DNS server themselves. This is
in the DNS Service config, not the TCP/IP config of the nic.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

The views expressed are my own (as annoying as they are), and not those of
my employer or anyone else associated with me.
-----------------------------------------------------

"Bryan L" <blinton.nospam@connellinsurance.nospam.com> wrote in message
news:u9$wmEjPHHA.4424@TK2MSFTNGP06.phx.gbl...
> I've been troubleshooting random, intermittent "page not found" errors on
> a couple of our intranet sites. Domain with about 30 users, single
> subnet, nothing unusual with our DNS config to my knowledge. The problem
> will affect an individual user even while other users continue to use the
> site without trouble. After a short while (10 mins? 30 mins?) the
> problem clears up on its own. After discovering that a reboot fixes the
> problem, I dug further, and here's what's happening:
>
> While the problem is occurring, I can ping the target intranet site by IP.
> I can resolve the site's dns name using nslookup. But I *can't* ping the
> site by DNS name. "Ping request could not find host funtimes. Please
> check the name and try again." Ipconfig /flushdns doesn't fix it.
> However, ipconfig release & renew (actually just "repair" from the gui)
> *does* fix the problem.
>
> In watching the messages that flash by during the repair operation, I'm
> very familiar with everything that's taking place except the messages
> having to do with NetBT. The Clearing NetBT and Refreshing NetBT
> messages, iiuc, have to do with NetBIOS over TCP/IP, but it's not clear to
> me what netbios name resolution could have to do with pinging an intranet
> site by DNS name.
>
> I'm stumped...any takers?
>
> Thanks in advance,
>
> BJ
>

"Bryan L" <blinton.nospam@connellinsurance.nospam.com> wrote in message
news:u9$wmEjPHHA.4424@TK2MSFTNGP06.phx.gbl...
> the name and try again." Ipconfig /flushdns doesn't fix it. However,

I didn't see this commend at the time I posted,...however the rest of the
"plan" I gave is correct and should be followed.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

The views expressed are my own (as annoying as they are), and not those of
my employer or anyone else associated with me.
-----------------------------------------------------

"Lanwench [MVP - Exchange]"
<lanwench@heybuddy.donotsendme.unsolicitedmail.atyahoo.com> wrote in message
news:u3$AOYjPHHA.3944@TK2MSFTNGP06.phx.gbl...
> Hmmm - well, funtimes isn't a 'DNS name' - it's the NetBIOS name of the

I'm restricted from "funtimes". I can only go to "boringtimes",...it is even
a ".org" because I'm such a charity case... ;- {

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

The views expressed are my own (as annoying as they are), and not those of
my employer or anyone else associated with me.
-----------------------------------------------------

"Phillip Windell" <@.> wrote in message
news:OnViKSjPHHA.4424@TK2MSFTNGP06.phx.gbl...
> Next time it doesn't work,...from the client machine you experience the
> problem, run:
>
> c:\> IPConfig /FlushDNS
>
> Does it work immediately after that?

I saw your followup post, so we've got this covered.

> 1. Make sure all machines on the LAN use the AD/DNS Server and *nothing*
> else.
> 2. Make sure the AD/DNS Servers are able to make outbound DNS Queries
> 3. Make sure the IP# of an external DNS (such as the ISP's) is listed in
> the Forwarders List within the config of the AD/DNS server themselves.
> This is in the DNS Service config, not the TCP/IP config of the nic.

Regarding 1, 2, &3: Under normal circumstances non-local DNS requests are
forwarded by my DNS server to appropriate external DNS servers. However, in
my DHCP setup I do have secondary and tertiary DNS servers assigned so hosts
can continue to resolve internet addresses in the event our server goes
down. When troubleshooting this problem, I have verified that the server
returning the results of my nslookup queries is my own DNS server.

BJ

"Bryan L" <blinton.nospam@connellinsurance.nospam.com> wrote in message
news:O2tHoKkPHHA.1252@TK2MSFTNGP02.phx.gbl...
> forwarded by my DNS server to appropriate external DNS servers. However, in
> my DHCP setup I do have secondary and tertiary DNS servers assigned so hosts
> can continue to resolve internet addresses in the event our server goes down.

Absolutely get rid of that.
If the server goes down, you 've lost the AD Domain and whether they can browse
the web is the least of your worries. I don't know that I would want them
running around on the internet while I'm trying to bring the Domain back to life
anyway. If you want multiple DNS's for redundancy's sake,...you need to do that
via multiple DCs (with DNS on them).

See what happens after correcting that.
One step at a time.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

The views expressed are my own (as annoying as they are), and not those of my
employer or anyone else associated with me.
-----------------------------------------------------

A couple of things:

"Lanwench [MVP - Exchange]" wrote:

> You might post an unedited ipconfig /all from a DC and from one of your
> problem clients.

Ipconfig results posted at the bottom

> Hmmm - well, funtimes isn't a 'DNS name' - it's the NetBIOS name of the
> server. The fully-qualified name in DNS would be funtimes.domain.whatever.
> If you type in funtimes and it doesn't return the name
> funtimes.domain.whatever you've got DNS problems.....

Sorry for being unclear. Funtimes is the name of the CNAME record in my
DNS, which corresponds to the host header I've assigned to the intranet
site. When I do an nslookup on that CNAME (alone or as a FQDN) the query
*returns the proper result from my DNS server* -- here's the kicker -- even
if the problem is occurring at that moment. In other words, even a client
experiencing the problem can still correctly *resolve* the name it's trying
to reach. The client can also ping the host by IP. But while the problem
is occurring, the client cannot ping the host by hostname. That's the part
that has me stymied.

Here's an example:
----------------------
C:\Documents and Settings\BJUsername>nslookup funtimes
Server: DNS1.mydomain.local
Address: 192.168.100.8

Name: Web1.mydomain.local
Address: 192.168.100.7
Aliases: funtimes.mydomain.local

-----------(Client resolved DNS name)------------

C:\Documents and Settings\BJUsername>nslookup funtimes.mydomain.local
Server: DNS1.mydomain.local
Address: 192.168.100.8

Name: Web1.mydomain.local
Address: 192.168.100.7
Aliases: funtimes.mydomain.local

-----------(Client resolved FQDN)------------

C:\Documents and Settings\BLinton>ping funtimes
Ping request could not find host crew. Please check the name and try again.

-----------(Client was unable to ping DNS name)----------
(note that I also tried the FQDN with the same result)

C:\Documents and Settings\BJUsername>ping 192.168.100.7

Pinging 192.168.100.7 with 32 bytes of data:

Reply from 192.168.100.7: bytes=32 time<1ms TTL=128
Reply from 192.168.100.7: bytes=32 time<1ms TTL=128
Reply from 192.168.100.7: bytes=32 time<1ms TTL=128
Reply from 192.168.100.7: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.100.7:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
----------------------

> ....And if you have NetBIOS over TCP/IP enabled, you should be using WINS,
> too -

I'm running a WINS server, and it has correct active registrations for all
hosts concerned. I did notice that the static IP configuration for the
AD/DNS/WINS server did NOT have a WINS server configured, so I entered that
(it points to itself for WINS now). All users' WINS configurations are
provided via the DHCP scope options, to use the h-node type.

Thanks again,

BJ

---------- AD/DNS Server ipconfig /all ---------------
C:\Documents and Settings\Administrator.MYDOMAIN>ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . : DNS1
Primary Dns Suffix . . . . . . : mydomain.local
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . : No
WINS Proxy Enabled. . . . : No
DNS Suffix Search List. . . : mydomain.local

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . . : Intel(R) PRO/1000 XT Network
Connection
Physical Address. . . . . . . . : 00-00-00-AA-BB-CC
DHCP Enabled. . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.100.8
Subnet Mask . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . : 192.168.100.1
DNS Servers . . . . . . . . . . : 192.168.100.8
Primary WINS Server . . . : 192.168.100.8
/----------
-------------Example Client ipconfig /all --------------
C:\Documents and Settings\BJUser>ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . : Client1
Primary Dns Suffix . . . . . . . : mydomain.local
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : Mydomain.local
mydomain.local

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : mydomain.local
Description . . . . . . . . . . . : Broadcom NetXtreme 57xx Gigabit
Cont
roller
Physical Address. . . . . . . . . : 00-00-00-DD-EE-FF
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.100.200
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.100.1
DHCP Server . . . . . . . . . . . : 192.168.100.8
DNS Servers . . . . . . . . . . . : 192.168.100.8
76.66.1.130
4.2.2.2
Primary WINS Server . . . . : 192.168.100.8
Lease Obtained. . . . . . . . . . : Monday, January 22, 2007 8:20:01
AM
Lease Expires . . . . . . . . . . : Tuesday, January 30, 2007
8:20:01 AM
/--------------

"Phillip Windell" <@.> wrote in message
news:uexi7gkPHHA.3316@TK2MSFTNGP05.phx.gbl...
> "Bryan L" <blinton.nospam@connellinsurance.nospam.com> wrote in message
> news:O2tHoKkPHHA.1252@TK2MSFTNGP02.phx.gbl...
>> forwarded by my DNS server to appropriate external DNS servers. However,
>> in my DHCP setup I do have secondary and tertiary DNS servers assigned so
>> hosts can continue to resolve internet addresses in the event our server
>> goes down.
>
> Absolutely get rid of that.
> If the server goes down, you 've lost the AD Domain and whether they can
> browse the web is the least of your worries. I don't know that I would
> want them running around on the internet while I'm trying to bring the
> Domain back to life anyway. If you want multiple DNS's for redundancy's
> sake,...you need to do that via multiple DCs (with DNS on them).

Mulitple DCs are in the plan...if I can swing it. Until recently my (old,
old) file server has been serving as an additional AD server. It's starting
to become unreliable (hardware issues) and is in the process of being
retired. I've begun migrating things to a shiny new server we just got.
Dell talked me into trying Storage Server, with an option to switch to
Server 2003 standard if it better meets our needs. I'm evaluating Storage
Server right now and am trying to judge whether the Storage Server goodies
(indexing and single-instance storage of duplicate files) outweigh the
inability to run AD, SQL, IIS, etc. Although it'll be more work, I'm
halfway inclined to dump Storage Server and install Server 2003 Standard R2,
in no small part because it's the only other server I have that can serve as
a DC without violating both best practices and the recommended/supported
config for apps running on other servers. Incidentally, if you or anyone
has opinions/experience about Storage Server vs Server 2003 standard, I'd
welcome those.

You seem very adamant about not having failover DNS servers configured on
the clients. What's the reason for that? My network is small enough that
my DNS server should never timeout on a DNS query under normal
circumstances. Also, in our particular organization, much of our work is
carried out via partners' websites (we are an independant insurance agency;
we do business with dozens of different carriers, and rely heavily on many
of their websites). So although the loss of the domain is a big deal,
having the users' lose their ability to complete web transactions with our
carriers is a bigger deal (from their working perspective).

All this just reinforces to me that probably, having a standard server I can
use as an additional DC probably outweighs the benefits of running Storage
Server on our file server.

Thanks again for great responses.

BJ
>
> See what happens after correcting that.
> One step at a time.
>
> --
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>
> The views expressed are my own (as annoying as they are), and not those of
> my employer or anyone else associated with me.
> -----------------------------------------------------
>
>

"Bryan L" <blinton.nospam@connellinsurance.nospam.com> wrote in message
news:Ogm2KElPHHA.1252@TK2MSFTNGP02.phx.gbl...
> You seem very adamant about not having failover DNS servers configured on the
> clients. What's the reason for that?

AD depends 100% on DNS. You can not allow a situation to exist where a client
(for whatever reason) while trying to interact with AD to might look to the
wrong DNS Server. This has to be fixed even if it does not turn out to be the
cause of the original problem.

All machines on the LAN use only the AD/DNS. The AD/DNS then uses the ISP's
DNS(s) as Forwarders in the Forwarders List in the configuration of the DNS
services.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

The views expressed are my own (as annoying as they are), and not those of my
employer or anyone else associated with me.
-----------------------------------------------------

In news:%23BJXjwjPHHA.2468@TK2MSFTNGP06.phx.gbl,
Phillip Windell <@.> typed:
> "Lanwench [MVP - Exchange]"
> <lanwench@heybuddy.donotsendme.unsolicitedmail.atyahoo.com> wrote in
> message news:u3$AOYjPHHA.3944@TK2MSFTNGP06.phx.gbl...
>> Hmmm - well, funtimes isn't a 'DNS name' - it's the NetBIOS name of
>> the
>
> I'm restricted from "funtimes". I can only go to "boringtimes",...it
> is even a ".org" because I'm such a charity case... ;- {

Just watch out for "goodtimes" because it's a virus that will not only steal
your online banking credentials, format your hard drive, and steal your
identity, but will also cause trees to fall on your car *and* give you and
your entire family severe intestinal gas for three years.

"Phillip Windell" <@.> wrote in message
news:OeYuqRlPHHA.1552@TK2MSFTNGP05.phx.gbl...
> "Bryan L" <blinton.nospam@connellinsurance.nospam.com> wrote in message
> news:Ogm2KElPHHA.1252@TK2MSFTNGP02.phx.gbl...
>> You seem very adamant about not having failover DNS servers configured on
>> the clients. What's the reason for that?
>
> AD depends 100% on DNS. You can not allow a situation to exist where a
> client (for whatever reason) while trying to interact with AD to might
> look to the wrong DNS Server. This has to be fixed even if it does not
> turn out to be the cause of the original problem.

Um... that is an excellent reason. :-) Before replying to this post, I
immediately went to the scope options and removed the other DNS servers.
Don't know why the security aspect never occurred to me before, but it makes
total sense; I don't want AD requests going to the wide, outside world,
ever.

Thanks for that. We'll also see if it helps the page not found intranet
situation.

BJ

"Bryan L" <blinton.nospam@connellinsurance.nospam.com> wrote in message
news:udS892lPHHA.4824@TK2MSFTNGP02.phx.gbl...
>
> "Phillip Windell" <@.> wrote in message
> news:OeYuqRlPHHA.1552@TK2MSFTNGP05.phx.gbl...
>> "Bryan L" <blinton.nospam@connellinsurance.nospam.com> wrote in message
>> news:Ogm2KElPHHA.1252@TK2MSFTNGP02.phx.gbl...
>>> You seem very adamant about not having failover DNS servers configured on
>>> the clients. What's the reason for that?
>>
>> AD depends 100% on DNS. You can not allow a situation to exist where a
>> client (for whatever reason) while trying to interact with AD to might look
>> to the wrong DNS Server. This has to be fixed even if it does not turn out
>> to be the cause of the original problem.
>
> Um... that is an excellent reason. :-) Before replying to this post, I
> immediately went to the scope options and removed the other DNS servers. Don't
> know why the security aspect never occurred to me before, but it makes total
> sense; I don't want AD requests going to the wide, outside world, ever.

It is more of a functional issue than a security issue, but none-the-less...the
right way is still the right way :-)

Do an "ipconfig /release" followed by "ipconfig /renew" on a few machines and
see how they behave after. Do an "ipconfig /all" to verify they have the new
correct config. The ones you don't force will only get the new config when the
DHCP Lease runs out or they get rebooted.

Don't forget that you need to adjust any machine that is statically configured
(non-dhcp) if they also include those "other" DNS servers. They can still have
the same problem even though they aren't dhcp clients.

I suspect your problems with this will fade away as the new config takes
effect,...or it will certainly lessen to maybe a few isolated stituations that
would be easy to sort out.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

The views expressed are my own (as annoying as they are), and not those of my
employer or anyone else associated with me.
-----------------------------------------------------

"Phillip Windell" <@.> wrote in message
news:uh3enzmPHHA.2340@TK2MSFTNGP05.phx.gbl...
>
> "Bryan L" <blinton.nospam@connellinsurance.nospam.com> wrote in message
> news:udS892lPHHA.4824@TK2MSFTNGP02.phx.gbl...
>>
>> "Phillip Windell" <@.> wrote in message
>> news:OeYuqRlPHHA.1552@TK2MSFTNGP05.phx.gbl...
>>> "Bryan L" <blinton.nospam@connellinsurance.nospam.com> wrote in message
>>> news:Ogm2KElPHHA.1252@TK2MSFTNGP02.phx.gbl...
>>>> You seem very adamant about not having failover DNS servers configured
>>>> on the clients. What's the reason for that?
>>>
>>> AD depends 100% on DNS. You can not allow a situation to exist where a
>>> client (for whatever reason) while trying to interact with AD to might
>>> look to the wrong DNS Server. This has to be fixed even if it does not
>>> turn out to be the cause of the original problem.
>>
>> Um... that is an excellent reason. :-) Before replying to this post, I
>> immediately went to the scope options and removed the other DNS servers.
>> Don't know why the security aspect never occurred to me before, but it
>> makes total sense; I don't want AD requests going to the wide, outside
>> world, ever.
>
> It is more of a functional issue than a security issue, but
> none-the-less...the right way is still the right way :-)

> Do an "ipconfig /release" followed by "ipconfig /renew" on a few machines
> and see how they behave after. Do an "ipconfig /all" to verify they have
> the new correct config. The ones you don't force will only get the new
> config when the DHCP Lease runs out or they get rebooted.

To clarify, this was only an intermittent problem anyway, so I'll just have
to wait to see if it pops up. I might have gotten a half dozen reports of
this during a given week, although I suspect it happened to people more
often and they just didn't report it.

> Don't forget that you need to adjust any machine that is statically
> configured (non-dhcp) if they also include those "other" DNS servers. They
> can still have the same problem even though they aren't dhcp clients.

I have 4 servers with static addresses; corrected those at the same time I
updated the DHCP config.

> I suspect your problems with this will fade away as the new config takes
> effect,...or it will certainly lessen to maybe a few isolated stituations
> that would be easy to sort out.

Here's hoping; it's so bizzare. The thing is, we have another site (hosted
by a dedicated IIS server) that runs the .NET front-end to our SQL-based CRM
database, and this has *never* happened on that site. The difference is
that the intranet sites that experience this problem are not published
(internal use only), while the CRM site is, meaning the site name can be
resolved and reached by both internal and external DNS servers and clients.

BJ

> --
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>
> The views expressed are my own (as annoying as they are), and not those of
> my employer or anyone else associated with me.
> -----------------------------------------------------
>
>
>

"Bryan L" <blinton.nospam@connellinsurance.nospam.com> wrote in message
news:eTBw7DnPHHA.780@TK2MSFTNGP03.phx.gbl...

One last thing. The AD/DNS machines themselves should point to themselves and
each other, but nothing else.

> Here's hoping; it's so bizzare. The thing is, we have another site (hosted by
> a dedicated IIS server) that runs the .NET front-end to our SQL-based CRM
> database, and this has *never* happened on that site. The difference is that
> the intranet sites that experience this problem are not published (internal
> use only), while the CRM site is, meaning the site name can be resolved and
> reached by both internal and external DNS servers and clients.

Research "Split-DNS".
You should run that DNS model. It can solve some issues that popup with
home-grown websites you have on the LAN.

The exact approach is differnet depending on whether your internal AD Domain is
spelled the same as the Public Domain or not. What I state below is based on
the assumption that the two names are different.

What you read may imply that you need an additional external DNS,...you do not.
That is handled by the ISP's DNS which will serve as your "external" DNS. So all
you have to worry about is the config of your AD/DNS boxes. Keep that in mind
when you read up on it.

In a nutshell, you simply keep two Zones in your AD/DNS setup. The internal AD
domain zone and the public external domain zone. But your external zone if
different than the one maintain on the ISP's system,...yours will use the
internal private IP of the resource instead of the public IP# if that resource
physically exists internally on the LAN. But if the resource is physically
external then it uses the regular public IP#. This is because the users should
go direct to the resource and not try to make "u-turns" through any firewall
devices when the resource is physically on the internal LAN.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

The views expressed are my own (as annoying as they are), and not those of my
employer or anyone else associated with me.
-----------------------------------------------------