VPN client cannot connect to domain through "my computer" properties. What am I doing wrong?

Check that your firewall is not blocking the the ports required for domain logon.  Whether or not that's possible will depend on your network architecture.  The VPN needs to bridge an external (WAN) segment and the internal LAN or else you're going to be subject to all firewall rules regulsating outside traffic.

OK - now that I read tha tit looks kind of stupid, since bridging LAN and WAN is what VPN does,.  More specifically, I meant it needs to bridge to an unrestriceted LAN segment.

the most commin error i found with VPN is DNS resolutions

edit the HOSTS file ( \windows\system32\drivers\etc - on winxp ) and add a line similar to

IP ADD                              servername

e.g.

10.0.0.2                       domainserver1

to the end, and try again

although adding to a domain remotely isn't really recommended

hope this helps

:o)

Try adding a LMHOSTS file entry:

How to Write an LMHOSTS File for Domain Validation and Other Name Resolution Issues
http://support.microsoft.com/support/kb/articles/Q180/0/94.ASP 

Try loggin on to VPN before you logon to the Domain. When the CTRL-ALT-DEL option to login comes up, use the login using dial-up netowrking option and choose your VPN connection. THis way you will bo on the network before you login, then it will authenticate you on the domain.

dagger3d, very good point.
That assumes that the client PC has actually joined the domain at some point, and can actually find the domain controller with the proper WINS/DNS entries provided to the client...
... that appears to be the problem at this point...

Are you trying to ping DC by name or by IP... I have seen lots of name resolution issues over vpn.  If you can ping the DC by IP, but not by name then this is the case.  A good place to start might be to take the .sam extension off of your lmhosts file and add the following entry:

x.x.x.x  domaincontroller #PRE  #DOM:domain  #PRE

replace x.x.x.x with ip address of your domain controller
replace domaincontroller with the name of your DC
replace domain with the name of your domain.

Also, add entries for anything else this machine is going to need to see by name on the inside of your network in similar format

x.x.x.x  machinename

Thanks all
.  I am trying these options now.

Darn did all these things and no dice.  

I can ping the DC by IP now but thats it.

Any services I should check on the VPN server?

What kind of connection are you using to connect to the VPN?  Can a machine already on the domain connect to all of the internal resources properly?  We've seen a lot of issues with DSL/PPPoE connections and VPN, and usually changing the MTU on the network connection helps resolve the issue.  

"Usually, once you establish a vpn session, you are logically inside the network so the firewall is probably not blocking anything." - mrrickyjones

Yes.  I just tested a dial up connection that got in just fine.  It is a DSL connection in fact we are having trouble with.  Please explain MTU?  Thanks.

Check out this FAQ from DSL Reports:

http://www.dslreports.com/faq/7801

I've noticed that a lot of times for SBC here in the Chicago area, 1350 is a good MTU that works.  As the FAQ suggests, it's probably best to check with your ISP to see what is the optimum MTU for your connection if 1350 doesn't work for you.

Thanks guys.  We are still having trouble getting those 2 guys to even ping the server by ip address once connected Via VPN.  This is weird.

Looks like the one location ISP is blocking protocols completely.  Can anyone suggest another VPN option ?  MS mentioned something like a UDP packet option...Not sure..Anyone?

If you can establish the VPN connection and can Ping across it, then the ISP can't see anything at all that is going on inside that VPN tunnel. You can't block what you can't see.

"If you can establish the VPN connection and can Ping across it, then the ISP can't see anything at all that is going on inside that VPN tunnel. You can't block what you can't see."

?Does not compute?

I guess I jumped the gun on that... you can't ping, can you?
What I meant was, if you can establishe the VPN, then that means that both TCP port 1723 and GRE are permitted through the ISP. TCp port 1723 is used simply to setup the dedicated, encrypted, tunnel between the server and the client using GRE. All traffic between this server and the client is encapsulated within that GRE stream. The ISP cannot see what is inside that tunnel. If the ISP can't see the ports/protocols inside that tunnel, they can't block any either. Even if they block, say UDP port 138, it doesn't matter because all any of their equipment sees is the GRE stream. They can block all the ports they want, but as long as GRE is permitted, and you can establish a GRE tunnel between the server and a client, then you can do whatever you want within that tunnel, including icmp pings.

Here's an example. I have a VPN tunnel open to my office, and my ISP blocks ICMP, yet I can still ping "through" my tunnel to my office, and the ISP can't stop it:

C:\WINDOWS>ping www.cisco.com

Pinging www.cisco.com [198.133.219.25] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 198.133.219.25:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\WINDOWS>ping bingo   <== my server

Pinging BINGO [229.35.x47.74] with 32 bytes of data:

Reply from 229.35.x47.74: bytes=32 time=34ms TTL=127
Reply from 229.35.x47.74: bytes=32 time=37ms TTL=127
Reply from 229.35.x47.74: bytes=32 time=36ms TTL=127
Reply from 229.35.x47.74: bytes=32 time=36ms TTL=127

Ping statistics for 229.35.x47.74:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 34ms, Maximum = 37ms, Average = 35ms

C:\WINDOWS>

If you can't ping by either name or IP address, then you have a separate issue. Can you possibly have the same IP subnet on the LAN at both ends?
If you could ping by IP but not by name, then you have a Microsoft name resolution problem.
If you can ping by IP and by name, but can't map drives, then you have a Netbios name resolution/ domain permissions problem

Thanks much for your input Lrmoore.  It took adding the user to the admins group to allow him permission to logon to the domain interestingly enough.  I also found that adding the internal DNS server to the VPN connection solved some of the problems.  LAst of all, there was a conflict of internal ip's as the client netwrok had the same addresses as my remote.  It just so happens that my exchange server is on a domain controller.  I wonder if I would have to demote that machine in order to not require them to have admin permissions to access resources?

Sp0cky, are you still working on this? Can you close out this question before the cleanup crew comes by?

Thanks!