Date: Thu, 26 Apr 2007 09:10:02 -0300 (BRT) From: eksffa@freebsdbrasil.com.br To: "Julian Elischer" <julian@elischer.org> Cc: eksffa@freebsdbrasil.com.br, ipfw@freebsd.org, Lubomir Georgiev <0shady0recs0@gmail.com> Subject: Re: ipfw with nat - allowing by MAC address Message-ID: <50005.BUtUVAdKVgE=.1177589402.squirrel@webmail.freebsdbrasil.com.br> In-Reply-To: <4630332A.6000508@elischer.org> References: <937e203f0704241000k1db56507jba1b0ac89cd3aece@mail.gmail.com> <4178.BUtUVAdKVgE=.1177554351.squirrel@webmail.freebsdbrasil.com.br> <4630332A.6000508@elischer.org>
index | next in thread | previous in thread | raw e-mail
> eksffa@freebsdbrasil.com.br wrote: >> Ok, I got home (when I have some time) and tried exactly your rule set. >> The main deal why it worked on my example and not your approach is: >> >> - once packets get dropped (denied) on layer2, it will never reach upper >> layers >> >> Thus, NO OTHER action besides deny will avoid the packet getting into >> ip_input or ip_output. >> >> This is crystal-clear on man page, on PACKET FLOW session, and yes, >> sometimes we just ignore the man pages, this si why I found very strange >> when I tried your setup and it showed the exact behavior you described >> (as >> I didnt expect). >> >> What was happening: >> >> When you skipped packets on layer2 to somewhere-else, it was ONLY >> skipped >> for layer2. Since the packet was still in the network stack, when it >> hitted upper layers (ip_input or ip_output) the rule MATCHED the packet. >> In your set, the DIVERT rule matched the packet, and it obviously got >> diverted. >> > > I'm adding code to make divert work at layer 2 too. > (We have that at work). > so be careful. Good news Elischer. I didnt know it was possible, as I thought L2 flow had no L3 or upper layers information. Any chances it will also work with IPFIREWALL_NAT?help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50005.BUtUVAdKVgE=.1177589402.squirrel>