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