freebsd stable - Jul 2009 - Torrent clients bring pf-based firewall to its knees...?

I've recently begun running a torrent client after hours on a PC sitting 
behind our firewall (7.2-STABLE using pf).  I have added a 'rdr' rule to
redirect incoming traffic to the client PC from the firewall, and as far 
as the client is concerned everything is fine.

However, after a short period of torrent activity, the machine running 
the firewall becomes extremely slow and lagged for all network traffic, 
but appears to be operating fine locally.  Remote connections via ssh 
become extremely unresponsive, and eventually connections start timing 
out, but when logged in at the console, there doesn't appear to be any 
problem.  Running tcpdump does not show nusually high volume of traffic, 
no more than I see during normal activity during the day.  The volume 
and length of connections doesn't seem to matter much -- trying to copy 
a BSD or Linux DVD with hundreds of connections breaks just as quickly 
as much smaller torrents with a handful of peers.

I know there are some cheap NAT-ing routers that get in trouble with 
torrents because of the heavy volume of state rules required, but I've 
never heard of anything like that being present in pf.  And I've used 
torrent clients at home behind a pf firewall with no issues, but not on 
this specific version of the FreeBSD.

I've tried shutting down the torrent client, clearing out the state and 
nat rules with pfctl, adding drop rules to reject the torrent traffic, 
and even bringing the network adapter down completely, but only a 
physical reboot (combined with not running the client ever again) seems 
to solve anything.

Has anyone experienced this kind of problem before?  Or alternatively, 
is there some way besides tcpdump and top (neither of which show 
anything unusual) that I can tell what exactly the machine is doing 
that's causing the network lag?

--Mike

If only a reboot solves the problem sounds like a kernel problem?
mbuf leakage?

On 2009-07-24 04:56:11PM -0400, Mike Edenfield wrote:
> I've recently begun running a torrent client after hours on a PC
sitting
> behind our firewall (7.2-STABLE using pf).  I have added a 'rdr'
rule to
> redirect incoming traffic to the client PC from the firewall, and as far as
> the client is concerned everything is fine.
> 
> However, after a short period of torrent activity, the machine running the 
> firewall becomes extremely slow and lagged for all network traffic, but 
> appears to be operating fine locally.  Remote connections via ssh become 
> extremely unresponsive, and eventually connections start timing out, but 
> when logged in at the console, there doesn't appear to be any problem.
> Running tcpdump does not show nusually high volume of traffic, no more than
> I see during normal activity during the day.  The volume and length of 
> connections doesn't seem to matter much -- trying to copy a BSD or
Linux
> DVD with hundreds of connections breaks just as quickly as much smaller 
> torrents with a handful of peers.
> 
> I know there are some cheap NAT-ing routers that get in trouble with 
> torrents because of the heavy volume of state rules required, but I've 
> never heard of anything like that being present in pf.  And I've used 
> torrent clients at home behind a pf firewall with no issues, but not on 
> this specific version of the FreeBSD.
> 
> I've tried shutting down the torrent client, clearing out the state and
nat
> rules with pfctl, adding drop rules to reject the torrent traffic, and even
> bringing the network adapter down completely, but only a physical reboot 
> (combined with not running the client ever again) seems to solve anything.
> 
> Has anyone experienced this kind of problem before?  Or alternatively, is 
> there some way besides tcpdump and top (neither of which show anything 
> unusual) that I can tell what exactly the machine is doing that's
causing
> the network lag?
> 
> --Mike
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
"freebsd-stable-unsubscribe@freebsd.org"
-- 
==========================================================Peter C. Lai          
| Bard College at Simon's Rock
Systems Administrator        | 84 Alford Rd.
Information Technology Svcs. | Gt. Barrington, MA 01230 USA
peter AT simons-rock.edu     | (413) 528-7428
===========================================================

On Fri, Jul 24, 2009 at 04:56:11PM -0400, Mike Edenfield
wrote:
> I've recently begun running a torrent client after hours on a PC
sitting
> behind our firewall (7.2-STABLE using pf).  I have added a 'rdr'
rule to
> redirect incoming traffic to the client PC from the firewall, and as far 
> as the client is concerned everything is fine.
FWIW, I don't do torrents a lot, but I've had no problems running the
Vuze/Azureus torrent client behind a pfSense firewall (7.2-based with
pf)
  -- Clifton

-- 
    Clifton Royston  --  cliftonr@iandicomputing.com / cliftonr@lava.net
       President  - I and I Computing * http://www.iandicomputing.com/
 Custom programming, network design, systems and network consulting services

On Fri, Jul 24, 2009 at 04:56:11PM -0400, Mike Edenfield
wrote:
> However, after a short period of torrent activity, the machine running  
> the firewall becomes extremely slow and lagged for all network traffic,  
> but appears to be operating fine locally.  Remote connections via ssh  
> become extremely unresponsive, and eventually connections start timing  
> out, but when logged in at the console, there doesn't appear to be any
> problem.
This sounds exactly like a problem I had with a server running out of
space in the state table.
> I've tried shutting down the torrent client, clearing out the state and
> nat rules with pfctl, adding drop rules to reject the torrent traffic,  
> and even bringing the network adapter down completely, but only a  
> physical reboot (combined with not running the client ever again) seems  
> to solve anything.
States and rules are separate in pf.  Did you clear out the *states* or
just the rules?  Check how many states are currently allocated
using "pfctl -s info" (or install pftop, it's awesome)

If you are indeed running out of states, add to pf.conf something like:
	set limit states 60000

The default is 10000.

--Emil