From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 26 22:25:17 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 583091065672 for ; Sun, 26 Feb 2012 22:25:17 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 27F008FC14 for ; Sun, 26 Feb 2012 22:25:16 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1QMPEtw090445 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 26 Feb 2012 14:25:16 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F4AB14B.5000601@freebsd.org> Date: Sun, 26 Feb 2012 14:25:15 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Matthias Apitz References: <4F4A9E87.4080807@freebsd.org> <20120226211424.GA1534@tiny> In-Reply-To: <20120226211424.GA1534@tiny> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: hackers@freebsd.org Subject: Re: o X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2012 22:25:17 -0000 On 2/26/12 1:14 PM, Matthias Apitz wrote: > El día Sunday, February 26, 2012 a las 01:05:11PM -0800, Julian Elischer escribió: > >> On 2/26/12 5:34 AM, Bob Bishop wrote: >>> Hi, >>> >>> I'd like to hear from somebody who understands this stuff on the relative merits of blackhole routes vs firewall drop rules for dealing with packets from unwanted sources. I'm particularly interested in efficiency and scalability. Thanks >> the key is the word "from". routes can only be selected on 'TO' >> (destination) where >> firewalls can select on any combination of header fields. > I understand the idea of the OP as, based on the source IP addr, he > wants to install routes that the resulting IP pkg to the source IP goes > to "nowhere", i.e. not back to the origin IP and the 1st SYN is not > answered back to the source IP; yes but that is wasteful because you have used resources answering the incoming packet. it would be better to have blocked it in the first place. > matthias