From nobody@FreeBSD.org  Tue Jul  2 03:46:15 2002
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id D3FD237B400
	for <freebsd-gnats-submit@FreeBSD.org>; Tue,  2 Jul 2002 03:46:15 -0700 (PDT)
Received: from www.freebsd.org (www.FreeBSD.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 94EAA43E09
	for <freebsd-gnats-submit@FreeBSD.org>; Tue,  2 Jul 2002 03:46:15 -0700 (PDT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.12.4/8.12.4) with ESMTP id g62AkFOT044327
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 2 Jul 2002 03:46:15 -0700 (PDT)
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.12.4/8.12.4/Submit) id g62AkF4J044326;
	Tue, 2 Jul 2002 03:46:15 -0700 (PDT)
Message-Id: <200207021046.g62AkF4J044326@www.freebsd.org>
Date: Tue, 2 Jul 2002 03:46:15 -0700 (PDT)
From: Bill Purvis <wp@High-Availability.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: IP Firewall code doesn't behave as expected
X-Send-Pr-Version: www-1.0

>Number:         40108
>Category:       kern
>Synopsis:       IP Firewall code doesn't behave as expected
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    luigi
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jul 02 03:50:01 PDT 2002
>Closed-Date:    Sat Jul 13 14:38:45 PDT 2002
>Last-Modified:  Sat Jul 13 14:38:45 PDT 2002
>Originator:     Bill Purvis
>Release:        4.6
>Organization:
High-Availability.Com
>Environment:
>Description:
I have been asked to test one of our products under FreeBsd involving
monitoring behaviour of a firewall. I have no previous experience with
FreeBsd, but extensive experience with other Unixes, particularly Linux.
I installed 4.6 on a PC and tried to set up a firewall. This seemed OK
but I noticed that when I set up a rule to deny access to a remote
machine, the behaviour was not what I see on other Unixes. I had
requested the firewall to "drop" the packets, but I received an 
immediate error response, which caused the monitor program to misinterpret the test. Other systems simply drop the packet and return
no error indication. The monitor program expects the request to time out and gets upset if this is not the case. I then looked at the
source code (netinet/ip_output.c) and noted that when the firewall
returns a "drop" indication, the code sets error = EACCESS; before
dropping the packet and exiting. I patched this out and the system 
now behaves in the manner I expect.

I read through the man pages for "ipfw" (several times) and feel that
the wording gives the impression that the behaviour does not match
that in the man page. I dislike the statement that "drop" and "deny"
are synonyms - I would be quite happy with the current behaviour if
I used "deny", but expect "drop" to do so without error return. 

>How-To-Repeat:
1) set up a "drop" rule using ipfw to a specific remote machine.
2) attempt to telnet/ping/??? to that remote machine.
3) note the error message returned.
>Fix:
Remove the statement

     error = EACCESS

from ip_output.c (just following the firewall call)

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->luigi 
Responsible-Changed-By: dougb 
Responsible-Changed-When: Tue Jul 2 13:38:05 PDT 2002 
Responsible-Changed-Why:  

He's been poking the ipfw bits. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=40108 
State-Changed-From-To: open->analyzed 
State-Changed-By: luigi 
State-Changed-When: Tue Jul 2 14:15:47 PDT 2002 
State-Changed-Why:  
Noticed the report, I do not believe that it is a bug. 



Class-Changed-From-To: sw-bug->change-request 
Class-Changed-By: luigi 
Class-Changed-When: Tue Jul 2 14:15:47 PDT 2002 
Class-Changed-Why:  
Noticed the report, it is not a bug but a change request. 
The system does not behave as the user expects, but it does 
behave in a reasonable way, the firewall can notify the local source 
that the packet has been dropped and it does that. 


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

From: Bill Fumerola <billf@mu.org>
To: Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/40108: IP Firewall code doesn't behave as expected
Date: Tue, 2 Jul 2002 14:59:34 -0700

 On Tue, Jul 02, 2002 at 03:46:15AM -0700, Bill Purvis wrote:
 
 > >How-To-Repeat:
 > 1) set up a "drop" rule using ipfw to a specific remote machine.
 > 2) attempt to telnet/ping/??? to that remote machine.
 > 3) note the error message returned.
 > >Fix:
 > Remove the statement
 > 
 >      error = EACCESS
 > 
 > from ip_output.c (just following the firewall call)
 
 this is not a bug, this is the defined behavior of ipfw.
 
 -- 
 - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org
 
 
State-Changed-From-To: analyzed->closed 
State-Changed-By: luigi 
State-Changed-When: Sat Jul 13 14:38:14 PDT 2002 
State-Changed-Why:  
I do not believe we want to change this. 


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