can't map to a network drive while using Secure Remote

barthalamu
barthalamu used Ask the Experts™
on
Hello:

I am able to log into my network through a Checkpoint Secure Remote connection from home just fine.  From there, I can ping, connect to servers using terminal services, etc.  Everything seems fine, until I want to map a drive from my home computer to one of the servers in the office network.  The permissions are fine.  It just doesn't map it.  It says it cannot find it.  I have tried it both by name and IP address.  I can ping the IP address however, and can see the little checkpoint envelope in the systray sending data both when pinging the address (which works) and while trying to map a drive. (which doesn't)

I can't think of anything blocking it at this point.  No firewall on my home machine or on the server in the office is blocking it.  Once I VPN into the network, no firewall is in between my connection and the server.  Of course I can map this drive just fine on an office pc, just not while I am connected via VPN.

Is there something I am missing??  I do not control the Checkpoint server, could it be being blocked by the checkpoint server??  Thanks for the help.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®

Commented:
I run checkpoint fw at my location, a lot of times it is just the isp that users have that make this difficult... you said you've tried to map the drive by ip as in \\172.16.20.25\c ? usually when i have this issue with a user, i just ensure that the mapping is done by ip as stated above... \\172.16.20.25\c

and edit lmhost and host files with server names to ip address's..

AL
Is your home machine XP Pro? and if so, are you authenticating against a server at home? If so, try to attach to the office share without authenticating against your home server.

Try creating a local logon on your home machine with the same username and pasword as you use at the office.   Try logging off and back on as that user just before attaching to the remote resource.  If your using 98, you may need to wipe the .pwl files in the Windows directory.

Also, check to see if you have an lmhosts file, if so make sure there is nothing goofy in it (like the wrong address for the foreign network's security providers)  

Finally, try creating a local lmhosts file containing at least one member controller on the foreign network (via the #DOM:domain and #PRE: attributes)

Good luck
Afro
Normally a Checkpoint configuration does not block traffic inside a VPN tunnel (although it is perfectly possibe). As stated by afrosonic, you could try to use a lmhost file -or- use WINS to resolve client names. Did you enable Client for Microsoft Networks on your adapter that connects via VPN? It is still needed if you want to do mapping or use Outlook Exchange.
Introduction to Web Design

Develop a strong foundation and understanding of web design by learning HTML, CSS, and additional tools to help you develop your own website.

Author

Commented:
Thanks for everyones responses, unfortunately they did not help...

foad:  Yes, I have been trying to map to the share using the full path, and the IP address as the computer name.  As I said, I can ping the computer by IP address, just not map a drive.

afrosonic:  My home machine is windows 2000, as is the remote machine.  Although I am getting a "network path \\192.168.11.203\doc_share could not be found" and not a username or password problem, I did create matching users and passwords on both the machine at home and at the office.  I checked out both computers' lmhosts files...nothing wrong there.  Also, the remote computer is in a domain at all, so I did not try the #DOM and #PRE directives.

Darq_Messiah:  Both machines have Client for Microsoft networks enabled.


Thanks for all the help.  Please let me know if you have any more suggestions.  Thanks!

Commented:
what about going into the network properties, lan connection and add your corportaes WINS server address? this has helped me before...

Commented:
Hi All,

  WINS is just one part of the issue. The SecureRemote client has a setting for Domain Logon, which has to be set in order for this to work.
Check the menu for something called SDL (Single Domain Logon). This will make sure that your password will be passed on via the VPN
to the Domain Network.

  By default, Windows Domains are not routed from the local network, and while working with a VPN client, you're in routing mode.
Enabling that feature will ensure that the firewall will present itself to the domain as you, and will allow that NBT traffic to go through
correctly. If you would like to resolve by names, make sure that you have a WINS server installed on your domain controller, make
sure that you enable WINS on your dial-up adapter, and you should be OK.

  I also suggest configuring the SSO option in SecureRemote (Single Sign-On), it will save you many times of entering your VPN
passwords over and over and over again.

Regards,
  NocMan
  AKA: Lord Stroud
  www.net-gurus.net

Author

Commented:
nocman:

Thanks for the advice.  The computer that I am trying to map a drive to is not even associated with a domain though.  It is just a stand alone computer.  Is there something special that needs to be done to map a drive to it??

Thanks for the help.

Commented:
Hmmmm.....

Nothing really needs to be done in order to map a drive, it's a built-in functionality. However, I would suggest trying
installing a WINS server on the network. Apart from that, I'm not entirely sure.
What version of CheckPoint are you using exactly ?

NocMan

Author

Commented:
Hello All:

I did install a WINS server on my network, but it did not seem to help the situation.  I also added the WINS server to my network adapter at home, and tried using an lmhosts file, but this did not work either.

I noticed that "NetBIOS over TCP/IP" was disabled, so I enabled it.  Again this did not help matters though.

nocman:

Unfortunately I am not sure what version of Checkpoint it is.  It is a checkpoint server for the entire building, which is administered by the building, and not my company.

Thanks for all the help.  Can anyone think of anything else to try??  Thanks.
Commented:
Hi There,

  Well, if the firewall is managed by someone else, I suggest that you check with them
that the "Client Encryption" rule that is configured for allows NBT protocols traffic. If it
doesn't, mapping a share from a remote computer will never work.

NocMan
Hi barthalamu,

If your attempting to access a shared folder on your home pc from your office site have you attempted to access it by connecting as a different user name. The different user name being one that is local to the resource. As in follows:

Choose drive letter you wish to assoccaite with the share
enter path \\192.168.11.203\doc_share

Then select connect using a different user name

In the selection box enter the appropriate detail.

Username = if not a member of a domain then workgroup name
eg. workgroup\user account which has local rights to the shared folder.
Then the password which allows that account access.

I think your home pc is not identifying your office domain/user account as the account which has the permissions to access it's shared folder.

I hope this can assist in your efforts to gain access to your home pc share.



Even though most possible things have been said, I'd like to get some order into things:
1) if the client-encrypt rule doesn't allow NBT traffic, then it simply won't work
2) in order to resolve internal NBNS names (aka WINS), you either have to set the internal WINS servers into the adapter's props, or, a better (possibly) way to do this is to use a feature called split DNS, and it's sister split WINS - it demands some configuration on the FW though - and is no longer supported.
The best solution for the internal resolving is Office Mode, but this means you must use SecureClient, AND it anyway demands configuration on the FW.

But this is just for your info. this won't help as you are also trying to \\IP

As it sounds now, I'd bet 10 points that it's just the rulebase. It's not a wide accepted opinion that opening up browsing for the outside is a good idea...

Oh, completely forgot.
Nocman, SDL is a Secure Domain Logon, and what it does - it prevents Netlogon service to be started before SR_Service is - then SR creates a VPN channel with the FW, and passes your Windows logon credentials to the PDC or AD.
AFAIK, SSO doesn't help you with reauthentications, it just saves the first one, but if you have 'cached credentials' option turned on, this will spare some pop ups.

Commented:
True True, I simply forgot :-)

Author

Commented:
Thanks to all.  I was able to get a hold of the people who manage the VPN (no easy task) and I found that they indeed to block this access.  I have since set up my own VPN.  Thanks for all the help!!

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial