RE: [squid-users] Problems with sites that use sessions

> On Wed, Aug 24, 2005 at 10:50:41AM +1000, Nick Bryant wrote:
> > I'm having a few issues with sites that use sessions going through our
> squid
> > (2.5.STABLE3).
> >
> > Basically all works well until a session gets set and then the site will
> > come up with a "Your Session has timed out" type message, irrelevant
> from
> > the type of site being used. It doesn't always happen but I'd say it's
> more
> > often than not. However, un-setting the proxy in the browser seems to
> > resolve the issue every time. For an example that doesn't require a
> login,
> > check out www.lastminute.com.au
> >
> > Has anyone experienced anything similar? Can anyone give me any clues as
> to
> > what I can look at in the config?
>
> I assume that by "session" you think of cookies. This may become a
> problem if you have several proxies that are talked to in a round-robin
> fashion. Then the request with the same cookie information appears to be
> coming from different IPs - from the web server's point of view.
>
> So if you have some kind of load balancing you should make sure it's set
> to "sticky". Which means: a certain client IP is redirected to the same
> proxy time and again.
>

Christoph, turns out I was wrong and you are actually a genius. I'll
explain...

The gateway for our LAN has three paths to the internet, each of which it
runs NAT on with a different global IP address. I then use a "per
destination" load balancing algorithm to decide which link to use. It bases
the path selection on a hash of the source/destination addresses thus
ensuring that each "conversation" will use the same path to avoid any issues
with things like... sessions actually.

So I went back and looked at the sites that have issues with sessions...
they all have something else in common which I hadn't looked at before -
HTTPS.

Now as the squid does tunnelling for https sessions it means the source
address of the packets are the original requesting host... however when
going HTTP these packets get sourced from the squid as it acts as a true
proxy. You can probably see where I'm going with this...

So this means that at the point of using the HTTPS connection the source
address to the web server on the intarweb will probably change (66% chance
with 3 paths). This could be what's confusing the server at the other
end....

Question is; how the hell do I get around that one! Presumably there is no
way to make the squid proxy for HTTPS in which case unless I cut the squid
out, address will always change.

Any suggestions more than welcome.

N
Received on Wed Aug 24 2005 - 12:05:19 MDT