From owner-freebsd-questions Sat Dec 1 16:37:34 2001 Delivered-To: freebsd-questions@freebsd.org Received: from hotmail.com (f145.law3.hotmail.com [209.185.241.145]) by hub.freebsd.org (Postfix) with ESMTP id 09E8837B416 for ; Sat, 1 Dec 2001 16:37:32 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 1 Dec 2001 16:37:28 -0800 Received: from 213.225.121.247 by lw3fd.law3.hotmail.msn.com with HTTP; Sun, 02 Dec 2001 00:37:28 GMT X-Originating-IP: [213.225.121.247] From: "Thor Legvold" To: freebsd-questions@freebsd.org Subject: Firewall rules (ipfw) Date: Sun, 02 Dec 2001 00:37:28 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Dec 2001 00:37:28.0785 (UTC) FILETIME=[85615C10:01C17AC9] 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 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? 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 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? I currently have the following: # Allow loopback iface, stop all 127 addresses ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 # Allow DHCP setup via cable0 ${fwcmd} add allow log udp from any 67 to 0.0.0.0 68 out xmit cable0 ${fwcmd} add allow log udp from 10.10.0.0/16 67 to 10.10.2.0/24 68 in via cable0 # Allow GRE & PPTP control connection ${fwcmd} add allow tcp from any to any 1723 in recv cable0 setup ${fwcmd} add allow gre from any to any via cable0 # Stop all other traffic via cable0 - only GRE/PPTP/DHCP allowed ${fwcmd} add deny log all from any to any via cable0 # NAT ${fwcmd} add divert natd log all from any to any via tun0 ...The rest is still under development, I'll be back when I get to it later... :-) Regards, Thor _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message