Hello Forum, we are rolling out web filtering and I am troubled by websites that are legit and allowed by policy, not connecting. S360, latest released code. One is site www.msn.com. We have done some sniffing around the device. When I go to it and sniff proxy interface of the S360, all we see are unresponded to SYN packets. When I direct connect with browser proxy settings it immediately beings working properly. It has worked properly in recent past. I have made no changes I am really aware of. We use WCCPv2 from a Cisco 6500 to the S360. When snifffing firewall above the 360 we so no traffic from to msn dns resolved addresses. When direct to proxy it is fine. Sometimes it will connect for a brief time, sometimes a timeout, sometimes only some bare text from the site. Accesslogs look normal. Nslookup from s360 varies sometimes. Evict from cache says it is not in. Have added to proxy bypass and custom URL allow list. No diff. Something inside the box is having a problem. We added a bunch of domains from the windows update issue before and are still in. Anyone seen this? Pcaps available.
That's possible. I also noticed that the DNS cache entry changes frequently and only one of three I noticed seem to be there when the page works.
Although we're using an ASA, i have our "redirect list" acl limited to HTTP, HTTPS, FTP, and FTP-data instead of IP.
What do your WCCP ACLs look like?
Core1-r1#sh access-list ironport2
Extended IP access list ironport2
10 deny tcp host 10.247.254.174 any
20 deny tcp any 192.168.0.0 0.0.255.255
30 deny tcp any 10.0.0.0 0.255.255.255
40 deny tcp host 10.230.3.250 any
50 permit tcp 10.139.60.0 0.0.0.255 any (119568304 matches)
60 permit tcp 10.230.32.0 0.0.0.255 any (9290669 matches)
70 permit tcp host 10.230.48.12 any (141403 matches)
80 permit tcp host 10.230.36.62 any (1456 matches)
90 permit tcp host 10.150.18.7 any (741 matches)
10= P1 interface
20= network we don't want to be sent to ironport
30= " "
40= M1 interface
50->90=All testing subnets to go to ironport
Thanks for the feedback! jc
my only suggestion would be to limit your wccp traffic to services you plan to send over. for a test, put your ip (or a test workstation) in the ACL below the deny statements but above the allow statements, but try limiting it to http, https, ftp, and ftp-data and see if msn.com works right?
access-list # permit tcp 10.11.12.4 0.0.0.0 any eq 80
access-list # permit tcp 10.11.12.4 0.0.0.0 any eq 443
access-list # permit tcp 10.11.12.4 0.0.0.0 any eq 20
access-list # permit tcp 10.11.12.4 0.0.0.0 any eq 21
I'm pretty new to using WCCP. I guess my network guys and I assumed WCCP was only interested in those services\ports. But I suppose it's not a WCCP issue but what the protocol is presented with by the ACL. I will see if we can get that done and let you know if it helps. Best regards.
We use what's up gold to check things around the internet. When we began deploying ours, I set up the ACL for ip/any traffic. Pings from what's up gold to things on the internet failed. When I trimmed the ACL back to web services (http, https, ftp, etc) then my pings started working again.
At that point, I left the access filters to the firewall (icmp, etc.) and left the WSA to handle proxying, AUP enforcement, and malware scanning.
Restricting WCCP to those services wouldn't compromise any L4 protections, would it? I have L4 set to look at HTTP\HTTPS, debating, not sure if they are completely separate from WCCP influence.
It shouldn't impact L4 inspection, although it will only check the traffic that passes to/through it.
We set up a span port source on the switch port that's on the inside interface of our firewall and set the span port destination to one of the T1 interfaces of our WSA. That way, anything that's going through our firewall will be checked by the L4 inspector.
Well, we changed the WCCP acl to route http and https, but intermittent MSN connectivity persists. Thanks for the tip regardless. Engineer will be looking in on it today. Thanks jc
We worked with Ironport engineer Raam (did excellent job) and identified a routing loop. Change controlled for Thurs to implement fix. Traffic was running twice by a WCCP interface that was on outbound interface for outbound traffic on core switch. That will definitely help performance. The only question I thought about later was, why would it work at all for most sites and only have an issue with a few. More to come...