From owner-freebsd-ipfw@FreeBSD.ORG Tue Dec 20 06:13:07 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 265AA106564A; Tue, 20 Dec 2011 06:13:07 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 654EB8FC08; Tue, 20 Dec 2011 06:13:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id pBK6D3UV094367; Tue, 20 Dec 2011 17:13:03 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 20 Dec 2011 17:13:03 +1100 (EST) From: Ian Smith To: alan yang In-Reply-To: Message-ID: <20111220153458.I64681@sola.nimnet.asn.au> References: <4EDE2739.1040104@FreeBSD.org> <20111208132002.R16498@sola.nimnet.asn.au> <20111209021345.Y11090@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-ipfw@freebsd.org, araujo@freebsd.org, Sergey Matveychuk Subject: Re: ipfw dscp support X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 06:13:07 -0000 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