cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2962
Views
0
Helpful
5
Replies

ZBF sometimes blocking websites

TCC Service
Level 1
Level 1

Hi,

My ZBF configuration on a Cisco 3825 is sometimes blocking websites, but not always. Lets say users browse to Linkedin.com, they click around on the website, accessing several pages and then suddenly they get the IE error saying that the website is unavailable. This is what appears in my ZBF log:

028454: May 25 07:49:48.360 CET: %FW-6-DROP_PKT: Dropping tcp session 64.74.98.80:80 INSIDEIP:49748 on zone-pair OUTSIDE_INSIDE_ZP class class-default due to  DROP action found in policy-map with ip ident 0

028455: May 25 07:50:22.553 CET: %FW-6-LOG_SUMMARY: 5 packets were dropped from 64.74.98.80:80 => INSIDEIP:49748 (target:class)-(OUTSIDE_INSIDE_ZP:class-default)

028456: May 25 07:50:43.677 CET: %FW-6-DROP_PKT: Dropping tcp session 64.74.98.80:80 INSIDEIP:49750 on zone-pair OUTSIDE_INSIDE_ZP class class-default due to  DROP action found in policy-map with ip ident 0

028457: May 25 07:51:21.214 CET: %FW-6-DROP_PKT: Dropping tcp session 64.74.98.80:80 INSIDEIP:49754 on zone-pair OUTSIDE_INSIDE_ZP class class-default due to  DROP action found in policy-map with ip ident 0

028458: May 25 07:51:22.554 CET: %FW-6-LOG_SUMMARY: 3 packets were dropped from 64.74.98.80:80 => INSIDEIP:49750 (target:class)-(OUTSIDE_INSIDE_ZP:class-default)

028459: May 25 07:51:22.554 CET: %FW-6-LOG_SUMMARY: 4 packets were dropped from 64.74.98.80:80 => INSIDEIP:49754 (target:class)-(OUTSIDE_INSIDE_ZP:class-default)

The packets are being dropped on the OUTSIDE -> INSIDE policy because for some reason they have not been inspected by the INSIDE -> OUTSIDE policy.

This is my ZBF config:

policy-map type inspect INSIDE_OUTSIDE_PM
class type inspect P2P_CM
  drop
class type inspect HTTP_URLFILTER_CM
  inspect
  service-policy urlfilter WEBSENSE_PM
class type inspect COMMON_PROTOCOLS_CM
  inspect
class type inspect TCP_UDP_ICMP_CM
  inspect
class class-default
  drop log

class-map type inspect match-all HTTP_URLFILTER_CM
match protocol http
match access-group name HTTP_URLFILTER_ACL

ip access-list extended HTTP_URLFILTER_ACL
permit ip any any

policy-map type inspect urlfilter WEBSENSE_PM
parameter type urlfpolicy websense WEBSENSE_SERVER_PARMAP
class type urlfilter websense WEBSENSE_CM
  server-specified-action

Can anyone tell me why this happens sometimes? It happend also before implementing Websense so I dont think that thats the problem.

Thanks!

5 Replies 5

m.kafka
Level 4
Level 4

The dropped packets are hitting the class-map default of the OUTSIDE_INSIDE_ZP which means they cannot be mapped to sessions which were established through the policy map of the INSIDE_OUTSIDE_ZP.

Do you have any other security devices like IDS/IPS that either might drop packets or send tcp-resets?

Try

show policy-map type inspect zone-pair [zone-pair-name] [sessions] to verify that the inspection might have dropped the session.

Hi,

I seem to be having the same problem on my 1941W.

The odd site here and there is dropped, refresh the page returns to normal for a few more clicks.

I can see incoming http packets being dropped by the OUTSIDE to INSIDE zone but can narrow it down to why this is happening.

Could this be a Dialer MTU or some timeout issue?

Thanks

ben.williams@dhi.co.uk

Hi,

I seem to be having the same problem on my 1941W.

The odd site here and there is dropped, refresh the page returns to normal for a few more clicks.

I can see incoming http packets being dropped by the OUTSIDE to INSIDE zone but can narrow it down to why this is happening.

Could this be a Dialer MTU or some timeout issue?

Thanks

Hi Ben,

Do you have any reproducible situation? Everything else is just guessing.

It *could* be a tcp-timeout if the application (browser) is not sending data, while users are reading a page.

This happens, when the browser is using  single-connect, sending multiple requests through the same session instead of opening a new tcp for each page element resp. request. This is the deafult behaviour for modern browsers.

If possible, make a packet dump from the browser session and compare how it behaves. If you have good timestamps you can even correlate with the IOS debug messages.

At least that would be my approach.

Rgds, MiKa

It seems to be something to do with the Trend Content Filter poicy thats added to the IN to OUT zone pair.

As a test recionfigured the router from the begining, all working fine until I added the content filter policy.

Web sites start to droping at incomming packets for no reason as the sites are no part of the content filter policy.

Have logged a support call with Cisco who seem abit stumped on the matter, could be a Bug in the IOS.

Updated the IOS to c1900-universalk9-mz.SPA.150-1.M4 from .M1 seems to be working ok just very slow

Review Cisco Networking for a $25 gift card