From owner-freebsd-questions Fri Mar 19 15:53:51 1999 Delivered-To: freebsd-questions@freebsd.org Received: from inet.chip-web.com (c1003518-a.plstn1.sfba.home.com [24.1.82.47]) by hub.freebsd.org (Postfix) with SMTP id 01DA514FDF for ; Fri, 19 Mar 1999 15:53:48 -0800 (PST) (envelope-from ludwigp@bigfoot.com) Received: (qmail 9022 invoked from network); 19 Mar 1999 23:53:28 -0000 Received: from speedy.chip-web.com (HELO speedy) (172.16.1.1) by inet.chip-web.com with SMTP; 19 Mar 1999 23:53:28 -0000 Message-Id: <4.1.19990319154231.00af9650@mail-r> X-Sender: ludwigp2@mail-r X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 19 Mar 1999 15:53:18 -0800 To: Jeff Yeo , "'freebsd-questions@freebsd.org'" From: Ludwig Pummer Subject: Re: ipfw rule blocking connection In-Reply-To: <8E6C9AEA17A8D2118D6E00A0C99869402AF48A@HERMES.pml.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 01:22 PM 3/19/99 , Jeff Yeo wrote: >ipfw add deny all from any to 192.168.0.0:255.255.0.0 via ${oif} > >I'm assuming that natd changes the destination address on the >packet and reinjects it into the packet stream. When it hits the >above rule, it appears that there has been a packet received on >${oif} with a destination of 192.168.1.x and the packet is dropped. >Is this correct? If that's what your 'ipfw show' says. >I'd like to explicitly deny any packets received on ${oif} with a >destination of 192.168.x.y (and still be able to access the 'Net >from inside, of course). Is this possible? Yes. See below. >Is simply omitting the above rule a reasonable thing to do? Upon >reflection, it seems that (a) routers on the Internet should not >forward pakcets with a destination network of 192.168.0.0/16 , But someone may send packets from those addresses in a deliberate attempt to do something harmful to you. >and (b) the firewall's external interface will not receive packets >with a destination address other than it's own (oops it is a gateway, >so this isn't that safe either). Hmmmm. Correct... but that's only before natd gets through with the packets. When you're using natd, you have to remember that packets get sent to natd by a certain divert rule in your ipfw. Before that rule, the destination address will be your outside Internet IP. NATD does its work and reinjects the packet. The divert rule gets skipped. Now the packet's destination address may be one of your internal address (I say 'may be' because the gateway machine itself may have sent out something). I'm running 2.2.5-R (old, I know. it'll be replaced when I get the replacement server completely up and running) My rc.firewall using the 'OPEN' firewall type: $OIP is my outside Internet IP address. #$fwcmd add 2000 divert natd all from any to any via vx0 $fwcmd add 4000 deny log all from $OIP to $OIP in via vx0 $fwcmd add 4010 deny log all from 172.16.0.0/12 to any in via vx0 $fwcmd add 4020 deny log all from 192.168.0.0/16 to any in via vx0 $fwcmd add 4030 deny log all from 10.0.0.0/8 to any in via vx0 #^-- disallow spoofers spoofing over cable modem interface $fwcmd add 5000 deny log tcp from any to $OIP 137,138,139 in via vx0 $fwcmd add 8000 divert natd all from any to any via vx0 $fwcmd add 10000 deny log tcp from any to $OIP pop2,pop3,imap via vx0 $fwcmd add 65000 pass all from any to any Note that my rule 4000 works as it does because I have a route for $OIP. I also could rearrange the order of my rules 5000 and 10000. If you take a look, I block RFC 1918 subnets before NATD does its magic, so the destination IPs of traffic coming in via vx0 is still my $OIP address. If you run a FreeBSD newer that 2.2.5 (like your 2.2.8), then NATD is called via rc and rc.conf. You may need to stick a firewall rule number in your rc, and add rule numbers to your rc.firewall to make sure that natd gets called before and after the proper rules. --Ludwig Pummer ( ludwigp@bigfoot.com ) ICQ UIN: 692441 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message