Thanks for all your help yesterday... tracked it down to a router config issue. Basically, the squid had a different ACL on it than the workstation, so when the browser was connected to the squid, all the TCP traffic was being sent to the squid and being dealt with there, where it was allowed to get through. With transparent caching, only port 80 was being forwarded, so the other ports were subject to the non-squid ACL, and the traffic was being denied. Sean > >> > >>Using WCCP... applicable router config lines: > >> > >>ip wccp version 1 > >>ip wccp web-cache redirect-list 199 > >> > >>access-list 199 permit tcp any any eq www > >>access-list 199 permit tcp any any eq 8080 > >> > >>interface FastEthernet3/1 > >> description connected to EthernetLAN_2 > >> ip wccp web-cache redirect out > >> > >>So it seems like maybe SSL/HTTPS traffic isn't being > >>forwarded to the squid at all? > > > >That is good. Check your firewall logs for traffic from the > client and > > >/ or to the web server in question. Look for dport 443 to > see if that > >traffic is going out the firewall (i.e. not going thru Squid). > > > > Okay.... looked into the fw logs. No traffic on dport 443... > but I did find traffic, which seems to be addressed to the > webmail site being dropped by iptables: Sep 14 13:42:21 fw1 > kernel: [IPTABLES DROP] : IN=eth1 OUT=eth0 SRC=[my > workstation] DST=[webmail host] LEN=60 TOS=0x00 PREC=0x00 > TTL=63 ID=62112 DF PROTO=TCP SPT=38972 DPT=2095 WINDOW=5840 > RES=0x00 SYN URGP=0 > > So this seems to suggest that the issue relates to the fw > configuration? Why would connecting to a squid vs. > transparent caching make a difference here? The dport is 2095, but WCCP is not redirecting that port. Add to your accessl-list 199 permit tcp any any eq 2095 First you might want to see if Squid is configured to proxy tcp/2095. Check your Safe_ports acl or manually configure your web browser to use the proxy. > >
