[ previous ] [ next ] [ threads ]
 
 From:  "Alex M" <radiussupport at lrcommunications dot net>
 To:  "Monowall Support List" <m0n0wall at lists dot m0n0 dot ch>
 Subject:  RE: [m0n0wall] limiting bandwith to spesific IP (MAC)
 Date:  Wed, 13 Feb 2008 12:11:10 -0500
Albright,
Thanks for help... I will now go and kill the users traffic and priorities

-----Original Message-----
From: Michael Brown [mailto:knightmb at knightmb dot dyndns dot org] 
Sent: Tuesday, February 12, 2008 7:14 PM
To: Monowall Support List
Subject: Re: [m0n0wall] limiting bandwith to spesific IP (MAC)

Is it all HTTP traffic or are you dealing with a p2p user?

An easy way that I've found to shape nearly all p2p use is to look at 
their local ports vs. their destination ports.  First I guess, are you 
getting charged by the MB or is this user just hogging all the bandwidth 
for him/her self which causes a great bandwidth bottleneck for the other 
users?

If the amount of data transfer isn't as important as it's priority, you 
could create some traffic shaping rules that stick all of his transfer 
at the bottom of the queue priority so that for example, if you had a 
1MB connection inbound (for easy math) and this user was burning up the 
1MB connection for hours at a time, him being bumped to the bottom of 
the priority list could squeeze him out of the bandwidth when others 
start to use it. So he starts at a strong 1MB, then someone opens up a 
website or checks e-mail and they all of sudden his 1MB speed drops to 
like 2 or 3 Kbps while the other is taking place, then resumes to full 
speed once the other user was "finished".  I've had great success with 
rules that check the local port and destination port to match against, 
and using myself as a test subject for say BitTorrent for example, I can 
traffic shape myself very well using this so that P2P eats all 
bandwidth, but as soon as anything else comes in, it's bumped to the 
bottom until the other packets come in (or out) and BT resumes back to 
full speed.

On the flip side, if you are paying by the MB, then the same rule can be 
used to just limit transfer speed rather than priority so that they 
can't burn up a large ISP bill using your connection.

On observation I've noticed with nearly all P2P programs is that they 
use Greater 1024 local ports on the client and Greater than 1024 
destination ports for file sharing. So if you set up a rule that 
anything matching both is limited, you won't affect web surfing, e-mail, 
etc.

When all else fails, I think the earlier suggestion of just using the 
DHCP to assign him his own IP address and limit from that would work. 
You could allocate a small section of IP address that DHCP doesn't use 
(maybe a small block of 7) in which you can throw all of your "bandwidth 
abusers" into. Since you plan on using radius to authenticate, you could 
just set a maximum limit that applies to everyone since it already 
supports a "per user bandwidth restriction", just set it to some high 
number that only he would hit and no one else ever would (maybe 1 Gb per 
user if they ever use that much?)

You have lots of options, hopefully they won't be too much trouble to 
maintain.

Thanks,
Michael

Alex M wrote:
> Hey all I have bad user who eats tooooooooo much bandwidth (he downloaded
> like 50Gb in one day) I wanna cut his speed to 128kbps I think I can do
that
> with mono + CP + radius (on the username basis), but I'm running PF Sense
> and they don't support this function (damn) is there any other way to
limit
> that user speeds?
>
>  
>
> Thanks!
>
>
>   

---------------------------------------------------------------------
To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch