I will elaborate as much as possible....
Our company is changing to a new physical location, aside
from a few employees, who will remain at the old location.
I had a few employees move to the new place before the
server was there, and myself and another who were running
XP pro could authenticate to the server at the old place
via the VPN from the new place, but the windows 2k clients
could not.
I am trying to get windows 2k clients(at the old location)
to connect via an IPSEC (hardware based) VPN connection to
a windows 2k server DC at the new location. The remote
clients are connecting via a Netgear VPN/Firewall router
(old location), to a Hotbrick 600/2 VPN/Firewall(new
location). The tunnel is good. If I log the client in
locally(old location), then I can see the server and map
drives, after entering a username and password for the
domain at the servers request. Trying to log in to the
domain from the old location won't work. The clients will
not authenticate to the server, but they can see the
server on the other end if you search for the it's IP
address. So it would seem that communication is there, but
the clients just won't authenticate at login. Again, the
server was behind the netgear a few days ago(old
location), and a windows xp pro client could authenticate
properly via the same tunnel just in the opposite
direction, but win 2k client could not. The server is now
behind the hotbrick at the new location. I have not tried
to authenticate to the server with an XP client from
behind the netgear(old location). I dunno if this is a
network policy problem within the netgear maybe, or maybe
its a LMHOST file problem and the clients cant find the
actual domain name.
-----Original Message-----
What OS are the client?
There is not alot to go on here but it sounds like you may have created an
ipsec policy that also secures all traffic between the clients and DC, this
is not a supported scenario at present.
For example you might have secured ICMP which will prevent clients talking
to the DC and getting correct IPSec policy, but there are other protocols
too that interfere with client to DC communications.
Can you elaborate please when you say the XP pro laptop works just fine?
--
Stephen Cartwright [MSFT]
"This posting is provided "AS IS" with no warranties, and confers no
rights."
Just trying to have the clients connect to the DC on the
other end of the tunnel. Authentication never happens,
even though you can see the server via its IP over the
network, so I can't map drives, shared printers, etc. I
know the tunnel is good because if I take my XP Pro laptop
and try it works just fine. And there are no errors on the
endpoint devices - but just so you know - some of the
security are as follows: Pre-shared key, 3DES Encryption,
and perfect forwarding secrecy is DISABLED. NETBIOS is
enabled at both VPN/Firewalls.
Appreciate the help!
.
