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

Is this normal for 300 users,

ibeheer
This is in a report for one day, I wonder is this amount normal or quiet a lot?
If total connections is above 1200 it's impossible to open webmail......
everyting else works ssl vpn,normail ipsec vpn, surfing.....
Very strange..... a reboot doesn't help. Changing mtu to 1400 everything works again????? And problem is gone again. The thing is i don't know how are what is causing the problem. Normal traffice for a week is about 80gb. Didn't have a lot of problems except strange problems and to go away also. The updates drive me crazy.


This thread was automatically locked due to age.
Parents Reply
  • 0 in reply to ibeheer
    What is the cpu spec?  Also can you give a screenshot of the main system panel when it's acting up?  

    also log into the shell as loginuser and run top.  hit the 1 key to show all the cpus and then take a screenshot of that as well.
Children
  • 0 in reply to William Warren
    Thanks for your response william. A top takes longer.... ssh is not enabled.
    Screenshot webinterface no problem. Is it much traffic are just normal?
  • 0 in reply to ibeheer
    your paketfilter drops 103.358 Packets.
    What is the reason for this high value ?


    Gregor Kemter
  • 0 in reply to gkemter
    2008:03:28-(none) ulogd[2880]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="2" initf="eth1" dstmac="" srcmac="" srcip="" dstip="" proto="17" length="78" tos="0x00" prec="0x00" ttl="64" srcport="137" dstport="137" 
    2008:03:28-13:10:12 (none) ulogd[2880]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="3" initf="eth1" dstmac="" srcmac="" srcip="172.16.0.40" dstip="" proto="17" length="229" tos="0x00" prec="0x00" ttl="128" srcport="138" dstport="138" 

    Idea is to drop most traffic so traffic for 137/138 is high so created a rule in top 2/3 to drop the traffic. Hoping the firewall will not process the traffic any further.
  • 0 in reply to ibeheer
    137/138 comes from internal lan, but this dont need to go "outside".
  • 0 in reply to gkemter
    could you post your packet filter rules?  I bet there's something there that might be causing this.
  • 0 in reply to William Warren
    If your 137/138 count is so high try not logging those dropped packets from that PF rule that will reduce the load considerably.

    Ian M
  • 0 in reply to RFCat_vk_01
    137/138 is the internal network and needs to stay internal. 

    Rule 1 is: 
    Some servers may go everyway.
    Rule 2:
    drop internal 137
    Rule 3:
    drop internal 138
    Rule 4:
    Blacklist (consist of ipnumbers who may never enter)
    Rule 5:
    mail server to smtp mailserver group.
    one mail server conects to 3 other mailservers outside
    Rule 6:
    Internal to a private site
    Rule 7:
    SSL VPN to terminal server
    Rule 8:
    SSL VPN to internal DNS server
    Rule 9:
    SSL VPN based on user (we self) may go everywhere internal
    Rule 10:
    Internal dns server to outside dns servergroup consist of four external dns servers.

    Also we see 255.255.255.255 Which can't we can drop except the dault rule (default drop)does. We have 35 rules so that means the firewall hold the against 35 rules...
    I want do drop that traffic sooner. By not logging does not mean the packetfilter isn't processing the traffic i hope. And we have beamers on the network that need to stay inside but is generating 3.255:5001 Traffic.
    Also i can't stop that. If more beamers are on the firewall is still processing it.
    Even if the beamers don't have the firewall as gateway??????

    We have 2 internet lines
    1 internal line
    1 administrative interface where in the future we do all the changes.

    ps. disk space for log no problem plenty off it
         cpu see clipboard10
  • 0 in reply to ibeheer
    137/138 is the internal network and needs to stay internal. 

    Rule 1 is: 
    Some servers may go everyway.
    Rule 2:
    drop internal 137
    Rule 3:
    drop internal 138
    Rule 4:
    Blacklist (consist of ipnumbers who may never enter)
    Rule 5:
    mail server to smtp mailserver group.
    one mail server conects to 3 other mailservers outside
    Rule 6:
    Internal to a private site
    Rule 7:
    SSL VPN to terminal server
    Rule 8:
    SSL VPN to internal DNS server
    Rule 9:
    SSL VPN based on user (we self) may go everywhere internal
    Rule 10:
    Internal dns server to outside dns servergroup consist of four external dns servers.

    Also we see 255.255.255.255 Which can't we can drop except the dault rule (default drop)does. We have 35 rules so that means the firewall hold the against 35 rules...
    I want do drop that traffic sooner. By not logging does not mean the packetfilter isn't processing the traffic i hope. And we have beamers on the network that need to stay inside but is generating 3.255:5001 Traffic.
    Also i can't stop that. If more beamers are on the firewall is still processing it.
    Even if the beamers don't have the firewall as gateway??????

    We have 2 internet lines
    1 internal line
    1 administrative interface where in the future we do all the changes.

    ps. disk space for log no problem plenty off it
         cpu see clipboard10

    pffilter is the huge load there i bet.  turn off the logging of droped rules in the packt filter.  the 137/138 are going to generate a colossal amount of drops and a equal amount of log entries.  In that 137/138(need to drop 445 as well) activate the option to not log the drops.  Wait a day or two for hte processing to catch up and see if that helps things.
  • 0 in reply to William Warren
    Thanks for your response william. I have done what you have suggested...
    I see know also other drops.... Lower count value. But traffic is still high about 12GB a day. Also contact framework filter restarts some times.... is there a way for the astaro to drop by ip adress...... because the printer traffic etc can be left alone...
  • 0 in reply to ibeheer
    Thanks for your response william. I have done what you have suggested...
    I see know also other drops.... Lower count value. But traffic is still high about 12GB a day. Also contact framework filter restarts some times.... is there a way for the astaro to drop by ip adress...... because the printer traffic etc can be left alone...


    Yes just define the ip address in the definitions section then you can drop the traffic w/o logging in the packet filter..[:)]