Re: [squid-users] Checkpoint FW1 & Securemote client

Wei,

> > Ward:
> > secureremote creates a tunnel to the firewall .. its more likely that the
> firewall is not allowing him access.
>
> The user is able to use telnet, ftp through Securemote. He should have no
> problem connect to the Checkpoint firewall. Moreover, the reply is not
> 'authentication failed' but 'page cannot display'.
>
> > Bill:
> > I would say to not send your dedicated server HTTP requests through the
> > proxy server. Maybe put the entire encryption domain in your browsers
> bypass
> > proxy list. SecuRemote is using VPN and IPSec to establish a secure route
> > between your computer and the firewall. When you try to put Squid in
> > between, you're breaking that route. SecuRemote is going to 'encapsulate'
> > everything going to an address in the encryption domain, not just HTTP
> > requests. We use telnet, ftp,x-windows,Windows Terminal Server over VPN
> > SecuRemote clients.
>
> The problem is the transparent proxy will 'hijack' all port 80 traffic and
> redirect to the Squid box. Seems that with TP will not work in this case...
No... As you have a transparent proxy the browser does not know that it's
there and therefore will send packets destined for the destination as per
normal. SecuRemote will spot these, hijack them and send them down the
encrypted tunnel.

> > Neil:
> > In theory, if it's going through a proxy the firewall will see the address
> > of the proxy, not that of the client.
>
> If the authentication packet is sent through port 80, it will be hijacked by
> Squid. The firewall will see the Squid IP and assume that the Squid box
> trying to authenticate.
The web browser will believe that it is sending to port 80 but the packet
that has been hijacked by SecuRemote will be sent down the encrypted
tunnel.

Authentication for SecuRemote takes place after the encrypted tunnel has
been set up on UDP port 259 if using FWZ or UDP port 500 if using
ISAKMP/OAKLEY.

> If the authentication packet is not sent through port 80, it will no be
> hijacked by Squid. The firewall will be able to authenticate the user.
> However, the http request from the browser will be encrypted and Squid will
> not be able to understand the request... am i right?
Correct, it's not port 80 (unless someones done something silly to your
firewall. After authentication all communication is then encrypted down
the tunnel on the above ports, not the original ones therefore squid
should not be seeing the requests at all.

Have you checked the firewall logs ???

> > Neil:
> > Switching to ISAKMP/OAKLEY should help although I'm
> > waiting to have it confirmed.
>
> Will this work? how to enable this?
In theory... If something is doing NATing in the way FWZ cannot be used
but ISAKMP/OAKLEY can be. For details see:

http://www.phoneboy.com/faq/0141.html

I am still waiting to have this confirmed by our supplier.

                        Neil.

> ----- 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 11:11 PM
> Subject: Re: [squid-users] Checkpoint FW1 & Securemote client
>
>
> > 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.
> >
> >
> >
> >
> >
>
>

-- 
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.