On Tue, 26 Oct 2004 14:29:43 +0200, Andre Oppermann <andre_at_freebsd.org> wrote: > Conrad J. Sabatier wrote: > > On Mon, 25 Oct 2004 22:13:05 +0200, Andre Oppermann > > <andre_at_freebsd.org> wrote: > > > > > >>Conrad J. Sabatier wrote: > >> > >>>This problem is occurring with the following kernel options: > >>> > >>>options IPDIVERT > >>>options IPFILTER > >>>options IPFILTER_LOG > >>> > >>>The only workaround at this time is adding "options IPFIREWALL". > >> > >>Yes, that is correct. > >> > >>IPDIVERT is a module now and you can dynamically load it just like > >you>can load ipfw (options IPFIREWALL). > >> > >>IPDIVERT depends on ipfw being loaded or compiled into the kernel. > >> > >>I have done the last step of IPDIVERT's transition into a KLD a few > >>minutes ago. It will warn you now if you try to compile it into a > >>kernel without IPFIREWALL as well. As a module it will simply > >>complain that ipfw needs to be loaded first. > > > > Hmmm. I'm confused now. Up until a day or two ago, the kernel > > would compile just fine without IPFIREWALL. When did IPDIVERT come > > to depend on IPFIREWALL, and why? > > > > Or maybe I'm just *really* confused. I thought I needed IPDIVERT > > for ipnat to work, or am I mistaken? > > Yes, you are confused. ;) IPDIVERT is only required for NAT with ipfw > (a.k.a. IPFIREWALL). > > > What exactly do I need now to use ipf and ipnat? > > ipf and ipnat. Nothing else in the kernel. > > -- > Andre Ah, thanks! -- Conrad J. Sabatier <conrads_at_cox.net> -- "In Unix veritas"Received on Wed Oct 27 2004 - 01:11:40 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:19 UTC