From owner-freebsd-ipfw Sun Jun 11 0:28:49 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id C724237B9D2 for ; Sun, 11 Jun 2000 00:28:44 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id JAA10194; Sun, 11 Jun 2000 09:30:12 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200006110730.JAA10194@info.iet.unipi.it> Subject: Re: ARP Hack for BRIDGE? In-Reply-To: <20000610133741.G1197@dialin-client.earthlink.net> from "Crist J. Clark" at "Jun 10, 2000 01:37:41 pm" To: cjclark@alum.mit.edu Date: Sun, 11 Jun 2000 09:30:12 +0200 (CEST) Cc: freebsd-ipfw@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I just noticed the following code hiding in the 4.0-STABLE > rc.firewall, > > # If you're using 'options BRIDGE', uncomment the following line to pass ARP > #${fwcmd} add 300 pass udp from 0.0.0.0 2054 to 0.0.0.0 it was ahack to let ARP throgu when you use a closed firewall and net.link.ether.bridge_ipfw=1 i.e. you pass bridged packets through the firewall. i think after recent bridging patches by Archie, you are not able to filter non-ip packets anymore. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sun Jun 11 11:16:29 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from www.phpbuilder.com (host34.rnt.ewr.qwest.net [63.236.72.231]) by hub.freebsd.org (Postfix) with ESMTP id 824F737B565 for ; Sun, 11 Jun 2000 11:16:25 -0700 (PDT) (envelope-from ago@linuxstart.com) Received: (from nobody@localhost) by www.phpbuilder.com (8.9.3/8.9.3) id LAA23410; Sun, 11 Jun 2000 11:19:25 -0400 Date: Sun, 11 Jun 2000 11:19:25 -0400 Message-Id: <200006111519.LAA23410@www.phpbuilder.com> X-Authentication-Warning: www.phpbuilder.com: nobody set sender to ago@linuxstart.com using -f Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 X-Mailer: MIME-tools 4.103 (Entity 4.115) From: ago To: freebsd-ipfw@freebsd.org Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I am setting up a FreeBSD box as an internet firewall/gateway for my home network. I connect to the internet from the firewall box via user ppp with ip aliasing enabled. After i am connected i browse the internet from another box on the local network. This works well untill i apply the following rules to drop RFC 1918 addresses at the outgoing device (tun0). Here is part of my /etc/rc.firewall which shows the rules: fw_outdev="tun0" fw_indev="ed1" fw_localnet="192.168.1.0/16" fw_cmd="ipfw" fw_resip="0.0.0.0 10.0.0.0/8 127.0.0.0/8 172.16.0.0/12 192.168.0.0/16" # IP Spoofing & broadcasts for i in $fw_resip do $fw_cmd add deny log ip from $i to any via $fw_outdev $fw_cmd add deny log ip from any to $i via $fw_outdev done Here is the situation: With the above rules applied all packets from the local net to the internet and visa versa get dropped. To let the ip aliasing do its work i have to allow traffic to and from the local network via the tun0 device. This does not seem to me to be a good way to do this. Does anyone know a better way? ------------------------------------------------ AGO Email: ago@linuxstart.com ---------------------- Do you do Linux? :) Get your FREE @linuxstart.com email address at: http://www.linuxstart.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jun 12 2:57:23 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from vidle.i.cz (vidle.i.cz [193.179.36.138]) by hub.freebsd.org (Postfix) with ESMTP id 1B86B37BF91 for ; Mon, 12 Jun 2000 02:57:20 -0700 (PDT) (envelope-from mm@i.cz) Received: from ns.i.cz (brana.i.cz [193.179.36.134]) by vidle.i.cz (Postfix) with ESMTP id 437C63070C for ; Mon, 12 Jun 2000 11:57:18 +0200 (CEST) Received: from woody.i.cz (woody.i.cz [192.168.18.29]) by ns.i.cz (Postfix) with ESMTP id A9BF536402 for ; Mon, 12 Jun 2000 11:57:17 +0200 (CEST) Content-Length: 2600 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 12 Jun 2000 11:57:17 +0200 (MET DST) Reply-To: mm@i.cz From: Martin Machacek To: freebsd-ipfw@FreeBSD.ORG Subject: Re: Hijacking DNS with ipfw Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 10-Jun-00 Andy Dills wrote: > On Sat, 10 Jun 2000, purpledreams.com system administrator wrote: > Well, to provide more input, I did this: > > I set up apache on this box, running on the standard port 80. I did a: > ipfw add 200 fwd 127.0.0.1,80 tcp from any to any 80 recv xl1 > > And guess what...it worked perfectly. So, I'm growing closer to assuming > this is a named issue. I'm considering trying out tinydns from bernstien, > to see what happens with that. It won't work! Why? The answer is in the code (as usually). Grep for IPFIREWALL_FORWARD in /usr/src/sys/netinet. You will find out that when kernel is compiled with IPFIREWALL_FORWARD and a packet is being redirected via ipfw fwd rule to a local address the only thing that happens is that the check for destination address being local is skipped. BUT only for TCP! The code that does it is in tcp_input.c around line 530 (CURRENT as of today). There is no equivalent counterpart for it in the udp_input function (or anywhere else as far I can see). As a result of that ipfw fwd rules can be used to redirect UDP packet to different next hop (other than the one that you'd look up in routing table) but cannot be used to redirect packets to localhost. It should be probably documented on the ipfw manpage. The reason for this assymetry comes from the difference between connection oriented transport (TCP) and connectionless datagram service (UDP). When sevicing TCP you have (on the server side) one socket for every client (returned from the accept call) and actually the socket structure is the place where the neccessary information about the original target address is being stored. So it can be put in source address field in reply packets. You have nothing like that for UDP. The other reason why ipfw fwd does not work for UDP is that the whole thing is more of a hack than a clean solution. Better (definitely cleaner) solution for redirecting packets working fine also for UDP is being offered by ipfilter. It is part of the base system (I believe since 3.0) and you can enable it by adding the IPFILTER option to kernel configuration and recompiling the kernel. It offers IP filtering sevices (configured via the ipf command - see man ipf) and IP NAT services (configured via ipnat command - man ipnat). It is somewhat harder to use from the programmers point of view (you need couple extra lines of code to get the original destination address) and I don't remember seeing any patch for named that would allow you to do what you want. So, you are on your own anyway ;-). Martin --- [PGP KeyID F3F409C4] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jun 13 9:53:51 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from post.xecu.net (post.xecu.net [216.127.136.211]) by hub.freebsd.org (Postfix) with ESMTP id 3A52C37BFA5 for ; Tue, 13 Jun 2000 09:53:43 -0700 (PDT) (envelope-from andy@xecu.net) Received: from shell.xecu.net (shell.xecu.net [216.127.136.216]) by post.xecu.net (Postfix) with ESMTP id CDF64487B; Tue, 13 Jun 2000 12:51:30 -0400 (EDT) Received: from localhost (andy@localhost) by shell.xecu.net (8.8.8+Sun/8.8.8) with ESMTP id MAA25061; Tue, 13 Jun 2000 12:53:30 -0400 (EDT) X-Authentication-Warning: shell.xecu.net: andy owned process doing -bs Date: Tue, 13 Jun 2000 12:53:30 -0400 (EDT) From: Andy Dills To: cjclark@alum.mit.edu Cc: "purpledreams.com system administrator" , freebsd-ipfw@FreeBSD.ORG Subject: Re: Hijacking DNS with ipfw In-Reply-To: <20000610121626.A1197@dialin-client.earthlink.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 10 Jun 2000, Crist J. Clark wrote: > On Sat, Jun 10, 2000 at 12:30:23PM -0400, Andy Dills wrote: > > [snip] > > > The problem is, AFAIK nat will not do that under any circumstances. I > > tried this approach already: > > > > (I'm running on instance of natd on 8668 already. According to the manpage > > for natd, -reverse is the closest approximation to what I'm trying to do) > > > > natd -p 8669 -alias_address -reverse > > ipfw add 10 divert 8669 udp from any to any 53 via xl1 > > ipfw add 11 fwd 127.0.0.1,53 udp from to any 53 > > > > That's the only way I can think of to do this with nat, and that didn't > > work either. > > Shouldn't this be, > > # cat /etc/natd_dns.conf # command line for natd getting long > port 8669 > interface xl1 > reverse > redirect_address 0.0.0.0 > # natd -f /etc/natd_dns.conf > # ipfw add 10 divert 8669 udp from any to any 53 via xl1 > # ipfw add 11 divert 8669 tcp from any to any 53 via xl1 FWIW, this still didn't do the trick. Because the method I originally wanted to use worked fine for http, I'm 99% sure the source of the problem is with named. I'm off to beat on those bushes, to see if the bind developers can explain it. Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message