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

HIgh loads on Astaro

pfilter-reporte is chewing up 100% of cpu for long periods of time resulting in system loads hovering between 1-4. Even as root in console this process won't go away.


This thread was automatically locked due to age.
Parents
  • William,
    are you using any of the p2p monitoring/helpers? I have a feeling, but I can't prove it that they go a little wild every so often. My ASG runs with some sort of load (above normal) for a couple of days, then 90-100% cpu and talks to nothing and nothing is logged.

    Makes it very hard to report problems in this forum and ask for help.

    Ian M
  • I have exactly the same problem with pfilter-reporte which is chewing the 80%-99% of my CPU capacity. I have disabled P2P rules but no improvement.
  • Two people here having that problem so far, neither coming up with machine/network specs or data which would be useful in spotting the possible problem, so how do you expect us to address this issue? From the data I was given I'd assume that your hardware is underpowered, so it might be better to use another product if you want to stick with that hardware.

    Regards,
      andreas


    What an arrogant statement.  The issue is clearly notated inside my post.  The specs of the machine are in my signature.  You know i tried really hard to give astaro the benefit of the doubt after the v5 fiasco but it appears astaro has only continued the downward trend.  Guess what?  I have all of the basic functionality with ipcop, cop+ and copfilter that i would have with astaro.  It's free, it's not a beta masked as a commercial release, and furthermore IT ACTUALLY WORKS RIGHT!  It also doesn't require a p-4 3ghz and a gigabyte of ram to run sufficiently.  You just lost one customer here for good and i will use whatever vineyards i have to make sure nobody else makes the mistake of using such a product backed by such a company as Astaro.

    Good Day.

    p.s. if you delete this post feel free as it's being posted on my blog along with the entire thread
  • Hi andreas,

    i had the same problems on my V7 (i think it was 6.9*) and i saw the same process "pfilter-reporte" eating up all my cpu.

    But, my hardware IS to slow. I use a 1Ghz Esther-Cpu with 512MB Ram. With PPPOE, 5 packet-filter-rules, 2 NAT-rules, 2 site2site-tunnels and only a little traffic.

    With IPS (server-rules disabled), portscan-detection and anti-dos i had exactly the same problems. From time to time my ASG just freezed and was not accessible for about 15 minutes.
  • the astaro machine here is perfectly accessible and works fine...there's just no reason for that process to be nailing the cpu at 100% for 2 weeks.
  • Hi

    Andreas lets get one thing clear, your comments were not helpful, they came out very abrupt and showed Astaro as a company that really does not care a crap about anyone, which I know is not the case.

    The prolem William (Please reconsider staying with Astaro, your help on the forums are much appreciated) and others, including me has been reported since 6.908.  However I do not feel enough data was gathered for you to fix the issue.  IPS has an issue with load, when I say load, I am talking about over 100 concurrent connections within a 1 minute period, eg. Bittorent, Skype, etc.  I run 7.002 on a Shuttle XPC, Celeron D 3.33 Ghz, 1 GB DDR RAM, 40 GB HD. Dlink 10/100 530TX.  When I run a bittorrent client (from bittorent.com).  Even if i just download 1 torrent, Astaro goes nuts, CPU goes to 100% and Webadmin is not responsive.  I have to stop the download to get back into Webadmin.

    The Astaro config i have is 2 basic rules, 1 internal Network Any Any Allow Log and a cleanup, Any Any Any Drop don't log rule.
    IPS Peer to Peer is on, all is set to block except bittorent.  If you turn off IPS and re test, my CPU stays below 10%

    Andreas, please let me know if there are any logs I can give to help sort this issue out that many members look to be having
  • Hi

    Andreas lets get one thing clear, your comments were not helpful, they came out very abrupt and showed Astaro as a company that really does not care a crap about anyone, which I know is not the case.

    The prolem William (Please reconsider staying with Astaro, your help on the forums are much appreciated) and others, including me has been reported since 6.908.  However I do not feel enough data was gathered for you to fix the issue.  IPS has an issue with load, when I say load, I am talking about over 100 concurrent connections within a 1 minute period, eg. Bittorent, Skype, etc.  I run 7.002 on a Shuttle XPC, Celeron D 3.33 Ghz, 1 GB DDR RAM, 40 GB HD. Dlink 10/100 530TX.  When I run a bittorrent client (from bittorent.com).  Even if i just download 1 torrent, Astaro goes nuts, CPU goes to 100% and Webadmin is not responsive.  I have to stop the download to get back into Webadmin.

    The Astaro config i have is 2 basic rules, 1 internal Network Any Any Allow Log and a cleanup, Any Any Any Drop don't log rule.
    IPS Peer to Peer is on, all is set to block except bittorent.  If you turn off IPS and re test, my CPU stays below 10%

    Andreas, please let me know if there are any logs I can give to help sort this issue out that many members look to be having


    I have zero ips functions active and no BT going.  This has been going on for 2 weeks now.  i'm not even using 250 concurrent connections according to the executive report.  I do average 350 packet filter violations daily and i have two rules..allow anything out and block everything else incoming.  I have no forwarding going on other than masquerading.  The last report showed 600 packet filter violations but that doesn't make my ipcop installation go above ZERO load.  With astaro it goes to a load factor of 4??...something's big time wrong here and it's not my machine.
  • This is exactly the information I was asking for right from the start. The pfilter-reporter processes data about blocked/dropped packets, therefore I was asking for the amount of dropped packets  (because you can obviously increase its CPU usage by having a lot of network traffic blocked).

    I missed the information about your machine specs because I disabled signatures and avatars to gain some speed, since I browse these forums a lot. I am sorry if my last posting came out too harsh, looks like I am getting frustrated that I still don't have the slightest idea about the possible reason for this behaviour.

    The IPS is a performance hog, but the pfilter-reporter is not directly connected to the IPS subsystem, therefore I don't think this is the same problem. Let's gather the facts: the machine is powerful enough, the amount of dropped packets is low (350-600 packet filter violations per day is LOW). The reporter also sends notifications, do you have them enabled/disabled/limiting on/off? It also tries hostname resolution, is your DNS server reachable/has a good connection to your ASG?
  • the only reports i have enabled is the executive reports...otherwise i don't have any of them running.  DNS is fine as my ipcop system has no issues and resolution with the asg install works fine as well.
  • Hello Astaro,

    just a few minutes ago my asg just stopped responding again for about 2 minutes. After that short downtime the cpu-usage showed 99% for a while and - what is more important - my ips.log is full of detected portscans from my own client?!

    In my opinion my firewall was always online and working, but IPS dropped all my connections (even my ssh connection to my asg was dropped). The trigger might be a skype-call, i tried to call someone from my client and from this moment on all connections stopped working...

    By the way, IM/P2P-Security is completely disabled. I have no P2P-software running, just skype and browsing through the internet.
  • please can you post some of the IPS logs so we can see.
    To aid Astaro and others help you please give us as much detail on this as possible.
    I see loads of posts on here from users with performance issues, including me, but no logs are posted so we can understand what the system may be doing that could shed light on the cause

    Cheers
  • Hier is a extract from my ips-log from this evening. Port 21544 is the port configured within skype, but i don't use a forwarding-rule to my client (nat).

    log.zip
    log.zip
Reply Children
  • Cheers for the logs..
    Very interesting..  

    It looks like the Astaro box is reporting a portscan from your internal workstation.   I can not see a way to stop that as there is no 'Allowed Networks' section to prevent it from 'seeing' this.
    Andreas if you are reading this, I would say this is a possible bug / feature request.  This is a powerful and needed feature, but I think it needs a way of making it less senseative and to allow exclusions, like an 'Allowed Networks / User / Node' section

    For the time being I would turn this feature off and see what happens

  • It looks like the Astaro box is reporting a portscan from your internal workstation.   I can not see a way to stop that as there is no 'Allowed Networks' section to prevent it from 'seeing' this.
    Andreas if you are reading this, I would say this is a possible bug / feature request.  This is a powerful and needed feature, but I think it needs a way of making it less senseative and to allow exclusions, like an 'Allowed Networks / User / Node' section


    I am reading this. [:)]
    Shouldn't Network Security->Intrusion Protection->Exceptions be exactly what you are searching for? You can disable the portscan detection feature for certain source networks ...

    Cheers,
      andreas
  • But why is my skype-login or skype-call a portscan??? And why is the asg-load rising so high when this 'portscan' is being detected?

    top - 20:17:02 up 6 days, 5 min,  1 user,  load average: 4.02, 1.87, 0.71
    
    Tasks:  92 total,   1 running,  90 sleeping,   0 stopped,   1 zombie
    Cpu(s): 74.5%us,  9.8%sy,  0.0%ni,  0.0%id, 15.7%wa,  0.0%hi,  0.0%si,  0.0%st
    Mem:    499996k total,   456908k used,    43088k free,    70140k buffers
    Swap:  1052248k total,       68k used,  1052180k free,    93908k cached
    Change delay from 1.0 to:
      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    19291 root      16   0 26748 7908 3008 S 15.4  1.6   1:23.61 pfilter-reporte
    11356 root      16   0 38432  22m 1836 D 15.4  4.7   0:00.16 confd.plx
     3176 root      16   0 13332 8432 2496 S  2.9  1.7  52:35.38 selfmonng.plx
    11355 root      15   0 38576  23m 1980 D  2.9  4.7   0:00.20 confd.plx
    19301 root      15   0 12968 8080 2492 S  1.9  1.6   0:03.01 notifier.plx
  • Skype probably opens up a number of outbound connections on different ports rapidly to figure out the best way to connect the call.
  • your right Andreas, sorry missed that one.

    I need more coffee
  • issue is stilll here with 7.005..[:(]
  • How does your IPS Portscan configuration look like?

    The portscandetection works like that:

    For every source ip that traverses the network in keeps track of which ports have been tried to open. 
    If a certain source ip tries to connect to many different destination ports and between two port attemps is less time than 300ms than a counter is incremented. If the counter reaches a certain threshold, than the assumption is that this ip is currently doing a portscan.

    The system triggers alert/drop if somebody tries to open more than 4 different ports per second for at least 6 seconds, than the ip is marked as portscanner.

    now Skype is a pretty agressive application, which easily tries to establish that many connections per second.

    Do you have "limited logging" enabled?
    If not, please do so, as it will lower the amount of log lines generated.

    hope that helps regards
    Gert
  • al ips functions are off.  I have zero packet filter logging. I have portscan detection off, anti flood off, anti ddos off..etc.  anything that uses ips functions is off.
  • it turns out it's part of a DOS vulnerability with the pfilter script:

    http://www.hescominsoon.com/archives/773