Re: Avoiding natd overhead
- From: Vladimir Grebenschikov <vova@xxxxxxx>
- Date: Sun, 22 Oct 2006 16:04:02 +0400
В сб, 21/10/2006 в 16:08 -0600, Brett Glass пишет:
At 03:54 AM 10/21/2006, Vladimir Grebenschikov wrote:
1. use PF for nat - it does aliasing in kernel space
True, but it doesn't let me translate the packets and
then continue processing within the firewall -- which
is necessary if you want to catch unregistered destination
addresses BEFORE translation and then unregistered source
addresses AFTER translation.
2. use in-kernel libalias implementation
(I guess man-page for ng_nat(4) will help)
Same problem. I don't know how I could send packets
through a Netgraph node in the middle of processing
by IPFW and then bring them back at the next rule.
Some years ago, I've managed to use ksocket interface to catch divert
packets from ipfw and even return them back (surprisingly it did support
divert AF).
But, be careful, it is easy to get infinite loop in kernel with this
technique. Probably some loop prevention appears in from these times,
but I am not sure.
I suppose that one solution might be, for lack of a--
better term, a "kernel divert socket," which would
pass packets through a kernel module rather than a
user process. (This could actually be used to speed
up many things for which the current "userland"
divert sockets are now used.) It would then be
possible to make a "nat.ko" module, and either
provide a utility to control it or roll that
functionality into ipfw(8).
--Brett
Vladimir B. Grebenschikov
vova@xxxxxxx
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: Avoiding natd overhead
- From: Vlad Galu
- Re: Avoiding natd overhead
- References:
- Avoiding natd overhead
- From: Brett Glass
- Re: Avoiding natd overhead
- From: Vladimir Grebenschikov
- Re: Avoiding natd overhead
- From: Brett Glass
- Avoiding natd overhead
- Prev by Date: Re: Instructing dhclient to set hostname of client
- Next by Date: Re: Instructing dhclient to set hostname of client
- Previous by thread: Re: Avoiding natd overhead
- Next by thread: Re: Avoiding natd overhead
- Index(es):
Relevant Pages
|