> [EMAIL PROTECTED] 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? _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
