From owner-freebsd-bugs Tue Jul 2 3:50: 9 2002 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDF8437B400 for ; Tue, 2 Jul 2002 03:50:03 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DEAE43E13 for ; Tue, 2 Jul 2002 03:50:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.4/8.12.4) with ESMTP id g62Ao3JU076915 for ; Tue, 2 Jul 2002 03:50:03 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.4/8.12.4/Submit) id g62Ao2Et076913; Tue, 2 Jul 2002 03:50:02 -0700 (PDT) Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3FD237B400 for ; 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 ; 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 ; 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 To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: kern/40108: IP Firewall code doesn't behave as expected Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 40108 >Category: kern >Synopsis: IP Firewall code doesn't behave as expected >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Jul 02 03:50:01 PDT 2002 >Closed-Date: >Last-Modified: >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: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message