RE: [squid-users] Transparent proxy problem with MSN Messenger

 
>
> Hello everybody,
> Can any body help me to solve my problem . Recently I
> configured Squid as
> transparent proxy as I was having hard time in configuring each user
> browser with proxy setting in my N/W. Everything with my new
> transparent
> proxy works fine execpt "MSN Messenger" . my users are NOT
> able to login in
> to MSN Messenger with my new transparent proxy setup. I
> tried several
> method to fix it but could not succeed yet also none of the
> port used by MSN
> is blocked. If I try to configure(which I DON't want) my
> user browser with
> IP address of same proxy server in their proxy setting I am
> ABLE to login
> in MSN Messenger with out any problem.
>
> Anything addition to the normal tranparent proxy
> configuration needed for
> MSN Messenger to work.?
>
> Appreciate any suggestion or advise .
>
 
 Many times it has been stated that most of the time
people will be on their own if such problems occur
with intercepting proxy solutions, just because of some
basic networking violations and problems it inheritly has;
here's on overview :
 
 
  - Intercepting HTTP breaks TCP/IP standards because user agents
think they are talking directly to the origin server.
  - Most if not all router based interception methods (route maps,
WCCP etc) causes servere problems for Path-MTU discovery between the proxy
and the clients.
   - On older IE versions ; "reload" did not
work as expected.
   - You can't use proxy authentication
   - You can't use IDENT lookups
   - Intercepting proxies are incompatible with IP filtering designed
to prevent address spoofing.
   - Clients are still expected to have full Internet DNS resolving
capabilities , when in certain Intranet/Firewalling setups , this
is not always wanted.
   - Related to above : because of transp. proxy setup : squid can sometimes
be forced to accept connections to existing sites , with DNS entries
but a webserver which is down. This can further confuse client browsers.

   - Perhaps related to your setup : depending on how the
actual perimeter setup is you may run into problems if remote apps (websites),
check whether subsequent http -> https steps in a logon process don't come
from the same origin (ip address), for instance.
A transp. proxy may break such a check. If the https connection is (again)
coming from the browser.
This problem needn't be there if at the foremost side of the perimeter
some global natting is done, but it very well can be an issue.

 M.

 
Received on Thu Mar 24 2005 - 05:08:33 MST