Checkpoint won't run in Remote Desktop session

[Guest]

Archived from groups: comp.security.firewalls (More info?)

We are a software development and support company supporting our
clients Intranet via VPN.

We have been requested by our client to use Secu Remote to obtain
access to their network.

Since we have a number of developers requiring access to support, we
have configured a single workstation as a Windows 2003 server machine
with the necessary tools and checkpoint vpn. The idea being that we
can tie down security and control a single machine environment far
easier than a number of disparate machines. The plan was that
developers would need to connect to this 'Client Gateway' server using
Remote Desktop and then effectively use this session to connect to the
client machine.

Problem: when anyone logs onto the Client Gateway Server using Remote
Desktop they are unable to run Checkpoint. Double clicking on the
program launch does nothing at all. No error messages or anything,
just nothing.

If the same user logs on locally to the same Client Gateway server,
then all is fine. I'm wondering if the issue is something to do with
file security on the server or perhaps Checkpoint not being able to
run in a session.

Do you know if there is a way around this that would enable remote
connections to run Checkpoint on a win2003 server machine?

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

ARe you sure you are making the correct request?

Remote access to resources on the system is not the samed thing as GUI
access to the Firewall. One is a user function the other is administrative.

SecuRemote is the Checkpoint interface for VPN access, you could also use
L2TP, but that introduces a whole new list of problems.
SecuRemot/SecureClient require a client loaded on the local machine, proper
configuration and topology download, correct configuration on the remote
server...

1. what is your intent, to access files, resources on the remote system or
actual control of the Firewall?

2. Was a SecuRemote Client and/or configuration (site configuration)
provided, either by transfer of the requried values or a preconfigured
download or floppy... or are you expected to figure it out?

3. If the "Icon" doesn't open, then it most likely is improperly configured.
You can download a virgin copy of the SecuRemote/SecureClient, free of
charge, from Checkpoint site.

You also mention a Client Gateway server. This is again, a different issue
from either of the above. Using a Gateway, would lead me to believe you are
attempting an "ExtraNet" which is more involved, but ultimately could be a
better solution.

More info please?.

"Alan Cox" <alan.cox@leftclick.co.nz> wrote in message
news:5cf17c37.0405040202.3077f6fe@posting.google.com...
> We are a software development and support company supporting our
> clients Intranet via VPN.
>
> We have been requested by our client to use Secu Remote to obtain
> access to their network.
>
> Since we have a number of developers requiring access to support, we
> have configured a single workstation as a Windows 2003 server machine
> with the necessary tools and checkpoint vpn. The idea being that we
> can tie down security and control a single machine environment far
> easier than a number of disparate machines. The plan was that
> developers would need to connect to this 'Client Gateway' server using
> Remote Desktop and then effectively use this session to connect to the
> client machine.
>
> Problem: when anyone logs onto the Client Gateway Server using Remote
> Desktop they are unable to run Checkpoint. Double clicking on the
> program launch does nothing at all. No error messages or anything,
> just nothing.
>
> If the same user logs on locally to the same Client Gateway server,
> then all is fine. I'm wondering if the issue is something to do with
> file security on the server or perhaps Checkpoint not being able to
> run in a session.
>
> Do you know if there is a way around this that would enable remote
> connections to run Checkpoint on a win2003 server machine?


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.676 / Virus Database: 438 - Release Date: 5/3/2004

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

Thanks for your prompt reply Beoweolf, much appreciated.

1. We need remote access into our clients network for transfering
files both ways, installing applications and updates, accessing their
intranet and document management system. We currently do this by
firstly starting a checkpoint session and then using either remote
desktop or Citrix client depending on what it is that we need to do.

2. SecuRemote Client has been provided to us by our client for this
purpose. Currently each user here has a copy of Checkpoint on there
own desktops and all works fine.

This does have some problems though such as developer machines are not
accesible from outside our network and so if they are out of the
office and we need them to do some work on the client system then they
have no option but to come back into the office.

So, we have set up a single server machine with the intent that any
user can access this machine remotely and then gain access to the
client network by firing up checkpoint within that session. This
server is what we are calling the 'client gateway', perhaps a poor
name, but it makes sense to users here.

The problem is that when a user is running a remote desktop session to
this server, they are unable to start checkpoint. But if they log on
locally to the same server with the same login credentials then they
can start checkpoint. It's as if checkpoint won't run in a session,
rather only when the user is logged onto the terminal.

