Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 41 replies
  • Subscribers 2 subscribers
  • Views 121137 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

Concurrent connections in UTM 9.312

stpfre
Hi,

after updating to the newest UTM Version 9.312-6, we noticed a constante rise of "concurrent connections", which stopped all our traffic last night, when the concurrent connections went up to 256000 and a "nf_conntrack: table full, dropping packet" message in the kernel.
Has anyone experienced the same problem or has an idea how to solve this?

Frank


This thread was automatically locked due to age.
  • 0 in reply to stpfre
    Hi William,
    there is no P2P traffic or other abnormalities visible in the logs.
    We can see this behaviour on 2 independent UTMs after updating to the newest version, so they are probably not compromised, but some kind of bug in the newest software in some constellation.


    Same here, two systems showing the behaviour after 9.312. By the way, maybe this helps, both are virtualized Active-Passive HA-Clusters (doesn't matter if only one system is up).
  • 0 in reply to bulirich_01
    Hi,

    could you please run the following command as root on your UTM:
    rmmod nf_conntrack_dns


    Please have an eye on the concurrent connections afterwards and report back if they are still rising or stay at a certain level.

    Thank you.

    Regards,
    Benjamin


    Sorry, I cannot check this, UTMs doesn't allow me access with SSH anymore?!? [:O]

    Update:

    Local network SSH login "Access Denied" (host is in allowed networks listed), tried via public IP from remote office (this IP also listed in allowed networks) successful! Bug?!

    Executed the command and I see no drop in concurrent connections. If you can tell me the command to check concurrent connections via shell I can check absolute numbers.
  • 0 in reply to HiRN
    Sorry, I cannot check this, UTMs doesn't allow me access with SSH anymore?!? [:O]


    go into the webadmin and enable the shell then set the loginuser and root passwords.  When you log into the shell you have to login as loginuser first then su - and your root password for root.
  • 0 in reply to William Warren
    Observation. My VM UTM seems to suffer quite badly from the growing concurrent connections, where as the three physical UTMs don't.
    The VM version has more devices connected to it. Reviewing history doesn't show an increase similar to what I am currently seeing since 9.312-5.

    Ian M
  • 0 in reply to William Warren
    go into the webadmin and enable the shell then set the loginuser and root passwords.  When you log into the shell you have to login as loginuser first then su - and your root password for root.


    Ahem, haven't done this for the first time [:)] This is all correctly configured, connection via an allowed host on the public IP of the UTM is working. But I don't want to hijack the thread.
  • 0 in reply to RFCat_vk_01
    Observation. My VM UTM seems to suffer quite badly from the growing concurrent connections, where as the three physical UTMs don't.
    The VM version has more devices connected to it. Reviewing history doesn't show an increase similar to what I am currently seeing since 9.312-5.

    Ian M


    Mh, what hypervisor do you use? I'm on ESXi 5.5 (same problem with two UTM VMs). Are the affected UTMs running in HA?
  • 0 in reply to HiRN
    I "solved" the problem by downgrading to 9.310011, so it's definitively a bug in the last versions (9.312005 and 9.312006). I can't say if 9.311003 is affected too.
  • 0
    Do all of you have IPv6 enabled? Does anyone experience this problem without having IPv6 enabled?
  • 0 in reply to bulirich_01
    Answers.
    1/. esxi 5.5u1
    2/. sixxs tunnel on the VM UTM.

    I am running IPv6 native on a physical UTM and not seeing the same amount of growth.

    Ian M
  • 0 in reply to RFCat_vk_01
    We had IPv6 disabled when the problem occured