From owner-freebsd-net@FreeBSD.ORG Wed Jul 21 11:53:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E0D616A4CE for ; Wed, 21 Jul 2004 11:53:28 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B28BB43D1D for ; Wed, 21 Jul 2004 11:53:27 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 30390 invoked from network); 21 Jul 2004 11:51:12 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Jul 2004 11:51:12 -0000 Message-ID: <40FE5938.6890EC8C@freebsd.org> Date: Wed, 21 Jul 2004 13:53:28 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James References: <20040720021237.GA74977@scylla.towardex.com> <40FCD21B.40CB83ED@freebsd.org> <20040721020418.GA53214@scylla.towardex.com> <40FE4367.AA7B0A7F@freebsd.org> <20040721114455.GA47249@scylla.towardex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: James Subject: Re: IPFW2 versrcreach update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 11:53:28 -0000 James wrote: > > Andre, > > > > > James, > > > > it just occured to me; but what is the purpose of versrcreach denying a > > packet that will be discarded a few cycles later anyway? When I mark > > a route with -reject I want the ICMPs go out and still use the versrcreach > > functionality in ipfw. > > The point is to have uRPF loose-check *drop* the packets sourced from IP's that > are null-routed. A null route would discard the packet destined *to* the null > route, but it would never drop a packet *sourced* with an IP within the null > route. Yea, sorry, you are right. Wasn't really up to speed this morning... ;-) > uRPF should not emit an ICMP when it drops a -reject route. Even with > ip unreachables, Cisco won't emit ICMP when uRPF is killing a packet. The source > that triggered uRPF drop condition cannot be trusted as it may have spoofed the > packet. Ok, I'll go ahead and commit this to ipfw2 later today. -- Andre