>> This is no longer true; he did indeed find "firewall_nat_enable"
>> in /etc/defaults/rc.conf. The knob seems to have first appeared
>> in February in HEAD and I'm guessing it cues the system to use a
>> new kernel-based nat rather than natd(8), but I've not read anything
>> further about this, as my system isn't as up to date as the OP's.
>> I don't know when this change was MFC'ed, but apparently fairly
> firewall_nat_* was added in the begenning of year in RELENG_7
> This is two different ways to do NAT. I can't speak about performance,
> kernel vs daemon.
Apologies for jumping in another thread commenting on my own question,
but I think the questions are very similar (see "Recompile kernel or
module for ipfw+nat?",
It would seem that doing NAT with ipfw (in-kernel as opposed to using
userland natd) is not possible in 7.0-RELEASE-p4 without recompiling
the kernel to include IPDIVERT even though IPDIVERT was converted to
loadable module way back. And I have doubts that even recompiling the
kernel would help doing "ipfw add nat 123 all from any to any".
However, I found the reason for that might be the following CVS commit message:
# $FreeBSD: src/sys/modules/ipfw_nat/Makefile,v 1.1 2008/02/29
22:27:18 piso Exp $
"Move ipfw's nat code into its own kld: ipfw_nat."
which got commited to RELENG_7 and HEAD only (explains why it doesn't
work on my 7.0-RELEASE-p4).
My guess is that this functionality is already available in 7.1-BETA
since the code freeze began in September and ipfw nat code got
committed in February.
I can only guess if what I wrote above if correct, but I'll upgrade
one machine to 7.1-BETA as soon as I get some spare time.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"