Re: Satellite Branch Office Woes

This may or may not help, but some services require the Cisco router to use
an iphelper address, which tells the router that if the service can not be
contacted locally, to send it to the next hop.

i know is is required for DHCP over WAN in a Cisco environment. We use this
in our VPN at one remote site over a Comcast VPN to our main office.

"Herb Martin" wrote:


"Slandrum" <Slandrum@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:EA7C3AAC-E839-41CF-BFFB-9151B5A5C546@xxxxxxxxxxxxxxxx
We are currently testing a traditional satellite branch office solution
(no
servers in the SBO) for several small locations that will be coming online
this year. I've been through several different sources now, including the
WSSRA, but either I've missed something completely, or I am stuck with an
(unacknowledged) WAN configuration issue. Hopefully you folks can help me
decide which.

To elaborate, we have the traditional setup where we have a WAN guy who
handles all the telecom stuff, and then we have a Windows server guy (me)
who
handles all the Windows/AD stuff, etc. Although we work well together, the
WAN guy is pretty anti-MS, which means that anytime I suspect something
amiss
on his end, I have to really jump through the hoops to get him to
double-check configuration settings on his side of the fence. Otherwise
his
answer is always "Must be a Microsoft issue". And he may be right, this
time,
or at least a "Windows Admin issue". ;-)

This is irritating and forces you to not only really know what you are
doing,
but understand his job as well, especially the tools and methods for
troubleshooting.


At any rate, he has setup a DSL connected VPN IPSEC tunnel that is
entirely
hardware based. At one end of the tunnel he has a Cisco router, and at the
other end a Cisco VPN Concentrator. I'm not sure of the actual model
numbers,
but for the sake of this discussion it shouldn't really matter.

No it shouldn't and we wouldn't care unless we have to change something
on those routers to fix it. We can almost always work generically (e.g.,
"It's
just a pipe for data.", if it works.)

Since it is a tunnel between routers we can treat it conceptually as ONE
HOP.

Can we ping? (If not is he explicitly blocking ICMP or is this a problem?)

Can we NSlookup? (If not thent the DCs aren't going to do DNS well
and they will almost certainly not replicate.)

Is the tunnel wide open (to us) or it is filtered in addition to disallow
certain traffic (especially RPCs, DNS, and other things the DCs need)?

If not fully open can we telnet to TCP ports we need open?

OR BETTER can we use NetCat (from the Internet) to connect with
TCP and UDP for all the ports we need?

There are a
few other hardware devices in between, a VLAN, etc, but still pretty
standard
from what I've reviewed thus far. He is handling the IPSEC via an internal
Cisco certificate solution, so right now I view this connection as being a
straight through, clean pipe, just like it was one of our WAN circuits.

Exactly -- as long as there are no additional filters and the routing
basically
works (see above.)

It passes pings just fine, and I have done some portqry testing to verify
that LDAP, Kerberos, NTLM, SMB and various other TCP/UDP traffic types go
through okay, so right now I don't think it's a port blocking issue. I
tested
in both directions, so all should be fine, but the behavior I am seeing
makes
me wonder if there is a port filtering issue, or a bounce issue, etc.

How about TCP vs. UDP? Most people don't know or use Netcat so they
only check the TCP with Telnet which doesn't do UDP. (DNS uses UDP
a lot, some other stuff does too.)

Also, if he is filtering, even loosely, expect RPC issues which don't filter
easily/cleanly.

Since as I said I view the connection as operating just like one of our
WAN
links, the only AD side change I made was to create a subnet to match the
SBO
site and assigned it to the Central AD Site. Based on experience and
subsequent re-checking, I see no other required AD changes at this time.
However, I could be wrong in this.

No DC at the SBO? Is so, then you could have probably left the subnet
out (undefined subnets go to the Default-First-Site-Name even if it was
renamed) but I LIKE to see them defined anyway.

