Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 17 replies
  • Subscribers 4 subscribers
  • Views 24117 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 - what happens when you hit the limit

rav3ndk
Hi all,

I have recently upgraded my Astaro 6.311 to 7.009 and I can see that there is a major reduction on the allowed concurrent connections from 32000 to 1000.

Does anyone knows what happens when you hit the concurrent connections limit ? Will the traffic then just be queued which then for example could result in high ping times / lag when I am gaming ?

Kind regards,
Lars-Heine


This thread was automatically locked due to age.
Parents
  • 0
    You must be using a home license...

    After you hit the connection limit, new connections are refused until the old ones time out / go away.  Most home users (and indeed, small businesses I service as well) never get near the limit... I have heard those folks using file sharing programs do sometimes, however.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

    --------------------------------------

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to BrucekConvergent
    Thanks for your answer BrucekConvergent. I'm already returning to Astaro 6.311 as the 1000 is not enough for me apparantly.

    I have tried to run on 7.009 with the 1000 but I am over the limit often, so that's no good. What a bugger - I really really really like the anti-spam in v7 as it filters most of the spam for my domain.

    Thanks,
    Lars-Heine
  • 0 in reply to rav3ndk
    The equivalent commercial license, a 10 User ASL license, ups the concurrent connections to 32,000 connections... I feel safe in assuming this is to keep people from using a free home license for commercial purposes (which I have caught some customers trying to do with other products before).

    Unfortunately, I think many peer to peer services (like BitTorrent, etc.) trigger many inbound connection attempts, using up the 1000 connection limit pretty fast... I'm not sure what could be changed to improve the situation, without Astaro running the risk of having some users violating their home license user agreements by using their system for business or commercial purposes.  Just regular web surfing, email traffic, IM, etc. that home users normally use on a day to day basis shouldn't exceed a 1000 connection limit... however, hosting a web site, etc. could.  I know I really don't go over 100 with 2 people on at home.. and have several customers with 50 employees that never go above 300 or so at a time... but we block Peer to Peer networks etc. as a matter of good business practice.

    As far as the connection timeout period (for "abandoned" connections), I'm really not sure what that timeout would be.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

    --------------------------------------

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to BrucekConvergent
    I can't imagine how 1000 connections isn't enough for home use. If the high connection count is caused by P2P apps, perhaps those connection limits need to be significantly reduced. Here are some peak connection counts for some of our production firewalls:

    1. A handful of lightly used web servers, mail servers, a dozen users (including a bittorrent client). Max 1.25k connections over the past day. Biggest peak is 3.15k.
    2. Medium load web site peaks at 15k connections.
    3. Light load web site peaks at 4k connections.
    4. Light web site, mail server and 150 users peaks around 25k (likely when some P2P apps were being used).

    I imagine that upping the limit to 1500-2000 connections would keep most P2P situations happy for home users as long as they configure them properly to keep the number of connections down.
  • 0 in reply to drees
    My experience with all sorts of different customer sites concurs with dree's personal experience...

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

    --------------------------------------

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to drees
    I imagine that upping the limit to 1500-2000 connections would keep most P2P situations happy for home users as long as they configure them properly to keep the number of connections down.


    Over 30 hours ago, I lowered Azureus' "Max Connections Globally" setting to 150, and eMule has "Max Connections" set to 200.

    Windows netstat -an currently shows 161 connections.
    (This is 1/2 of what it was on Thursday before I lowered those settings.)

    However, Astaro (7.009) currently shows "1.25K" current connections in the network graph.
    Lowering the clients settings doesn't seem to have made any difference.

    fwiw:

    Windows:
    C:\Documents and Settings\barry>netstat -an|wc -l
        162

    Astaro:
    loginuser@fw:/home/login > sudo wc -l /proc/net/ip_conntrack
    1076 /proc/net/ip_conntrack

    Quite a significant difference, no?

    The windows machine is the only PC currently turned on, and the only other PC's only are used for surfing, no P2P, and haven't been on for at least 6 hours.

    Glancing at /proc/net/ip_conntrack, it looks like some remote P2P clients are port-hopping or something... one of them is listed as having 336 connections!
    Windows shows 0 for that same IP, so apparently they were already closed or timed out.

    I guess I'm going to have to dig into the IPTables docs to see what & where the timeouts are on these things.

    Barry
  • 0 in reply to BarryG
    http://www.kalamazoolinux.org/presentations/20010417/conntrack.html
    This is old but it looks like the TCP timeouts haven't changed much.

    On Astaro 7.009:
    loginuser@fw:/home/login > find /proc/sys/net/ipv4/netfilter -name 'ip_conntrack_tcp_timeout*' -print -exec cat {} \;
    /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_max_retrans
    300
    /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close
    10
    /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
    120
    /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_last_ack
    30
    /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
    60
    /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
    120
    /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
    432000
    /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_recv
    60
    /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent
    120


    432000 seconds is 5 days... me thinks that is excessive.

    Many programs are sloppy about closing TCP connections, which explains all of the 'ESTABLISHED' connections hanging around.

    I tried tweaking some of these values, but it doesn't seem to be making any difference.

    Barry
