From trost@cloud.rain.com Sat Nov 20 17:01:54 1999
Return-Path: <trost@cloud.rain.com>
Received: from grey.cloud.rain.com (c1029014-a.bvrtn1.or.home.com [24.12.160.67])
	by hub.freebsd.org (Postfix) with SMTP id 0B6F214F3A
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 20 Nov 1999 17:01:53 -0800 (PST)
	(envelope-from trost@cloud.rain.com)
Received: (qmail 4794 invoked by uid 236); 21 Nov 1999 01:01:52 -0000
Message-Id: <19991121010152.4793.qmail@grey.cloud.rain.com>
Date: 21 Nov 1999 01:01:52 -0000
From: trost@cloud.rain.com
Reply-To: trost@cloud.rain.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: "client" firewall configuration kills incoming broadcast
X-Send-Pr-Version: 3.2

>Number:         15010
>Category:       conf
>Synopsis:       [patch] rc.firewall: "client" firewall configuration kills incoming broadcast
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    keramida
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Nov 20 17:10:01 PST 1999
>Closed-Date:    Fri Mar 15 23:41:35 UTC 2013
>Last-Modified:  Fri Mar 15 23:41:35 UTC 2013
>Originator:     Bill Trost
>Release:        FreeBSD 3.3-STABLE i386
>Organization:
Trost Computing
>Environment:

	rc.conf configured with firewall_enable=YES and firewall_type=client

>Description:

	As provided, the "client" firewall type does not permit the
	host to receive broadcast packets from its local network.

