Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 3 subscribers
  • Views 2744 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

Memory Leak in UTM 9.306-6

OpsMonkey2000
Hi all,

I recently had a situation where all L2L VPN tunnels on the UTM went down and stayed offline despite the device appearing responsive.  I corrected the issue by simply toggling each tunnel on/off.  On examination of the logs, I found that the system had run out of memory and many services were killed and restarted.  At this time, many processes were restarted but for purposes of this post the important ones were dhclient and pluto.  It looks like the VPN subsystem came back online before dhclient was able to get an IP for the interface.  As a result the vpn subsystem failed to come online with a line like the following recorded for each tunnel:

2015:04:10-04:57:15 Prod-RAVPN01 pluto[17384]: "S_REF_removed_0": we have no ipsecN interface for either end of this connection

2 seconds after this message dhclient got its IP, but no retry occurred.  Manual fix was to toggle each tunnel on/off and all was happy.

So two issues:
- It would be great if that race condition could be solved.  My understanding is that this is a known issue.

- More important, it seems to me that a memory leak is what caused the crash.  The attachment seems like strong proof of a leak.  This device provides RA and L2L VPN services and basic NAT/firewall type functionality.  We don't use Web, Email, Endpoint, Wireless, or Web Protection features at all.

Not sure if it matters but this instance is an AWS virtual appliance version of the UTM.  I looked at the up2date patches pending and none of the bugfixes seem related to a memory leak.  I can probably find out what process is leaking once some time goes by, but not sure what if anything I can do to fix it aside from restarting whatever process is leaking.


This thread was automatically locked due to age.
  • 0
    This is a user-to-user forum and not monitored by Sophos.  If you have a paid license, open up a support case to make Sophos aware of the issue.

    How much memory is allocated to this instance?  The bare minimum recommended for the newest versions is 2GB.
  • 0
    The system has 3.75G of memory.  I took a look this morning and it seems that the memory usage over the last 24 hours since my crash is slowly ramping up at about the same rate that it had prior to the crash.  I'm going to observe the system over the next couple days to see if I can figure out what process is consuming the extra memory.  At a minimum I might be able to work around things by disabling the process if its for some functionality I don't use.

    I'm curious does anyone else see this type of pattern in their memory usage graph in either version 9.306-6 or any other version?  Although the 3 outstanding patches don't mention any memory related fixes, I'm curious to see if anyone else sees similar behavior in any other versions.  I am intending to apply the 3 patches during an upcoming maintenance window, so I'll comment back on this thread if those fix it.

    Does Sophos have any mechanism for the community to report possible bugs?  I have no support contract with them, and I'm not looking for free support.  But if its a bug I figure they probably want to know about it.
  • 0
    Does Sophos have any mechanism for the community to report possible bugs?
    No they don't, except during active betas.  Home license users cannot contact support, which is the main mechanism for reporting and prioritization of bugs in release versions. 

    You mention a maintenance window, which would be highly unusual and a bit confusing for a home user.  Is this an Essentials install?  If you have a paid license, you would have standard support.  With this, you can report the bug to your reseller, who can then open a support case with Sophos.

    3.75GB?  That's an odd number.  I'm wondering if you installed as 32 bit instead of 64.  That could potentially cause issues with 4 GB of memory, due to highly inefficient memory usage.  

    While there have been major memory leak issues in the past, mostly with the Web Proxy, I haven't seen any manifest in quite some time.
  • 0
    Its 64-bit running on 64bit virtual hardware.  The specific product is this:

    https://aws.amazon.com/marketplace/pp/B00DJDRZB2

    Its running on an m3.medium which is 3.75GiB  Presumably the hardware is fully supported since Sophos is the one publishing the AMI and allowing it to run on specific instance sizes (that's how the AWS marketplace works).

    I'll follow-up on this thread if I figure out what process is causing the issue.  And maybe I can convince Sophos to take my call.  I don't have a support contract but I am paying them $250/month to run the AMI.
  • 0
    maybe I can convince Sophos to take my call. I don't have a support contract but I am paying them $250/month to run the AMI
    The information at Management > Licensing > Overview in WebAdmin should let you know where you stand support wise.  It should say something like software install type with standard support.
  • 0
    I like how they make "web support" sound like its support.  Folks on this board should ask them for a cut of the action.  At any rate, Scott, I appreciate you looking at my post.  If I find anything concrete I'll post back to help out the community.
  • 0
    Sounds good.  Might help you with your diagnosis to take a look at Support > Advanced > Process List.  Look forward to hearing back.
  • 0
    Looks like the issue is ulogd.  Over the last 24 hours its usage has increased substantially while other processes seem to be staying generally the same.  I did a little digging and found this:

    Sophos UTM v 9, Known issues

    ID34315 9.209 Ulogd is filling up the swap memory
    ------------------------------------------------------------------------
    Description:
    Workaround:
    Fixed in:     9.310

    So it looks like maybe this is fixed in 9.310.

    One question though, in my "up2date" panel the most recent version I see listed is 9.309-3.  On the ftp site I see 9.310 but I was wondering why it doesn't show up in the up2date?
  • 0
    9.310 hasn't been released to the up2date servers (different from the FTP) yet or they are doing a staged release by appliance model or geographic location.
  • 0
    the upgrade to 9.310-11 seems to have fixed the issue.  Memory usage of ulogd is now basically flat for the last 24 hours, and the overall memory usage of the device no longer shows the steady increase in usage that was apparent prior to the patch.  Hope this helps anyone else that sees this.