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.

Anyone know what the connection timeout is on the firewall?

I've got 1 PC running, windows says there are about 300 current connections (running eMule and Azureus), but Astaro says there are over 900.
Also, I have the MAX Connections set to 200 in each client.

Thanks,
Barry

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

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.

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.

My experience with all sorts of different customer sites concurs with dree's personal experience...

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