>How-To-Repeat:

	Set the flags.  Install something that needs to receive broadcast
	(e.g., Samba's nmdb).  Watch nothing happen.

>Fix:

	(Just a suggestion).
	
--- rc.firewall.old	Mon Nov  8 19:04:02 1999
+++ rc.firewall	Sat Nov 20 16:58:11 1999
@@ -100,9 +100,11 @@
     mask="255.255.255.0"
     ip="192.168.4.17"
 
-    # Allow any traffic to or from my own net.
-    $fwcmd add pass all from ${ip} to ${net}:${mask}
-    $fwcmd add pass all from ${net}:${mask} to ${ip}
+    # Allow any traffic to or from my own net, including
+    # broadcast traffic.
+    $fwcmd add pass all from ${net}:${mask} to ${net}:${mask} via $ip
+    # undirected broadcast, too
+    $fwcmd add pass all from 255.255.255.255 to $ip via $ip
 
     # Allow TCP through if setup succeeded
     $fwcmd add pass tcp from any to any established



>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: johan 
State-Changed-When: Sun Nov 24 07:24:42 PST 2002 
State-Changed-Why:  
Is this still a problem in more recent releases, 
say for example 4.7? 

Please followup by sending a mail to  
freebsd-gnats-submit@FreeBSD.org 
with the subject of this mail intact. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=15010 

From: Bill Trost <trost@grey.cloud.rain.com>
To: Johan Karlsson <johan@FreeBSD.org>,
	freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: conf/15010: "client" firewall configuration kills incoming broadcast 
Date: Sun, 24 Nov 2002 11:49:08 -0800

 I'm running 4.6.2, but I'm running a hand-crafted firewall
 configuration.  Reading /etc/rc.firewall, I would expect the problem to
 still be there, but it probably needs to actually get tested...
 
 Sorry I don't have better information.
 
 Bill

From: David Malone <dwmalone@maths.tcd.ie>
To: Bill Trost <trost@cloud.rain.com>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: conf/15010: "client" firewall configuration kills incoming broadcast 
Date: Sat, 04 Jan 2003 09:38:41 +0000

 > That was sort of my reaction, too, upon re-reading the bug report.
 > It seems to me that both directions are necessary.  The nmbd needs
 > to receive broadcasts from other SMB servers, as well as be able to
 > transmit its own broadcasts to them.
 
 As far as I know, the source address of a packet should never be
 set to the broadcast address. The patch seems to be testing for
 the source address being a broadcast, which should not happen
 in normal opperation.
 
 > In short, both the bug description and the fix are incomplete.
 
 Was the patch you submitted one that you were actually using, or
 one you extracted from our own custom rules? It doesn't make alot
 of sense to me in the form it is in, but if it got confused when
 transcribed from other rules that would explain it.
 
 	David.

From: Bill Trost <trost@grey.cloud.rain.com>
To: David Malone <dwmalone@maths.tcd.ie>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: conf/15010: "client" firewall configuration kills incoming broadcast 
Date: Thu, 09 Jan 2003 21:06:36 -0800

 David Malone writes:
     As far as I know, the source address of a packet should never be
     set to the broadcast address.
 
 Based on that observation, why would you trust me to suggest
 a good fix?  (-:
     
     Was the patch you submitted one that you were actually using, or
     one you extracted from our own custom rules?
 
 The rule I'm currently using is
 
 	ipfw add pass all from $internal_net to $internal_broadcast via de1
 
 (de1 being the internal net interface).

From: Maxim Konovalov <maxim@macomnet.ru>
To: Bill Trost <trost@cloud.rain.com>
Cc: bug-followup@freebsd.org
Subject: conf/15010
Date: Fri, 14 Apr 2006 22:42:42 +0400 (MSD)

 Hi Bill,
 
 If you still interested in the PR could you please update the patch
 you want to see in FreeBSD.  The one is the PR is not correct as David
 explains.  Thanks!
 
 -- 
 Maxim Konovalov

From: Bill Trost <trost@cloud.rain.com>
To: Maxim Konovalov <maxim@macomnet.ru>
Cc: bug-followup@freebsd.org
Subject: Re: conf/15010 
Date: Sat, 15 Apr 2006 07:31:48 -0700

 Maxim Konovalov writes:
     If you still interested in the PR could you please update the patch
     you want to see in FreeBSD.  The one is the PR is not correct as
     David explains.  Thanks!
 
 Wow, these bugs live forever....
 
 Let's see, my suggestion included the line
 
   $fwcmd add pass all from 255.255.255.255 to $ip via $ip
 
 on the theory that limited broadcast should be permitted. David correctly points
 out that the broadcast address as the source is always wrong. Whoops.
 
 OK, so what I think it really should say is
 
   $fwcmd add pass all from ${net}:$mask to 255.255.255.255 via $ip
 
 Does that seem plausible?
 
 Bill
State-Changed-From-To: feedback->analyzed 
State-Changed-By: keramida 
State-Changed-When: Tue Jun 3 12:32:59 UTC 2008 
State-Changed-Why:  
I'll handle this.  The fix seems pretty straightforward 
but it doesn't require the *removal* of any rules.  We 
can add the one rule to p ass limited broadcast packets, 
as shown at: 

http://people.freebsd.org/~keramida/diff/rc-firewall.limited-bcast.patch 



Responsible-Changed-From-To: freebsd-bugs->keramida 
Responsible-Changed-By: keramida 
Responsible-Changed-When: Tue Jun 3 12:32:59 UTC 2008 
Responsible-Changed-Why:  

http://www.freebsd.org/cgi/query-pr.cgi?pr=15010 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: conf/15010: commit references a PR
Date: Fri,  6 Jun 2008 07:17:31 +0000 (UTC)

 keramida    2008-06-06 07:17:04 UTC
 
   FreeBSD src repository
 
   Modified files:
     etc                  rc.firewall 
   Log:
   SVN rev 179598 on 2008-06-06 07:17:04Z by keramida
   
   Tweak rc.firewall to allow incoming limited broadcast traffic,
   when configured to run in 'client' mode.
   
   PR:             conf/15010
   Submitted by:   Bill Trost, trost at cloud.rain.com
   Reviewed by:    bz
   MFC after:      2 weeks
   
   Revision  Changes    Path
   1.55      +3 -0      src/etc/rc.firewall
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: analyzed->patched 
State-Changed-By: keramida 
State-Changed-When: Fri Jun 6 07:31:33 UTC 2008 
State-Changed-Why:  
Committer a fix for this to HEAD.  I'll have to see if 
we need to also patch rc.firewall6 and then we can MFC 
to STABLE branches. 

Thanks! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=15010 
State-Changed-From-To: patched->closed 
State-Changed-By: eadler 
State-Changed-When: Fri Mar 15 23:41:34 UTC 2013 
State-Changed-Why:  
MFCed/fixed by now or it will never be MFCed 

http://www.freebsd.org/cgi/query-pr.cgi?pr=15010 
>Unformatted:
