Odd MSN traffic behavior

Unanswered Question
Feb 5th, 2010
User Badges:

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
nadamsgreektown Mon, 02/08/2010 - 17:32
User Badges:

if bypassing the proxy works and using the proxy directly works, i wonder if something's wonky with your wccp configuration?

john.cunningham Tue, 02/09/2010 - 05:46
User Badges:

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.

nadamsgreektown Tue, 02/09/2010 - 19:06
User Badges:

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?

john.cunningham Wed, 02/10/2010 - 05:51
User Badges:

Like this;

Core1-r1#sh access-list ironport2
Extended IP access list ironport2
    10 deny tcp host any
    20 deny tcp any
    30 deny tcp any
    40 deny tcp host any
    50 permit tcp any (119568304 matches)
    60 permit tcp any (9290669 matches)
    70 permit tcp host any (141403 matches)
    80 permit tcp host any (1456 matches)
    90 permit tcp host 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

nadamsgreektown Wed, 02/10/2010 - 14:26
User Badges:

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 any eq 80

access-list # permit tcp any eq 443

access-list # permit tcp any eq 20

access-list # permit tcp any eq 21

john.cunningham Wed, 02/10/2010 - 15:51
User Badges:

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.

nadamsgreektown Thu, 02/11/2010 - 08:01
User Badges:

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.

john.cunningham Thu, 02/11/2010 - 11:03
User Badges:

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.

nadamsgreektown Thu, 02/11/2010 - 13:36
User Badges:

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.

john.cunningham Mon, 02/15/2010 - 07:52
User Badges:

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

john.cunningham Wed, 02/17/2010 - 10:08
User Badges:

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


This Discussion