We have a client PC in the SBO running WinXPsp2. At first "the WAN guy"
was
providing DHCP from the Cisco router endpoint on the SBO side, but just to
make it cleaner I have since given the PC a manual IP address, with two
DNS
entries,

Where do these entries point? They most point STRICTLY to the INTERNAL
DNS Server (set) which can resolve all of the AD records.

Neither must point to any other DNS server (firewall, ISP, etc) which cannot
resolve your DCs and other AD records in the internal DNS zone for the AD
domain.

...a WINS entry and so on. I will eventually provide DHCP from the
Central Site as well, but not until I can get past the current issue.

Easier for him to do it unless there is a compelling reason to do otherwise.

Why? Because you would either need him to do "DHCP Relay Agent"* or
(ugh) enable "BootP forwarding".

* Cisco doesn't call it this, but rather "IP Helper address" (IIRC.) Other
routers might call it "DNS helper address" or some such.

Also, due to SPNEGO errors in the Event Log of the client PC that match KB
article numbers 891559 and 885887, I have applied the kereberos.dll sp2
hotfix as described in KB 885887 in an attempt to correct the below
described
problems. It didn't help any.

The PC itself does have a workstation account in the domain, and I have
placed this account in its own OU and have checked on "Block Policy
Inheritance" to ensure that it's not receiving any of our GPOs.

Is there a really good reason for this?

And its Host
entry does appear in the AD-integrated DNS Zone for the Domain.

Then something registered it there -- and since YOUR DHCP server
is not providing the address it didn't do it. So unless this is a manual
entry the computer itself was able to get DNS (registration) packets
through the tunnel. (Good sign.)

Also, IF you have enabled "Secure" updates only, then you have
proven that the machine authenticated with the domain if it registered
itself - very important.

(But if it did, AND you had a mixture of the right/wrong DNS servers
configured on that machine this would cause an INTERMITTENT
problem that might have made it work enough for that but fail at other
times.)

I have also configured a reverse lookup zone for the SBO subnet.

Pretty much irrelevant (except for Admin [your own] convenience.
(But if you did this, did you make THAT zone dynamic so that you
could get it to auto register?)

The primary problem that I am seeing is that the PC will not log into the
domain. It accepts the domain user name and password, albeit rather
slowly,
then goes to the "Loading Your Personal settings" screen and stays there .
forever. This occurs whether I am attaching via Remote Desktop, or if he
is
actually logging in at the console. We have left it at this stage for as
much
as 24 hours at one point, and it never completes the login.

I am very suspicous of those "two DNS servers".
==================================

I can attach to the PC with Remote Desktop (through the VPN IPSEC Tunnel)
but I receive the standard "user domain/username is currently logged in ."
message that requires me to do a forced Remote Logoff.

That means someone is using the machine (or autologon is enabled) and you
are kicking that user off abruptly.

This often will take
several tries, but eventually the incomplete domain login session will
end.

Common symptom of screwed up DNS -- it might work but work VERY
slowly.

Once it does I can attach to the PC with Remote Desktop by logging onto
the
local machine Administrator account. I can then attach to domain resources
on
our file servers by providing a domain/username and password when prompted
to
do so. However, these operations are also very slow; much slower than the
ping times would lead me to expect.

So some authentication is working.

I'm sorry this is sooo long, but I've tried to paint as complete a picture
as possible to eliminate the "did you check this and this" stuff, but will
watch for and happily answer any additional configuration or environment
questions you may have.

What do you think I've missed, or barring that, what should I have "the
WAN
guy" check?

I think you have configured some DNS server AT THE SBO which doesn't
know about the domain DNS servers with the zone supporting AD. Might
be wrong but this is a very common mistake.

EVERY DNS server used by a client MUST return the same answers, that is,
ALL of the correct answer that client will ever legitimately need. Clients
will
believe whichever server they use.

--
Herb Martin, MCSE, MVP
http://www.LearnQuick.Com
(phone on web site)



.

Loading