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

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
  • 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.

  • 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
  • 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
  • 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
  • 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.

  • 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
  • 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.
  • 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
  • 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?
  • 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
  • Do all the established connections on the firewall match up with the established connections you see on your client PC?
  • 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
Reply Children
No Data