We are using NBAR to match on and subsequently filter certain urls and p2p traffic at a few customer sites. I understand that this is a substandard way to police user traffic in light of other content filtering options and if this proves unreliable then I will definitely look at those other options.
We're matching urls with a very basic class map:
Class Map match-any url_list
Match protocol http host "*youtube*"
Match protocol http host "*myspace*"
Match protocol http host "*facebook*"
Match protocol http host "*video.google*"
This is being applied to inbound traffic on the LAN interface(s) and the traffic is being filtered fine. The issue we are running into is that other html traffic is matching and being filtered as well.
We are also filtering p2p applications with the following class-map:
Class Map match-any p2p_list
Match protocol bittorrent
Match protocol directconnect
Match protocol fasttrack
Match protocol edonkey
Match protocol gnutella
Match protocol winmx
Match protocol kazaa2
Match protocol socks
This is applied ingress on the LAN interface and ingress on the WAN. On one of our sites the ingress LAN application is filtering out POP3 traffic.
I really appreciate everyone's time and help.
Routers used: 3745 with 12.4(15)T7 & 871 with 12.4(20)T1
Marwanshawi, I really do appreciate the advice and will take it under serious consideration. Our issues seem to be solely affecting outbound WAN-bound traffic(i.e. improperly matched url headers and outbound POP3 requests). As I said though, I most certainly will consider making that adjustment.
Now that I have a little time, let me provide more detail. On one site we are using an 871 as a LAN router and filtering websites with the above class-map(please see "url_list" class-map above). This class-map is being nested in a policy that is simply dropping the packets. At other sites we are using ToS marking and filtering in-line with the DiffServ model.
This particular site(871 matching "url_list" & dropping the packets) it seems that packets are being improperly dropped to legitimate websites, but it's random. For instance, a packet attempting to GET the following URL: http://en-us.www.mozilla.com/en-US/firefox/3.0.3/firstrun/ will sometimes be dropped and other times be forwarded. Also, arin.net is another example of this behavior. Again, the only classifying we are using at this site is the "url_list" class-map above.
This is still very much an issue at multiple sites. All routers(3745's and 871's) have the latest Boot Rom and IOS images. All are being tested with the basic "url_list" class-map(please see above). Some have been nested in a policy that is marking unwanted traffic and subsequently filtering, and others are being nested in a policy that is simply dropping the packets. At all sites we seem to be experiencing the same issue; using the "url_list" class-map above, some legitimate http traffic(in addition to the unwanted traffic) is being improperly classified and filtered.
hasmurizal, thank you for taking the time to respond. I have tried packet inspection both ingress on the LAN interfaces as well as egress on the WAN ports. Qos, however, has only ever been configured to use a "drop" policy.
Please let me know if I can provide any more details that would be of use to you, and any suggestions that you might have would be most appreciated.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...