Is there any way around this?

I hope this helps to clarify the use case.

Alan

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

The additional information does help to detail your situation better.

If I understand it correctly I see two major solutions.

1). Contact the administrator of the other system and arrange for individual
remote access for those parties that need at-home , remote access, in
addition to site to site access. This is the most simple resolution, it
would require closer coordination between the two admin groups...you would
need them to send weekly, monthly activity/status reports from their logs of
access times, Ids, etc...in addition, you would need to inform them of
status changes, terminations, downgrade of status-instead of it being an
in-house function.

2.) Run Checkpoint vpn-1/fw-1 NG or NG-AI, the VPN routing function would
allow you to route calls from home users, thru vpn hub, it will accept
calls from your users then reroute them thru the active connection to the
extranet system. You might need to manually configure the VPN_route file on
your side. This solution, is not that complex, but is a little more involved
than just coordinating a remote user access plan with the other admin. Is
this of any use?

"Alan Cox" <alan.cox@leftclick.co.nz> wrote in message
news:5cf17c37.0405041357.5567979a@posting.google.com...
> Thanks for your prompt reply Beoweolf, much appreciated.
>
> 1. We need remote access into our clients network for transfering
> files both ways, installing applications and updates, accessing their
> intranet and document management system. We currently do this by
> firstly starting a checkpoint session and then using either remote
> desktop or Citrix client depending on what it is that we need to do.
>
> 2. SecuRemote Client has been provided to us by our client for this
> purpose. Currently each user here has a copy of Checkpoint on there
> own desktops and all works fine.
>
> This does have some problems though such as developer machines are not
> accesible from outside our network and so if they are out of the
> office and we need them to do some work on the client system then they
> have no option but to come back into the office.
>
> So, we have set up a single server machine with the intent that any
> user can access this machine remotely and then gain access to the
> client network by firing up checkpoint within that session. This
> server is what we are calling the 'client gateway', perhaps a poor
> name, but it makes sense to users here.
>
> The problem is that when a user is running a remote desktop session to
> this server, they are unable to start checkpoint. But if they log on
> locally to the same server with the same login credentials then they
> can start checkpoint. It's as if checkpoint won't run in a session,
> rather only when the user is logged onto the terminal.
>
> Is there any way around this?
>
> I hope this helps to clarify the use case.
>
> Alan


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.676 / Virus Database: 438 - Release Date: 5/3/2004

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

Hi Beowolf.

Once again, many thanks for your reply.

You understand correctly but what I guess I was hoping for is a reason
as to why checkpoint will not work when running inside a remote
desktop session. Is it that it will only run when the user is logged
on to the terminal? Or could it be a security issue? Either way, is
there a way around this?

Thanks.

Alan

"Beoweolf" <Beoweolf@pacbell.net> wrote in message news:<iS7mc.5432$v%3.3355@newssvr27.news.prodigy.com>...
> The additional information does help to detail your situation better.
>
> If I understand it correctly I see two major solutions.
>
> 1). Contact the administrator of the other system and arrange for individual
> remote access for those parties that need at-home , remote access, in
> addition to site to site access. This is the most simple resolution, it
> would require closer coordination between the two admin groups...you would
> need them to send weekly, monthly activity/status reports from their logs of
> access times, Ids, etc...in addition, you would need to inform them of
> status changes, terminations, downgrade of status-instead of it being an
> in-house function.
>
> 2.) Run Checkpoint vpn-1/fw-1 NG or NG-AI, the VPN routing function would
> allow you to route calls from home users, thru vpn hub, it will accept
> calls from your users then reroute them thru the active connection to the
> extranet system. You might need to manually configure the VPN_route file on
> your side. This solution, is not that complex, but is a little more involved
> than just coordinating a remote user access plan with the other admin. Is
> this of any use?
>
> "Alan Cox" <alan.cox@leftclick.co.nz> wrote in message
> news:5cf17c37.0405041357.5567979a@posting.google.com...
> > Thanks for your prompt reply Beoweolf, much appreciated.
> >
> > 1. We need remote access into our clients network for transfering
> > files both ways, installing applications and updates, accessing their
> > intranet and document management system. We currently do this by
> > firstly starting a checkpoint session and then using either remote
> > desktop or Citrix client depending on what it is that we need to do.
> >
> > 2. SecuRemote Client has been provided to us by our client for this
> > purpose. Currently each user here has a copy of Checkpoint on there
> > own desktops and all works fine.
> >
> > This does have some problems though such as developer machines are not
> > accesible from outside our network and so if they are out of the
> > office and we need them to do some work on the client system then they
> > have no option but to come back into the office.
> >
> > So, we have set up a single server machine with the intent that any
> > user can access this machine remotely and then gain access to the
> > client network by firing up checkpoint within that session. This
> > server is what we are calling the 'client gateway', perhaps a poor
> > name, but it makes sense to users here.
> >
> > The problem is that when a user is running a remote desktop session to
> > this server, they are unable to start checkpoint. But if they log on
> > locally to the same server with the same login credentials then they
> > can start checkpoint. It's as if checkpoint won't run in a session,
> > rather only when the user is logged onto the terminal.
> >
> > Is there any way around this?
> >
> > I hope this helps to clarify the use case.
> >
> > Alan
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.676 / Virus Database: 438 - Release Date: 5/3/2004

 

