Re: Torrent clients bring pf-based firewall to its knees...?
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 -- clift...@iandicomputing.com / clift...@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Torrent clients bring pf-based firewall to its knees...?
My apologies all, This was clearly not intended for this list :-) - Thanks - - Dave Rivers - Is there a main() function in your program? Are you building this for LE operation, or with the Systems/C runtime? If it's Systems/C, are you using the RENT library (and the -frent option on the compilation?) If you want to build a non-RENT program for USS, you can, but you have to set the appropriate environment varible under USS to execute it; as a USS program is executed with the code sections marked READ-ONLY. - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Torrent clients bring pf-based firewall to its knees...?
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 6 The default is 1. --Emil ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Torrent clients bring pf-based firewall to its knees...?
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-unsubscr...@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 === ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Torrent clients bring pf-based firewall to its knees...?
Is there a main() function in your program? Are you building this for LE operation, or with the Systems/C runtime? If it's Systems/C, are you using the RENT library (and the -frent option on the compilation?) If you want to build a non-RENT program for USS, you can, but you have to set the appropriate environment varible under USS to execute it; as a USS program is executed with the code sections marked READ-ONLY. - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
