SYN-Flood packets dropped by unknown rule

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SYN-Flood packets dropped by unknown rule

L4 Transporter

Hi everybody,

we got a lot of syn-packets which were dropped  by the rule any-allow. But we haven't this rule, so is it a inbuilt rule and

why do i need a DoS-Rule to be protected against Syn-Floods if there is a builtin rule.

flood.PNG.png

Cheers klaus

1 accepted solution

Accepted Solutions

So it should be a bug.

Maybe restarting some services will solve this but I can't say you'll not see same behaviour then, or not.

Best; I advice an upgrade to 5.0.11

View solution in original post

14 REPLIES 14

L7 Applicator

Hello Sir,

Do you have a DOS protection profile configured on your PAN firewall..? As per my knowledge, PAN is not having such inbuilt rule on it. Could you please expand the session details as mentioned below and update here.

flood.PNG.png

Thanks

L6 Presenter

did you check zone protection ?

if no zone protection or dos protection is used then better to open a case.

L3 Networker


Maybe you have flood protection turned on in a network profile?  That might do it.

Mike

L4 Transporter

Hello kdd,

From the description we see that the inbuilt rule has taken charge. What we will have to look is at the time of issue did we see any DOS or zone protection profile counters triggered.(If they are configured )

This can be seen by " less dp0-log dp-monitor.log" Also we can check the commands to see the triggers for the syn flood

show dos-protection rule <rule name>

show zone-protection zone <zone name>

Example for Dos counters:

How to Implement Resource Protection using a DOS Profile

L4 Transporter

Thx for your comments.

to make it more visible and comprehensible what the zero point is:

- log entry

flood.PNG.png

- DoS rule

DoS-Rule.PNG.png

- DoS protection profil

DoS-protection-profile.PNG.png

- DoS global counters

dos-global-counters.PNG.png

what i understood so far is that there seems to be a inbuilt rule which was taken in advance because the limitation of our own DoS-protection rule isn't as narrow as the default

where can i get information about the settings of the any-allow rule ? it sounds also strange to me to call a rule any-allow and then drop the packets. anywhere,

but there should be a clue to the inbuilt rule

Since it says "Session limit event" and your rule name is different, this is not normal.

What os version you are using ?

L4 Transporter

5.0.5 / PA-5020

I am not sure if this is an unlisted bug but if you have time to upgrade it will be better.

There are some Dos related issues (49337—Traffic was blocked even though the DoS Protection policy was configured to allow it. - but written that fixed with 5.0.5)

Have you ever used "any_allow" name for a rule ? 

L4 Transporter


yes, as we started with new zones there was a "any-allow" rule but not yet

So it should be a bug.

Maybe restarting some services will solve this but I can't say you'll not see same behaviour then, or not.

Best; I advice an upgrade to 5.0.11

L4 Transporter

thx for your assistance unfortunately there is still another problem with this version

L4 Transporter

after upgrade to 5.0.10 this behavior is completely disappeared. Thanks to all for your support

Regards Klaus

kdd if you're running HA you might want to move to 5.0.11 ASAP.... there are some huge HA bugs (dataplane restarts....) in 5.0.10

we wanna upgrade to 5.0.11. it is also an advice of panos but thank you too and is also done fast

  • 1 accepted solution
  • 5356 Views
  • 14 replies
  • 0 Likes
  • 101 Subscriptions
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!