[Ron Johnson]

DID THIS EVER GET RESOLVED? I AM HAVING THE SAME PROBLEM.

Archived from groups: comp.security.firewalls (More info?)

Hi Beowolf.

Once again, many thanks for your reply.

You understand correctly but what I guess I was hoping for is a reason
as to why checkpoint will not work when running inside a remote
desktop session. Is it that it will only run when the user is logged
on to the terminal? Or could it be a security issue? Either way, is
there a way around this?

Thanks.

Alan

"Beoweolf" <Beoweolf@pacbell.net> wrote in message news:<iS7mc.5432$v%3.3355@newssvr27.news.prodigy.com>...
> The additional information does help to detail your situation better.
>
> If I understand it correctly I see two major solutions.
>
> 1). Contact the administrator of the other system and arrange for individual
> remote access for those parties that need at-home , remote access, in
> addition to site to site access. This is the most simple resolution, it
> would require closer coordination between the two admin groups...you would
> need them to send weekly, monthly activity/status reports from their logs of
> access times, Ids, etc...in addition, you would need to inform them of
> status changes, terminations, downgrade of status-instead of it being an
> in-house function.
>
> 2.) Run Checkpoint vpn-1/fw-1 NG or NG-AI, the VPN routing function would
> allow you to route calls from home users, thru vpn hub, it will accept
> calls from your users then reroute them thru the active connection to the
> extranet system. You might need to manually configure the VPN_route file on
> your side. This solution, is not that complex, but is a little more involved
> than just coordinating a remote user access plan with the other admin. Is
> this of any use?
>
> "Alan Cox" <alan.cox@leftclick.co.nz> wrote in message
> news:5cf17c37.0405041357.5567979a@posting.google.com...
> > Thanks for your prompt reply Beoweolf, much appreciated.
> >
> > 1. We need remote access into our clients network for transfering
> > files both ways, installing applications and updates, accessing their
> > intranet and document management system. We currently do this by
> > firstly starting a checkpoint session and then using either remote
> > desktop or Citrix client depending on what it is that we need to do.
> >
> > 2. SecuRemote Client has been provided to us by our client for this
> > purpose. Currently each user here has a copy of Checkpoint on there
> > own desktops and all works fine.
> >
> > This does have some problems though such as developer machines are not
> > accesible from outside our network and so if they are out of the
> > office and we need them to do some work on the client system then they
> > have no option but to come back into the office.
> >
> > So, we have set up a single server machine with the intent that any
> > user can access this machine remotely and then gain access to the
> > client network by firing up checkpoint within that session. This
> > server is what we are calling the 'client gateway', perhaps a poor
> > name, but it makes sense to users here.
> >
> > The problem is that when a user is running a remote desktop session to
> > this server, they are unable to start checkpoint. But if they log on
> > locally to the same server with the same login credentials then they
> > can start checkpoint. It's as if checkpoint won't run in a session,
> > rather only when the user is logged onto the terminal.
> >
> > Is there any way around this?
> >
> > I hope this helps to clarify the use case.
> >
> > Alan
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.676 / Virus Database: 438 - Release Date: 5/3/2004

 

[Ron Johnson]

Has this been resolved. I would like to see the solution because I am having the same problem.