Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 Sep 2003 21:48:19 -0700
From:      "Crist J. Clark" <cristjc@comcast.net>
To:        Sten Daniel S?rsdal <sten.daniel.sorsdal@wan.no>
Cc:        freebsd-ipfw@freebsd.org
Subject:   Re: verrevpath - denies local multicast. Is this intended?
Message-ID:  <20030905044819.GA72999@blossom.cjclark.org>
In-Reply-To: <0AF1BBDF1218F14E9B4CCE414744E70F07DF28@exchange.wanglobal.net>
References:  <0AF1BBDF1218F14E9B4CCE414744E70F07DF28@exchange.wanglobal.net>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Fri, Aug 29, 2003 at 02:45:55PM +0200, Sten Daniel S?rsdal wrote:
> 
> when using verrevpath it seems to drop local multicast packets suck as RIP2.
> i use it as suggested; deny log ip from any to any not verrevpath
> 
> logentry:
> Aug 29 14:32:08 <security.info> fictious /kernel: ipfw: 1011 Deny UDP 80.86.140.54:520 224.0.0.9:520 in via fxp1

What does,

  # route get 80.86.140.54

Return? If it's fxp1, I'm not sure what might be going wrong.

> i read in /sys/netinet/ip_fw2.c:
> 
> /*
>  * The 'verrevpath' option checks that the interface that an IP packet
>  * arrives on is the same interface that traffic destined for the
>  * packet's source address would be routed out of. This is a measure
>  * to block forged packets. This is also commonly known as "anti-spoofing"
>  * or Unicast Reverse Path Forwarding (Unicast RFP) in Cisco-ese. The
>  * name of the knob is purposely reminisent of the Cisco IOS command,
>  *
>  *   ip verify unicast reverse-path
>  *
>  * which implements the same functionality. But note that syntax is
>  * misleading. The check may be performed on all IP packets whether unicast,
>  * multicast, or broadcast.
>  */
> 
>  does this mean it should deny multicast and broadcasts or that it really should 
>  verify that the multicast path is correct? 

The _only_ thing it does is check that the interface a packet arrives
on is the same interface that it would route out of to reach the source
address of the packet. All that matters in this case is where
80.86.140.54 gets routed to.
-- 
Crist J. Clark                     |     cjclark@alum.mit.edu
                                   |     cjclark@jhu.edu
http://people.freebsd.org/~cjc/    |     cjc@freebsd.org



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20030905044819.GA72999>