From owner-freebsd-questions Sat Dec 1 17:33:34 2001 Delivered-To: freebsd-questions@freebsd.org Received: from services.webwarrior.net (overlord-host99.dsl.visi.com [209.98.86.99]) by hub.freebsd.org (Postfix) with ESMTP id C38ED37B416 for ; Sat, 1 Dec 2001 17:33:17 -0800 (PST) Received: from twincat.vladsempire.net (unknown [209.105.45.51]) by services.webwarrior.net (Postfix) with ESMTP id B27371BD for ; Sat, 1 Dec 2001 19:33:03 -0600 (CST) Received: by twincat.vladsempire.net (Postfix, from userid 1001) id 2F772385E; Sat, 1 Dec 2001 19:33:12 +0000 (GMT) Date: Sat, 1 Dec 2001 19:33:12 +0000 From: Josh Paetzel To: Thor Legvold Cc: freebsd-questions@FreeBSD.ORG Subject: Re: Firewall rules (ipfw) Message-ID: <20011201193311.E493@twincat.vladsempire.net> Mail-Followup-To: Thor Legvold , freebsd-questions@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from tlegvold@hotmail.com on Sun, Dec 02, 2001 at 12:37:28AM +0000 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Dec 02, 2001 at 12:37:28AM +0000, Thor Legvold wrote: > Having a bit of trouble getting my firwall rules refined. > > Am I correct in that a packet gets sent on (and thus bypasses the rest of > the firewall) when it meets a rule it matches (that allows the packet in > question, of course)? Or does it continue on to the next rule when > successfully passing a previous one? Yes. ipfw is a first match wins system. The first rule that matches gets applied to the packet and the rest of the ruleset is skipped. > > Trying to make some sane and simple rules to protect a small home LAN on a > cable connection. Maybe Windows 2000 would be better? I doubt it. :) > > I was thinking it might be an idea to allow DHCP (ports 67/68), TCP (port > 1723) and GRE only on my cable interface, blocking everything else with a > deny rule following the allow ones. There's loads of broadcast, RealNetworks > and other garbage (seen with tcpdump on the cable iface) I assume would be > nice to filter out before it reaches my firewall and NAT, reducing the > amount of work they have to do. Then a nat divert rule to my "inside" > PPTP/VPN iface (a virtual tun interface "inside" the cable interface), > followed by a rule or two against spoofing and then allowing the few things > I plan ok'ing (ssh, no http server, no smtp server, passive ftp only, etc), > being basically "let the LAN access pretty much anything/where on the net, > but deny the net any access to inside machine(s) unless a response to an > inside SYN (setup/established)". > > When I put the global "deny" after allowing GRE/TCP and DHCP (for > configuration of the iface, and bringing up the PPTP connection via port > 1723), my PPTP connection fails. Meaning it appears that the "approved" GRE > packet get's stopped cold when it meets the following deny rule. I'd like it > to continue on to the NAT rule, jumping over the rule denying all other > traffic on the cable interface. Any ideas on how to make ipfw jump through > hoops, or am I trying to do something considered mistreatment of the basic > premise? > > Maybe I should have a divert line _before_ the global deny on cable0, but > divert only GRE packets (as they contain the encapsulated PPTP data)? Then > run the anti spoofing stuff after nat is finished translating the packets, > explicitly allow what I want and leave the deny rule until the very end? > My guess is that the deny log all from any to any via cable0 rule is killing packets before they ever make it to the divert rule. You can confirm this by looking at either the logs or the packet counters. Typically the divert nat rule is one of the first things in the ruleset. Trying to be efficient is always a worthwhile endevor, and crafting rule sets that are as efficient as possible is a good thing (TM), but on the other hand, a 486 can easily do nat and ipfw for a cable modem, so I wouldn't lose too much sleep over it. Josh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message