From owner-freebsd-ipfw@FreeBSD.ORG Mon Jul 18 19:05:33 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F107106564A for ; Mon, 18 Jul 2011 19:05:33 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout018.mac.com (asmtpout018.mac.com [17.148.16.93]) by mx1.freebsd.org (Postfix) with ESMTP id EA4AE8FC0C for ; Mon, 18 Jul 2011 19:05:32 +0000 (UTC) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp018.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LOJ00MB0MD8LF70@asmtp018.mac.com> for freebsd-ipfw@freebsd.org; Mon, 18 Jul 2011 12:05:32 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-07-18_06:2011-07-18, 2011-07-18, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107180155 From: Chuck Swiger In-reply-to: Date: Mon, 18 Jul 2011 12:05:32 -0700 Content-transfer-encoding: quoted-printable Message-id: <02D2E336-48EE-498E-87AA-8A307EC2EF74@mac.com> References: To: David van Rensburg - PC Network X-Mailer: Apple Mail (2.1084) Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw and nat problem X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 19:05:33 -0000 On Jul 18, 2011, at 11:53 AM, David van Rensburg - PC Network wrote: > Yes sorry - I suppose I was assuming that goes without saying. Well, you can't design working firewall rulesets with unstated = requirements. > Will open 443 for https and close 80 and do a transparent squid proxy > which I got to wkr. You need to permit *both* 80 and 443, either directly or via the Squid = proxy. > I just cant seem to understand in and out. > Does in mean INTO the BOX or into the specific interface what happens = if > you don=B9t specify an interface when u say in or out? > OR does in mean into the internal network from outside or just into = the > box? >=20 > Please just elaborate on that for me ? In refers to incoming traffic to the box running IPFW (and also NAT'ed = traffic which gets re-written by natd to your internal clients); out = refers to traffic generated from the box (and/or from NAT traffic from = internal machines via natd). If that doesn't make sense, consider using = "recv", "xmit", and "via ifX" instead: recv | xmit | via {ifX | if* | ipno | any} Matches packets received, transmitted or going through, = respec- tively, the interface specified by exact name (ifX), by = device name (if*), by IP address, or through some interface. The via keyword causes the interface to always be checked. = If recv or xmit is used instead of via, then only the receive = or transmit interface (respectively) is checked. By = specifying both, it is possible to match packets based on both receive = and transmit interface, e.g.: ipfw add deny ip from any to any out recv ed0 xmit = ed1 The recv interface can be tested on either incoming or = outgoing packets, while the xmit interface can only be tested on = outgoing packets. So out is required (and in is invalid) whenever = xmit is used. A packet may not have a receive or transmit interface: = packets originating from the local host have no receive interface, = while packets destined for the local host have no transmit = interface. Regards, --=20 -Chuck