Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Dec 2011 17:13:03 +1100 (EST)
From:      Ian Smith <smithi@nimnet.asn.au>
To:        alan yang <alancyang@gmail.com>
Cc:        freebsd-ipfw@freebsd.org, araujo@freebsd.org, Sergey Matveychuk <sem@freebsd.org>
Subject:   Re: ipfw dscp support
Message-ID:  <20111220153458.I64681@sola.nimnet.asn.au>
In-Reply-To: <CAPATHO3_piwPxS6tC0yZ2MMJWGkR%2BgPgJa585m%2B0BM9mTAcF9A@mail.gmail.com>
References:  <CAPATHO3yFKkYHrhpe-DHf97GMfpzFc43Y8_4k4kJ-oXO0H%2By-w@mail.gmail.com> <4EDE2739.1040104@FreeBSD.org> <CAPATHO2e2Mi=LbPRkkCFmpwUj9zvKbhqqyK6x46uBFW1OAcK6w@mail.gmail.com> <20111208132002.R16498@sola.nimnet.asn.au> <CAOfEmZieG=AKzv-x9XAKjEqUjnPYdkw9%2BmkdBgp_YnB9EnPa3Q@mail.gmail.com> <20111209021345.Y11090@sola.nimnet.asn.au> <CAOfEmZj5%2BChnMr_sqoiyncbVGgb9YVUC5L_nDMnPEcknJNwKNQ@mail.gmail.com> <CAPATHO3_piwPxS6tC0yZ2MMJWGkR%2BgPgJa585m%2B0BM9mTAcF9A@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 19 Dec 2011, alan yang wrote:
 > Hi Marcelo,
 > 
 > Thanks for the modip work!

I still haven't found any docs like the manpage patches or even a clear 
description.  I know such things seem obvious to the programmer :) but 
a few examples really don't cut it for me, even with reference to RFCs, 
and I doubt this could ever be committed without manpage updates.

 > I am trying to see:
 > 
 >      -  ipfw rule to divert traffic for ipfw-classifyd
 >      -  ipfw-classifyd to classify specific traffic: ftp, sip, ...etc.
 >      -  ipfw-classifyd to reinject traffic with sin-port set according
 > to application flow (ftp == 1000, sip == 1001, ... )

But you show no rules just above 1000 and 1001 that would match these?  
See below for some caveats re rule numbering when using divert sockets.

 >      -  ipfw rule modip module to set DSCP
 >      -  ipfw rule to send traffic to appropriate ALTQ queue
 > 
 > with the following ipfw config:
 > 
 >      1)  pfctl to create ALTQ queue: pf.conf
 >                altq on em0 cbq bandwidth 5Mb queue { ftp }
 >                queue ftp bandwidth 10% cbq(default)
 > 
 >           reload pf.conf: pfctl -f /etc/pf.conf

I really can't comment; no experience with pf or ALTQ, only dummynet.

 >      2)  ipfw-classifyd
 > 
 >           /usr/local/sbin/ipfw-classifyd p 7777
 > 
 >      3)  add ipfw rule
 > 
 >           /* enable ALTQ */
 >           ipfw enable ALTQ
 > 
 >      ipfw add 100 divert 7777 tcp from any to any via em0
 >      ipfw add 101 divert 7777 udp from any to any via em0

Rather than relying on 'diverted', you may do better using the general 
ipfw-classifyd method, eg where your protocol definitions point to (as 
per the examples) rule 1000, then after the divert rules, but before or 
at rule 1000 at latest, deal with traffic NOT diverted by classifyd, by 
allowing, denying, piping or perhaps best just 'skipto somewhere_else' 
to get it out of the way.

Also be aware that the 'target' rule given to ipfw-classifyd is the rule 
number PAST which ipfw will resume scanning on a match, moreover that 
the next rule ipfw will run is not the NEXT rule, but the NEXT HIGHER 
NUMBERED rule - either after the divert rule or after the classify-match 
rule - so be sure not to use sets of same-numbered rules, either for 
diverts or as target rules.  Not that you have here, but it's something 
to watch out for; if in doubt, space your rules further apart.

 >      ipfw add 1010 modip dscp:AF11 ip from any to any out diverted
 >      ipfw add 1020 allow altq ftp ip from any to any out diverted
 >      ipfw add 64000 allow altq root_em0 ip from any to any via em0
 > 
 >      (one_pass was enabled in above testing case. )
 >      65535 deny ip from any to any

I'm not sure whether ftp is going to work with this at all.  Passive or 
active ftp?  ./ipfw-classifyd/l7-protocols/protocols/ftp.pat begins:

# FTP - File Transfer Protocol - RFC 959
# Pattern attributes: great notsofast fast
# Protocol groups: document_retrieval ietf_internet_standard
# Wiki: http://protocolinfo.org/wiki/FTP
#
# Usually runs on port 21.  Note that the data stream is on a dynamically
# assigned port, which means that you will need the FTP connection
# tracking module in your kernel to usefully match FTP data transfers.

What's this 'FTP connection tracking module' about?  Do you have this?

To me this sounds like Linux stuff, from whence the l7-protocols come, 
perhaps ip_conntrack_ftp as used with ip_tables?, but I admit to not 
following ipfw-classifyd in this respect well at all .. I think it only 
uses these for pattern-matching, but would be happy to be corrected.

Eg modules on a linux firewall/nat box I'm doomed to keeping an eye on:

ip_nat_quake3           1800   0 (unused)
ip_conntrack_quake3     1896   1
ip_nat_proto_gre        1092   0 (unused)
ip_nat_pptp             2148   0 (unused)
ip_conntrack_pptp       2601   1
ip_conntrack_proto_gre    1973   0 
ip_nat_mms              2672   0 (unused)
ip_conntrack_mms        2832   1
ip_nat_irc              1968   0 (unused)
ip_conntrack_irc        2768   1
ip_nat_h323             2372   0 (unused)
ip_conntrack_h323       2153   1
ip_nat_ftp              2448   0 (unused)
ip_conntrack_ftp        3568   1
iptable_nat            15878   8 
ip_conntrack           18928   7 
ip_tables              10976  14 

 >      4)  observe packet flow through ALTQ ftp queue
 > 
 >           ipfw show - list the packets matched the firewall rule
 >           pfctel -s queue -v - view the packet captured by ALTQ queue
 > 
 > With ICMP and FTP traffics:
 > 
 >           1)  icmp traffic matches rule 64000, traffic direct to root_em0 queue

As you've only diverted tcp and udp traffic above, no surprise there.

 >           2)  ftp traffic matches rule 100, 1010, 1020, 64000 all match
 > 
 > Not sure how to configure ipfw rules so that ftp traffic would match
 > rule 100, 1010, 1020, but not 64000?

Me neither, sorry.  Perhaps there's a way using stateful dynamic rules?

cheers, Ian



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111220153458.I64681>