VPN problem 1

[vanna520]

I can't resolve a problem I'm having with VPN user (win2000). It seems that he can't connect to a share drive, although he can access exchange server and his e-mail. Our system is behind Netscreen50 firewall and most of my users have VPN access (no problems).
The hosts script in etc directory is ok and as I already mentioned, he can't access only one of our servers.

It seems strange not to be able to access that if he can access rest of the network.

Does anybody have a solution for this problem?

 

[vishuonline]

probably the user might not have sufficient privileges to access the specified resource..he/she might not be in the group that that has been 'permitted' access to the resource.

helpful?

 

[GuiTech]

I am battling the same exact problem in our company. From what I can see, the problem is very random; I can't put together enough common configurations to nail down the source.

Scenario #1: I have a company IBM T23 laptop which is running Win2kSP3 and the Nortel Client 465_09 (465_18 performs the same). In my lab at work, I have a Verison DSL connection 760k up/down. I can VPN in with no problems, no matter what. Another person with an IBM T22 laptop and the same software setup (we baseline company PCs using a syspreped ghost image) can't map network shares when booting off the network. When this T22 boots on the network and hibernates/standby, and then connects through VPN, they can map network shares. ????

Scenario #2: The same T23 laptop that works on the DSL line has these problems on my home Adelphia Cable modem (128k up/1.3m down). When I plug the laptop in and creat the tunnel, I can't get to network shares, but can get email and iis server pages. It doesn't work even if I hibernate. The only way I can get it to work form home is to reboot the modem, linksys router and the laptop. Sometimes after rebooting, I have to plug into the modem itself. Also, it will not work after a while and I will need to reboot.

In both locations we are using linksys routers. This is also a problem at our Japan and Brussels sites. We have standardized computers and software, but they have different hardware. The point is, the hardware is random so I can't say that it's the router and we also see the problem on home users running whatever hardware running WindowsXP.

I have a case open with Nortel, but they have been no help yet. I have seen this problem before in this forum, but never saw any solutions.

I really hope that someone has some inside info on this.

Thanks

 

[snsh]

Maybe your VPN problems are due to subnetting.

I once worked on a startup's LAN that grew quickly to about 500 hosts (two octets worth). This tranformed one network into two, but the subnet mask stayed 255.255.255.0 when it should have changed to at least 255.255.252.0. And all our NT4 domain controllers stayed in one subnet, not the other. It seemed to work because our monster Cisco switch seemed to manage the traffic okay.

The problem created was that during login, WinNT clients in the 2nd subnet couldn't find a nearby domain-controller, so they got share-mounting errors. If a domain controller had existed in the 2nd subnet, its MAC would have remained handy in each host's ARP cache. But since the domain contoller existed in a foreign subnet, it wouldn't stay in the ARP cache and it took a long time to find it.

The error seemed intermittent because each time we rebooted a NT4 PC, we couldn't predict what subnet DHCP would assign it to. We were playing musical IP's. Occasionally we even ran out of internal IP addresses.

The sysadmin eventually fixed the timeouts by moving a domain controller to the second subnet.

So, check the subnetting, the ARP caches, and the locations of the domain controllers. You might find your answer there.

 

[John Lewis]

I tend to agree that these problems are a result of subnetting. SMB generally relies on broadcasts to provide browsing information, and broadcasts do not cross subnets (when everything is working correctly).

Make sure that you are running a WINS server, and the clients are configured to poll the WINS server. If a WINS server is not an option, browsing can be accomplished by using a lmhosts file. Not pretty, but it works.

To verify that you are seeing a name resolution issue, open a command prompt on the client.

Type 'net view \\COMPUTERNAME' replacing COMPUTERNAME with the name assinged to the server in question. Should give a list of the shared resources on the server. If an error is reported, name resolution is a possible issue.

Try again, this time 'net view \\xxx.xxx.xxx.xxx' replacing the xxx with the server's IP. Again, this should provide a list of resources on the server. If this works and the computername method does not, pretty well confirms a name resolution issue. If this does not work either, it does not rule out that name resolution issues exist, but it does inidicate that another problem exists as well. Make sure that NetBIOS is running on the VPN connection of both the client and the server, for starters. Check IP addresses. If you have not already done so, try to ping the server by name and by IP to check connectivity.

When reporting errors for further assistance, be as specific as possible. One very important point, 'ping' always works. Might not give the response you want, but don't say 'ping doesn't work'. Report the specific error message, as each of the dozen or so messages can indicate a different problem.

 

[GuiTech]

Thanks for the information. I will give this a shot when I get the the faulty connection. By the way, isn't Microsoft canning support for NetBios?

 

[GuiTech]

Ok, here is the result. I took my laptop home and created the tunnel. As normal, I can get mail and corp. intranet. I could ping our netlogon server, but it took a few moments before the replies came back, with no delays. I ran the net view \\server and after a few moments, got "Access denied". It's as if I didn't get authenticated. Is there some vehicle that should send out my security token?

 

[KenBailey]

Have you tried to force kerberos to always use tcp and not udp? The registry entry is:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]
"MaxPacketSize"=dword:00000001


It seems to fix our W2K share mapping issues.

 

[GuiTech]

Sounds like a plan. I will try it tonight and let you know.

 

[GuiTech]

KenBailey, you are really on top of things. There is a Microsoft Q article on this 244474. It works perfectly and we have a lot of happy people in Brussels and Japan thanks to you and this forum. Thank you KenBailey and thank you tek-tips for hosting such a site. If you really dig deep, you have saved lives today. We are a medial device manufacturing company and you had contributed to a company that saves lives.

Once again, THANKS