Wei,
> Thanks for your reply.
No probs.
> Frankly I'm not very familiar with Securemote... This is how the network
> layout looks like
>
> Securemote client --> Our (ISP) proxy --> Checkpoint FW1
In theory, if it's going through a proxy the firewall will see the address
of the proxy, not that of the client.
SecuRemote works as follows:
1) Client requests network topology from remote firewall (this is when you
add the firewall in to SecuRemote). The topology describes what networks
are behind the firewall. (this happens on TCP port 256 or 264 dependant
on SecuRemote version)
2) When SecuRemote sees a packet destined for a network behind the remote
firewall it establishes an encrypted session to the firewall and then
authentication takes place (be it reusable password SecurID, Radius, etc.)
(this authentication is encrypted)
3) Once authenticated all traffic is encrypted down the tunnel.
Notes:
o as someone else has just pointed out it's worth checking that the
rules on the firewall allow access to the desired service although
authentication should take place before the rulebase is consulted.
o Check in the firewall log viewer and ensure that the IP address that the
firewall sees is the SecuRemote client and not the proxy's
o Check the log viewer to see if the request is being dropped
Anyway, hope some of this helps.
Neil.
> Let me explain the senario in greater details...
>
> The user has an securemote client pointing the the Checkpoint FW1. With the
> client running, when the user try to access a dedicated server through http
> (http://x.x.x.x), the Checkpoint login prompt will not appear. If the user
> try port 900 (http://x.x.x.x:900) the prompt will appear. However, even
> after authentication, the user could not get any page reply.
>
> As far as I understand, there shouldn't be any NAT between the client and
> the firewall. Most likely, the NAT is done at the firewall itself. One
> possible explaination could be that after the user successfully login to CP,
> the browser request will be forwarding by Squid to the CP. Not aware of the
> presence of Squid, CP will then reply an encrypted http page to the client.
> When Squid see an encrypte reply, it will not understand and forward it back
> to the browser.
>
> Please enlighten me...
>
> Rgds,
> Wei Keong
>
>
>
> ----- Original Message -----
> From: "Neil A. Hillard" <hillardn@whl.co.uk>
> To: "Wei Keong" <chooweikeong@pacific.net.sg>
> Cc: "Squid Users" <squid-users@squid-cache.org>
> Sent: Thursday, May 30, 2002 9:49 PM
> Subject: Re: [squid-users] Checkpoint FW1 & Securemote client
>
>
> > Wei,
> >
> > > We have this user whose Securemote client could not authenticate and
> access
> > > his intranet webpages through Checkpoint FW. We suspect that our
> transparent
> > > proxy might have caused this problem.
> > Not sure that this is entirely on-topic, but here goes anyway...
> >
> > > After some debugging, the user is managed to authenticate by using port
> 900
> > > (http://x.x.x.x:900/). But, he still could not access his intranet
> webpages.
> > > Have you encountered similar problem? Besides removing the user from
> > > transparent proxy, is there anything we can do to resolve this?
> > Can you indicate the layout of the network that the user is connecting
> > over so I can see if your problem is the same as the one I'm experiencing.
> >
> > You don't happen to be using FWZ Client Encryption and the client is also
> > going through some NAT or masquerading device ??? If so that may very
> > well be the cause. Switching to ISAKMP/OAKLEY should help although I'm
> > waiting to have it confirmed.
> >
> > Have a look at www.phoneboy.com for similar problems...
> >
> > HTH,
> >
> >
> > Neil.
> >
> > --
> > Neil Hillard hillardn@whl.co.uk
> > Westland Helicopters Ltd. http://www.whl.co.uk/
> >
> > Disclaimer: This message does not necessarily reflect the
> > views of Westland Helicopters Ltd.
> >
>
>
-- Neil Hillard hillardn@whl.co.uk Westland Helicopters Ltd. http://www.whl.co.uk/ Disclaimer: This message does not necessarily reflect the views of Westland Helicopters Ltd.Received on Thu May 30 2002 - 09:51:42 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:08:16 MST