Re: IPFW with user-ppp's NAT
Erik Trulsson wrote: On Sun, Mar 16, 2008 at 04:37:18PM +0100, Wojciech Puchar wrote: Frankly I'm a bit surprised that this hasn't been more widely heralded, as userland natd is often given as a reason to prefer other firewalls, what's wrong in userland natd? Performance. With userland natd, every packet that passes through natd must pass from kernel to userland (causing one context switch) and back again (causing another context switch). This will be slower and use more CPU than doing it all inside the kernel, without any context switches. Online reconfiguration. Userland natd requires a restart (and a loss of all nat state information) when you want to change forwarded ports and such, whereas the in-kernel NAT engines (in ipf and pf, at least) support reconfiguration without flushing state. To a large extent, at least. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net [EMAIL PROTECTED] Furry Peace! - http://.fur.com/peace/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW with user-ppp's NAT
On Sat, 15 Mar 2008 21:16:12 -0500 Dan Nelson [EMAIL PROTECTED] wrote:
In the last episode (Mar 16), Razmig K said:
With IPFW enabled in the kernel, I'd like to use the NAT functionality of
user-ppp instead of natd. Do I need the IPDIVERT option in the kernel and
the special arrangement of divert and skipto rules in the ruleset? Or, a
non-NATed ruleset (as demonstrated in handbook section 28.6.5.6) would
suffice?
If divert rules are necessary, what argument do I need to pass to action
divert in place of natd?
If you mean the nat enable yes option in ppp.conf, that is done
completely within the user-ppp daemon (using the same libalias libarary
that natd uses). Since user-ppp creates its own tun# device, it can
call the NAT functions as it processes packets to/from that device
without needing IPFW divert rules.
True, though if you're running FreeBSD 7 you can instead use ipfw(8)'s
new in-kernel NAT, which uses the same libalias and semantics.
Frankly I'm a bit surprised that this hasn't been more widely heralded,
as userland natd is often given as a reason to prefer other firewalls,
even in the handbook. ('legacy', indeed :)
And while being frank .. the present ipfw section in the handbook needs
rewriting in large part. It contains undue deprecation, misconceptions,
outdated information and some straight up errors, both of principle and
usage. Using rc.firewall as a base example (modulo needing to permit
appropriate icmp traffic) and a fair study of ipfw(8) should yield a
better firewall, with or without NAT - certainly a more comprehensible
and flexible one - than the examples in that section.
Cheers, Ian
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW with user-ppp's NAT
Frankly I'm a bit surprised that this hasn't been more widely heralded, as userland natd is often given as a reason to prefer other firewalls, what's wrong in userland natd? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW with user-ppp's NAT
On Sun, Mar 16, 2008 at 04:37:18PM +0100, Wojciech Puchar wrote: Frankly I'm a bit surprised that this hasn't been more widely heralded, as userland natd is often given as a reason to prefer other firewalls, what's wrong in userland natd? Performance. With userland natd, every packet that passes through natd must pass from kernel to userland (causing one context switch) and back again (causing another context switch). This will be slower and use more CPU than doing it all inside the kernel, without any context switches. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW with user-ppp's NAT
what's wrong in userland natd? Performance. With userland natd, every packet that passes through natd must pass from kernel to userland (causing one context switch) and back again (causing another context switch). This will be slower and use more CPU than doing it all inside the kernel, without any context switches. true, anyway for my two 2Mbps symmetric connection (all for nat), and three 4/0.5Mbit connections (part for nat, mostly for squid) all natd processes takes at most 3 percent of single core (core2duo). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW with user-ppp's NAT
On Sun, 16 Mar 2008 18:20:12 +0100 (CET) Wojciech Puchar [EMAIL PROTECTED] wrote: what's wrong in userland natd? Performance. With userland natd, every packet that passes through natd must pass from kernel to userland (causing one context switch) and back again (causing another context switch). This will be slower and use more CPU than doing it all inside the kernel, without any context switches. true, anyway for my two 2Mbps symmetric connection (all for nat), and three 4/0.5Mbit connections (part for nat, mostly for squid) all natd processes takes at most 3 percent of single core (core2duo). Sure. And with my little 512/128k ADSL link, soon 1500/256, I doubt you could even measure the difference. I haven't seen any comparative data on high-performance boxes but as Erik points out, it may be significant. Just to make it clear, my point was that one reason for deprecating ipfw is out the door, and that its development is ongoing. I see rc.firewall has had a recent facelift too, including a stateful 'workstation' type. (Sorry that our ancient mail setup blocked your mail; hopefully fixed.) cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
IPFW with user-ppp's NAT
Hello, With IPFW enabled in the kernel, I'd like to use the NAT functionality of user-ppp instead of natd. Do I need the IPDIVERT option in the kernel and the special arrangement of divert and skipto rules in the ruleset? Or, a non-NATed ruleset (as demonstrated in handbook section 28.6.5.6) would suffice? If divert rules are necessary, what argument do I need to pass to action divert in place of natd? Thank you. //rk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW with user-ppp's NAT
In the last episode (Mar 16), Razmig K said: With IPFW enabled in the kernel, I'd like to use the NAT functionality of user-ppp instead of natd. Do I need the IPDIVERT option in the kernel and the special arrangement of divert and skipto rules in the ruleset? Or, a non-NATed ruleset (as demonstrated in handbook section 28.6.5.6) would suffice? If divert rules are necessary, what argument do I need to pass to action divert in place of natd? If you mean the nat enable yes option in ppp.conf, that is done completely within the user-ppp daemon (using the same libalias libarary that natd uses). Since user-ppp creates its own tun# device, it can call the NAT functions as it processes packets to/from that device without needing IPFW divert rules. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
