From nobody@FreeBSD.org Mon Feb 1 02:21:30 2010 Return-Path: Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 955C71065694 for ; Mon, 1 Feb 2010 02:21:30 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 845FD8FC22 for ; Mon, 1 Feb 2010 02:21:30 +0000 (UTC) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o112LU6T026307 for ; Mon, 1 Feb 2010 02:21:30 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id o112LUOk026306; Mon, 1 Feb 2010 02:21:30 GMT (envelope-from nobody) Message-Id: <201002010221.o112LUOk026306@www.freebsd.org> Date: Mon, 1 Feb 2010 02:21:30 GMT From: Jed Clear To: freebsd-gnats-submit@FreeBSD.org Subject: IPFW handbook page issues X-Send-Pr-Version: www-3.1 X-GNATS-Notify: >Number: 143416 >Category: docs >Synopsis: [handbook] IPFW handbook page issues >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: handbook >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Mon Feb 01 02:30:04 UTC 2010 >Closed-Date: >Last-Modified: Tue Aug 31 22:33:46 UTC 2010 >Originator: Jed Clear >Release: 6.3 >Organization: dis >Environment: n/a >Description: In http://www.freebsd.org/doc/handbook/firewalls-ipfw.html, section 30.6.5.7 on NAT and statefull, there is a typo, plus some misleading verbiage. The last para before the example rules mentions rule 425 which doesn't exist, but I believe should be 420. The misleading bit occurs in both of the last two paragraphs, specifically the phrase "released on the LAN". It obscures the processing that actually happens with check-state. In the inbound replies to an outbound connection, the check-state match does not do the "release", but causes the same "skipto 500" as in the original match. Rule 500 doesn't match an inbound packet, so natd is skipped, but rule 510 allows the packet. But we're still not released to the LAN as it will traverse ipfw on the inside interface, albeit getting a free pass from rule 2 then. The inbound connection description is even further off. All the example rules are for services running on the firewall, so the inbound packet never reaches the internal LAN. It says the response to that after matching check-state "is then sent to rule 500", but it's not as the original keep-state rule is for an allow, not a skipto. The connection works because NAT isn't required for a service running on the firewall's external IP. Finally the inbound connection description ought to cover a service running on an different interior server, too. The matching rule for that will need to use "skipto 500", rather than allow, so that the check-state for the response will go through the NAT. It took me about an hour to ferret that out today. >How-To-Repeat: n/a >Fix: Rewrite descriptions of outbound and inbound connection processes. Add a rule for an inbound connection to a service running on a different server and describe difference between that and inbound to a service running on the firewall. >Release-Note: >Audit-Trail: >Unformatted: