From owner-freebsd-net@FreeBSD.ORG Tue Nov 29 00:34:32 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A974106564A for ; Tue, 29 Nov 2011 00:34:32 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by mx1.freebsd.org (Postfix) with ESMTP id EE1768FC18 for ; Tue, 29 Nov 2011 00:34:31 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 13226 invoked from network); 29 Nov 2011 01:34:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1322526869; bh=sw1iqR1ouiBar4BY2cW45HRrd0gWzB8gR3FszkwEDA0=; h=From:To:Subject; b=PlPYpluYbsse+bN+ZqTAydnx2pLjOQj7j0ERrL3vd+s7pmIjz392SuMF/LI0KHt6y 5VOw0bQBJ0s6dUcThMIyw2X6GuOAqJEInrn130JmXeB2sqOARMlI0Wo8VZz496/fvc GbFPkami0fmEZ6kX/I7/POqUi+pBNXS0gqzJiR2s= Received: from nat.misal.pl (HELO [10.0.0.15]) (marek_sal@[83.19.131.171]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 29 Nov 2011 01:34:28 +0100 Message-ID: <4ED42894.6010506@wp.pl> Date: Tue, 29 Nov 2011 01:34:28 +0100 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Freddie Cash , freebsd-net@freebsd.org References: <4E412116.1070305@wp.pl> <4E422A74.3090601@wp.pl> <4E7B450F.5050802@wp.pl> <4E84B447.7010509@wp.pl> <4E84DE26.6030103@misal.pl> <4E85D8CB.6010104@wp.pl> <4E876705.3040806@wp.pl> <4ED40CF7.2040005@wp.pl> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [IXNU] Cc: Subject: Re: ipfw - accessing DMZ from LAN , pipes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 00:34:32 -0000 W dniu 2011-11-28 23:49, Freddie Cash pisze: > This is something I've never really received a satisfactory answer to. I > believe you have to put your pipe/queue rules in place of your final allow > rules. IOW, the pipe/queue rules are the final rule that a packet touches > in the ruleset. > > For example, for outgoing HTTP traffic, you would allow the packet coming > in on the internal interface. Then you NAT the packet as it goes out the > external interface. And, finally, you send the NAT'd packet to the > pipe/queue, instead of allowing the NAT'd packet out the external interface. Yes! You're right ;) Thanks for suggesting me that I've made like this: $cmd add 4006 pipe 1 ip from $DMZHOST1PUB to any out xmit $PUBLICIF #$cmd add 4010 allow ip from $DMZHOST1PUB to any out xmit $PUBLICIF #commented - used pipe above $cmd add 4016 pipe 2 ip from any to $DMZHOST1 in recv $PUBLICIF #$cmd add 4020 allow ip from any to $DMZHOST1 in recv $PUBLICIF #commented - used pipe above And it worked ;) And at the beginnig of Firewall I put the configs: #pipe for DMZ hosts - pipe 1 upload limit $cmd pipe 1 config bw 200Kbit/s #pipe for DMZ hosts = pipe 2 download limit $cmd pipe 2 config bw 1536Kbit/s > > All of the examples in the man page, handbook, and online show the 'add > pipe' rules first, then the 'pipe config' rules. But that seems backward to > me. So I always do my 'pipe config' rules first. Afterlife, how do you send > a packet to a pipe that doesn't exist yet? :) > ;) it makes sense to config at first and then attach traffic to pipe - for me it works regards, -- Marek Salwerowicz