I use Vista as my primary desktop (replacing Windows XP)

When I create a PPTP tunnel to a remote site (a client), all seems well, I can ping computers on the remote site, and I can ping my local servers.

I can RDP to remote servers via the VPN tunnel, and I can RDP to local servers also.

BUT:  After a short while I notice that my drives mapped to local servers come up with a red cross (No access).  Of course I can ping the local server, and RDP to it.

Delving into the issue I open a CMD prompt and run:

This always results in:

Now, as usual for my VPN connections it is not set to use the VPN as my default gateway (That box is unticked under TCP/IP v4).  This is confirmed by my ability to RDP to 'localserver' even when the VPN is established.

I have unticked tcp/ip v6, Microsoft Client and Microsoft Server in the VPN connection to no avail.

It would appear that Windows Vista is passing my VPN credentials to ALL machines that I try to connect to via SMB/CIFS, not just those that are located through the VPN.

This differs greatly from Windows XP, which would pass my normal credentials (or service ticket) to local machines and my VPN credentials to machines accessible via the VPN.

So, basically when VPN'd I can no longer access any local SMB/CIFS resources.

I have confirmed this against several clean vista builds.

I have no idea how to resolve this, obviously it will be a bit of a killer for corporate machines connecting to a remote resource via VPN to suddenly lose access to their local file servers / printers!

I sincerely hope this is not a security measure!

Regards,

VirtualG.

OMG! Finnally! Someone experiencing the same problem.

I noticed that the remote DNS server (over the VPN) appears to beat out my local DNS. I thought that maybe my client's request for a DC was being satisfied by the remote network via DNS lookup of ?any? available DC.

Also I have found that if I Start | Run | enter UNC of server I am prompted for credentials (which default to my VPN credentials) at which time I can enter my local domain credentials and then have access to the local resources on that server.

Please post back here if you find a solution. I'll do the same. Thanks again for your post. I AM SANE AFTER ALL!!!!

And the winner is.... http://groups.google.com/group/microsoft.public.windows.vista.networking_sharing/browse_thread/thread/22d0d3590987e9ed/d33616e810d66619?lnk=st&q=vista+vpn+wrong+credentials+domain&rnum=1&hl=en#d33616e810d66619

A little more pain for a lot of gain.

Using the FQDN will always allow correct access to your local network, but does not always present the correct credentials to remote systems.

For example just create two simultaneous VPN tunnels to two different networks.  Using the FQDN does not present the correct credentials to each network.  Actually the Credentials Manager only remembers the last set of VPN credentials!

There is a problem with Microsoft's Credentials Manager.  It is not correctly determining which credentials to give to each resource.

I have esculated this issue with Microsoft, and they are now aware of the problem (read - it was not the indended or expected behaviour).  What this means in terms of an actual fix, I don't know (timeframe / availability).

Remember under windows XP/2k/2k3 the credentials manager would correctly determine which set of credentials to use for each resource (regardless of FQDN or not).  So this is actually a bug.

A workaround given by Microsoft is to run the following command after establishing the VPN tunnel.

cmdkey /delete /ras

OR

Use the FQDN to access local resources

By using the "cmdkey /delete /ras" command you are removing the VPN credentials from the Credentials manager.  In doing this you will regain access to your local resources without having to use FQDN names.  But you will have to specify credentials if you want to access remote resources (SMB / CIFS) via the VPN.

If you only establish a single VPN tunnel and have control over your drive / printer mappings (i.e. Not controlled by a corporate login script or group policy) then ensuring everything is being mapped by FQDN will work.

If you establish multiple VPN tunnels then you are out of luck regardless of using FQDN or not, the credentials manager only remembers the last set of VPN credentials.  And when you disconnect one of the VPN's you will lose all VPN credentials, hence using the FQDN to access a remote resource (i.e. via the currently established VPN - SMB / CIFS resources) it will fail.  (Assuming each VPN tunnel uses different domains / usernames for authentication).

This has been a long road!  Hopefully Microsoft will correct this issue soon.

I have the same issue and will try the FQDN when mapping drives but I also lose my connection to Exchange server 2003 which is connecting with a FQDN. Any thoughts?

I think this issue is not solved yet. There a are still 2 problems, right?

1. When you make a VPN connection Vista uses the remote DNS-server as primairy DNS-server. If you try to contact your local shares e.g. \\srv.domain.local\docs the remote DNS-server cannot resolve this. One work-around is to add srv.domain.local to the hosts-file. But this doesn't work for a distributed file system e.d. \\domain.local\dfs or other DNS-lookups, rather than A-records. Besides using host files is not a very elegant solution.
2. When you make a VPN connection you can access shares in your local network to which you have anonymous access (e.g. NETLOGON) but for some reason with the credential manager not to shares for wich you have to authenticate. Vista does not ask for credentials but just denies access "You do not have permissions to use this network resource". "An unexpected network error occured".

Does anyone has solutions to these problems yet?

This is NOT a DNS issue. The names have already been resolved so there is no need to query  a DNS server after the connection has been made.

At this point we still have no resolution for this even after trying everything above. Hopefully Microsoft will sort this with SP1. Meanwhile I have resolved it by going back XP

Thanks Microsoft!

Jon,

 As you pointed out this is not a dns resolution issue, it is a credentials issue.  As I pointed out above.

Non FQDN names will be accessed using the last RAS credentials supplied, meaning your local resources will disappear on you.  Great one MS.

I personally have just being using:

cmdkey /delete /ras

To remove the RAS credentials as soon as I have formed the VPN tunnel, so that my local resources (including Outlook -> Exchange Server) keep working.  Are you saying that this does not work for you?  Of course this means you will have to supply credentials to access remote resources, but mostly I use VPN for RDP access so this is not a problem.

I will be testing this against Vista SP1 Beta as soon as MS let me have access to it, if it is not fixed in the SP1 Beta I will raise it again with MS.  Even though I have raised it on both fronts (Functionality, and Security - Passing wrong credentials to remote systems, and even passing local credentials to remote systems if you do things in a certain order), I have not had any formal - "Oh we stuffed up there and are going to fix it" notification.

Makes it quite hard to see how Vista is going to work in a corporate environments really!!

Cheers,

VirtualG.