Reply
  • 0 in reply to BarryG
    http://www.kalamazoolinux.org/presentations/20010417/conntrack.html
    This is old but it looks like the TCP timeouts haven't changed much.

    On Astaro 7.009:
    loginuser@fw:/home/login > find /proc/sys/net/ipv4/netfilter -name 'ip_conntrack_tcp_timeout*' -print -exec cat {} \;
    /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_max_retrans
    300
    /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close
    10
    /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
    120
    /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_last_ack
    30
    /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
    60
    /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
    120
    /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
    432000
    /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_recv
    60
    /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent
    120


    432000 seconds is 5 days... me thinks that is excessive.

    Many programs are sloppy about closing TCP connections, which explains all of the 'ESTABLISHED' connections hanging around.

    I tried tweaking some of these values, but it doesn't seem to be making any difference.

    Barry
Children
  • 0 in reply to BarryG
    Well, I'm not 100% sure on how these current peer to peer programs work, but if it's the kind of client that accepts connections from other peer systems:  While you can certainly limit the total number of connections in the client app, you don't really have a way to control how many clients attempt a connection -- if you are at the client-enforced limit, new attempts are simply rejected until one is freed up... the Astaro (or any other firewall) doesn't know how many connections you are limiting complete connections to, so the attempts pile up.  I do agree that 5 days is a fairly excessive timeout for connections that have no activity... but they may have that limit set that high for services that don't have  a heartbeat of sorts, but that you want the connection to remain up, even if there's no traffic for days.  I recall an issue we had with some Sonicwall installs with Citrix clients some years ago, clients kept getting disconnected every 10 minutes or so... found that the default idle connection timeout for all TCP sessions was set to 5 minutes.  Fortunately, we were able to add a rule that upped the timeout for traffic on port 1494 (the Citrix ICA protocol) to 3 hours or so, that way if someone walked away from their client computer for a few minutes, they didn't kicked off.  Anyhow, it seems that it's a good thing we block P2P apps at business clients' sites... even with 32,000, etc. connections, if enough users ran a P2P app, they'd eat up all the connections.  Barry, thanks for checking out the timeouts, that's good info to know.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

    --------------------------------------

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to BrucekConvergent
    You're probably right... only half of the tracked connections are in the ESTABLISHED state.

    However, ISTM that might be an easy way to DOS someone.
    I suppose the anti-DOS features should help, though.

    Barry
  • 0 in reply to BarryG
    Seems like dropping ip_conntrack_tcp_timeout_established to a day or so (86400) should help immensely. Could even try going as low as an hour or less for testing.

    The rest of the timeouts seem sane. What types of connections make up the rest of your entries in ip_conntrack?

    I would would lower your max connection count for your P2P apps to 50, you really don't need more than that unless you have a huge amount of bandwidth.
  • 0 in reply to drees
    I lowered it to an hour; didn't make much difference (5-10% at most).

    Most of the established connections are eMule TCP connections.

    I've got 8mbps in, 768k out.

    I've lowered the max connections some more; it doesn't seem to make much difference.

    Thanks,
    Barry
  • 0 in reply to BarryG
    I'll ask again: What types of connections make up the rest of your entries in ip_conntrack? It would be helpful to get a count of each connection type.
    I lowered it to an hour; didn't make much difference (5-10% at most).
    Yeah, I suspected that would happen. It will only cut down on connections that are open and have timed out which don't have any traffic flowing over them.
    Most of the established connections are eMule TCP connections.
    See my first question above. [:)]
    I've lowered the max connections some more; it doesn't seem to make much difference.
    How much more?
  • 0 in reply to drees
    Hmm... after 3 days, the connections have gone down to between 600 and 700.

    I don't know how much of that was from changing the timeout (to 1 hour), and how much from changing the client's max connections (to 150 for both eMule and Azureus).

    Anyways, currently, there are 632 connections:
    1 ICMP
    330 UDP
    301 TCP

    78 connections are outgoing P2P from my PC to external IPs.
    The rest are incoming P2P connections.

    1/3 of the connections are eMule, the rest are BitTorrent.

    Of the 272 incoming TCP connections:
    238 ESTABLISHED
    32 TIME_WAIT
    1 SYN_RECV
    1 CLOSE


    My guess is that remote clients aren't closing their connections.

    Thanks!
    Barry
  • 0 in reply to BarryG
    Do all the established connections on the firewall match up with the established connections you see on your client PC?
  • 0 in reply to drees
    At the moment, windows shows 39 established connections, and ASL shows 137.

    I spot checked a couple of the windows ones on ASL, and yes, there are corresponding entries.

    Thanks,
    Barry
  • 0 in reply to BarryG


    My guess is that remote clients aren't closing their connections.

    Barry


    That's probably what's happening.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

    --------------------------------------

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

Unfiltered HTML