Concurrent Connections - what happens when you hit the limit

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.

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.

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

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