Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

IOS-XE ZBFW logging lots of dropped packets (erroneously?)

I've got an ISR4431 running "Cisco IOS XE Software, Version 03.16.01a.S" at a remote office. IPSec over GRE tunnels for corporate traffic, regular ISP off a gigabit interface for all Internet traffic.

We've got a simple ZBFW setup with:

Policy Map type inspect Trusted_to_Outside
Class FW-in-to-out
Class class-default
Drop log

And Class FW-in-to-out is just:

 Class Map type inspect match-any FW-in-to-out (id 1)
Match protocol tcp
Match protocol udp
Match protocol icmp
Match protocol h323
Match protocol ftp

The Outside_to_Trusted zone-pair just allows our GRE traffic from corporate, and deny log the rest. But with the outbound being inspected, that allows the return, established TCP traffic to come back through, without specific rules for it in the Outside_to_Trusted rule set.

Our logging buffer is completely filled with tcp pkt drops that appear to be return HTTP(S) traffic (source port 80 and 443 from the Internet):

0000381951172484032 %FW-6-LOG_SUMMARY: 1 tcp packet was dropped from GigabitEthernet0/0/1 => (target:class)-(Outside->Trusted:class-default)
.Jun  9 2016 13:33:23.876 EST: %IOSXE-6-PLATFORM:cpp_cp: QFP:0.0 Thread:003 TS:00000381981172577392 %FW-6-LOG_SUMMARY: 5 tcp packets were dropped from GigabitEthernet0/0/1 => (target:class)-(Outside->Trusted:class-default)

Now, we're not getting any complaints regarding web browsing from this office, so it's safe to say that return HTTP(S) traffic is not getting blocked.

Seems to me, there's two explanations of what's going on here.

  • Even though the ZBFW is allowing the established traffic back through, it's somehow hitting the Deny log statement, creating log entiries (bug?)
  • There's some kind of ongoing established-tcp-spoofing attack happening (unlikely)

Is anyone else seeing anything like this?

VIP Purple

I think I would try upgrading

I think I would try upgrading to the gold star release 3.16.2S and see if the issue still happens.

New Member

Heh, I was afraid that might

Heh, I was afraid that might be the answer. I was hoping to hear if anyone else has this issue. I'll see what we can do about a maintenance upgrade.