Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 4 subscribers
  • Views 15055 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

UTM9 not accessible for several minutes - nf_queue: full at 1024 entries, droping packets(s)

Michael Bickel

Today our UTM9 stopped working for several minutes, we were unable to connect via ssh or https. After a while everything worked again. I found this entries in the kernel log for the whole time:

"nf_queue: full at 1024 entries, dropping packets(s)"

What can be the reason for this? How can we avoid a full nf_queue in future?



This thread was automatically locked due to age.
  • 0

    Hi Michael,

    It seems that the Snort process is hanging for a while. What is the rule_age limit set for attack patterns in the UTM for IPS? We may be dealing with heavy traffic here and reducing the rule_age limit can increase performance. Alongside, before changing the rule_age limit, I would recommend you to increase the queue_length to 8192. Execute the following command through shell in the UTM as root.

    cc set ips queue_length 8192 

    cc set ips status 0 

    cc set ips status 1

    After making the changes monitor the situation at your side and let me know if the issue reappears.

    NOTE: If you have a licensed support, I would recommend you to call the support team to make these changes through CC.

    Thank You

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

  • 0 in reply to sachingurung

    Hi,

    thanks for your reply, but we don't have IPS activated. I also searched the logs but can't see anything unusual, even the packetfilter logged several entries during this time.

    Is it possible to change the nf_queue size?

    Michael

  • 0 in reply to Michael Bickel

    Hey Michael.

    Last time I saw that was on a very busy UTM220 handling a lot of traffic. I ended up upgrading to a SG230, as the UTM220 was not able to handle the load anymore. My guess was that when swap usage got too high because of limited memory on the UTM220, hardware would just fail to process new requests, probably because all that swaping was killing disk speed and consequently raising CPU usage to the roof.

    Check your resource usage logs. You might find yourself at the same situation, with high swap usage and CPU usage peaks all over the day. If that's the case, I would suggest upgrading that hardware.

    Regards - Giovani

  • 0 in reply to giomoda

    Hi Giovani,

    yes, that may be a reason. The swap usage was at about 50%, but i didn't see any CPU peaks. Anyway, I rebooted the UTM and will have a look at the resources.

    Regards,
    Michael

Unfiltered HTML