Application layer classifier for ipfw

[Patrick Tracanelli]

Mike Makonnen escreveu:
> Hi,
> 
> An Internet Cafe I do some work for was recently having problems with 
> very slow internet access. It turns out customers were running P2P file 
> sharing applications which were hogging all the bandwidth. I looked for 
>  programs that would allow me to shape traffic according to the 
> application layer protocol, but couldn't find any for FreeBSD. I found a 
> couple: l7-filter and ipp2p, but these are Linux specific. So, I decided 
> to write one. The result is ipfw-classifyd :
> http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2
> 
> As the name implies it uses ipfw(4) to implement a userland daemon that 
> classifies TCP and UDP packets according to regular expression patterns 
> for various protocols. It's intended to be used with divert(4) sockets 
> and dummynet(4) so you can do traffic shaping depending on the 
> application level protocol. The protocol patterns are from the l7-filter 
> project.
> 
> Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It 
> reads its configuration file for a list of protocols and ipfw(8) rules. 
> Then, when it detects a matching session it re-injects the packet back 
> at the specified rule number. The tarball has a sample configuration 
> file and firewall script to get you started.
> 
> While I have not done extensive testing, preliminary tests are 
> encouraging and it seems to work, so I thought I'd announce it to the 
> rest of the world in case anyone else is interested in this kind of 
> application.
> 
> Comments and suggestions highly appreciated.
> 
> Cheers.

Wont compile on RELENG_6 but is working perfectly on REL_7. I am trying 
hard with ssh, soulseek and msn. Its working like a charm with the 
suggested rc.firewall.

I have configured ipfw-classfyd.conf changing the rules, for a number of 
L7 patterns, and now I try to understand why the "diverted" rules only 
match if the rule number is 1 after the configured, ie, I put soulseek 
to 65530 and a rule wont match there, but the very same rule matches 
65531. I will read the code, but it seems that reinjection of the packet 
is made +1, correct?






-- 
Patrick Tracanelli