[patch] mbuf aware libalias
http://people.freebsd.org/~piso/libalias_mbuf.diff this patch makes libalias able to handle mbuf: TOS, big MTU, much less copy-around, etcetc. I encourage people to test it, since i would like to commit it soon. Known issues: -documentation was not updated -i didn't convert the fragment handling part (GetFragment, SaveFragmentC) since i would like to axe it -all the modules still require some copy-around to work, but i'm teaching them, piece by piece, how to use mbuf bye, P. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: natd interferes with incoming RTSP/RTP
Mikhail T. wrote: Great pointer! As a matter of fact, all I had to comment out was the /lib/libalias_smedia.so... Now, what's wrong with it? Does not disabling this plugin mean, the hosts on the LAN can't access RTSP streams? Thanks! Yours, try this patch: http://people.freebsd.org/~piso/alias_smedia.c.patch ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets?
Luigi Rizzo wrote: Can you put a description in the manpage especially on the assumptions and side effects of the reass option ? E.g. as i read it, + you need to make sure that the fragments are not dropped before the 'reass' (so you cannot rely on port numbers to decide accept or deny). This is obvious but a very common mistake; + reass silently queues the fragment if it does not reass, so it opens up a bit of vulnerability. Again obvious, but people won't realise if they don't see the code. someone else already pointed out that i should mention net.inet.ip.maxfrag*, i'll come up with an updated man page later today. -- bye, P. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets?
Alex Dupre wrote: Luigi Rizzo ha scritto: it is not related to dynamic rules, but to the fact that that the firewall is called before reassembling packets. The info (port numbers especially) is not available in the fragments so the firewall cannot do anything. The only solution would be to call the firewall after reassembly. I am not sure if there is any work in progress for that. FWIW pf has traffic normalization feature (scrub keyword), that reassembles packets before inspection. Unfortunately, it works with IPv4 packets, but lacks IPv6 support. FYI i have a patch for ipfw nat that reassemble a packet before nat[*], but if the idea of an explicit packet reassembly action sounds good, i could move the code over there. [*] actually the patch is really simple, it's just a call to ip_reass() with some glue code, but nonetheless it could be used more globally. -- bye, P. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: kernel nat memory usage?
Evgenii Davidov wrote: tell me please: does kernel nat in ipfw have a memory leak like ng_nat+libalias: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/115526 ? i haven't tested it yet i've never been able to reproduce that bug: i resemble there was a memory leak/a resource was never returned in libalias, but it was plugged months ago. could you update that box (7.x or HEAD) and try again? bye, P. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw and smtp port rewriting
On Sun, May 18, 2008 at 09:51:26PM +0300, Oleksandr Samoylyk wrote: Hello freebsd-ipfw, I'd like to make smtp port rewriting for any destination by means of ipfw. With iptables I just used this rule in order to achieve this functionality: iptables -t nat -A PREROUTING -i ppp+ -p tcp --dport 2525 -j DNAT --to-destination :25 ipfw nat 123 config redirect_port tcp YOURIP:2525 25 ipfw add nat 123 tcp from any to any or something along the line. -- bye, P. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new NAT method ??
On Sat, Mar 22, 2008 at 10:49:21PM -0400, Robert Huff wrote: (I am not subscribed; please CC: me.) I have been told that for 7.0+, network address translation involving ipfw no longer uses natd(8). Is this so? If it is, where do I find documentation on the new correct way to do things? no, natd is there and works fine. in kernel nat for ipfw was just added, for more info see ipfw man page. -- bye, P. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw initialization: SI_ORDER_ANY - SI_ORDER_MIDDLE?
On Sun, Mar 02, 2008 at 03:58:50PM +0100, Luigi Rizzo wrote: The SI_ORDER_* definitions in /sys/sys/kernel.h are enumerated on a large range, so if the existing code does not have races, you can safely move the non-leaf modules (such as ipfw,ko in your case) to (SI_ORDER_ANY - some_small_integer) without breaking anything. fine, i did this. is it MFCable? bye, P. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfw initialization: SI_ORDER_ANY - SI_ORDER_MIDDLE?
Hi, i just found out that depending on a KLD doesn't imply any initialization order, thus depending on a lock initialized in the ipfw init path is _really_ a bad idea from another KLD init path (see ip_fw_nat.c::ipfw_nat_init()). A fix would be to move ipfw init priority from SI_ORDER_ANY to SI_ORDER_MIDDLE, but i guess there are side effects that i'm unaware in this modification... On the other hand, if we keep ipfw at SI_ORDER_ANY, i don't know how to build stuff that relies on it without opening race conditions: see ip_fw_nat.c::flush_nat_ptrs() called in rule deletion and rule configuration paths. bye, P. ps yes, next time i'll better read the MODULE_DEPEND man page... ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw initialization: SI_ORDER_ANY - SI_ORDER_MIDDLE?
On Sun, Mar 02, 2008 at 03:49:39PM +0100, Paolo Pisati wrote:
Hi,
i just found out that depending on a KLD doesn't imply any
initialization order, thus depending on a lock initialized in the ipfw
init path is _really_ a bad idea from another KLD init path (see
ip_fw_nat.c::ipfw_nat_init()).
A fix would be to move ipfw init priority from SI_ORDER_ANY to
SI_ORDER_MIDDLE, but i guess there are side effects that i'm
unaware in this modification...
On the other hand, if we keep ipfw at SI_ORDER_ANY, i don't know how
to build stuff that relies on it without opening race conditions:
see ip_fw_nat.c::flush_nat_ptrs() called in rule deletion and
rule configuration paths.
as the problem arises only during ip_fw_nat initialization, another
viable solution would be to fix ipfw_nat_init() this way:
static void
ipfw_nat_init(void)
{
-IPFW_WLOCK(layer3_chain);
/* init ipfw hooks */
-ipfw_nat_ptr = ipfw_nat;
ipfw_nat_cfg_ptr = ipfw_nat_cfg;
ipfw_nat_del_ptr = ipfw_nat_del;
ipfw_nat_get_cfg_ptr = ipfw_nat_get_cfg;
ipfw_nat_get_log_ptr = ipfw_nat_get_log;
-IPFW_WUNLOCK(layer3_chain);
+ipfw_nat_ptr = ipfw_nat;
ifaddr_event_tag = EVENTHANDLER_REGISTER(ifaddr_event, ifaddr_change,
NULL, EVENTHANDLER_PRI_ANY);
}
avoid grabbing the lock at all during init, and exploit orders of
hooks initialization: as the presence of ipfw_nat in ipfw is checked
via ipfw_nat_ptr, i can narrow/close the race window initializing
ipfw_nat_ptr at the end of the function, but can i trust the order of
variables assignment? i guess no without some sort of memory barriers,
and are memory barriers available in all archs? and are memory
barriers enough?
bye,
P.
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to [EMAIL PROTECTED]
[patch] ipfw_nat as a kld module
Here is the patch against HEAD: http://people.freebsd.org/~piso/ipfw_nat_module.patch Any objection if i commit it? bye, P. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [6.x patchset] Ipfw nat and libalias modules
I'm having a bit of trouble backporting 7.x to 6.x, 6.2 Release specifically. Before I continue down this road, in the name of not re-inventing the wheel twice, does anyone already have a current patch which will work on 6.2 ? Thank You! AFAIK no. -- bye, P. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [6.x patchset] Ipfw nat and libalias modules
On Wed, Sep 05, 2007 at 09:41:50PM -0500, Chris Bowman (Home) wrote: I was recently testing the in kernel nat patch, which is an absolutely wonderful addition in my opinion. I have however run into one issue, when for example I do the following : ipfw nat 10 config ip 2.2.2.2 [snip] Where did you get the 6.x patch? Did you find a tarball around or you backported the code from 7.x? In the first case, that patch is old and buggy, and AFAIK the bug you encountered was due to an uninitialized conditional variable. bye, P. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [6.x patchset] Ipfw nat and libalias modules
On Mon, Jul 03, 2006 at 01:42:36AM +1000, Vini Engel wrote: Paolo Pisati said the following on 15/05/06 08:05: Released a new revision of my libalias+ipfw work as a patchset for 6.x, get it here: http://mercurio.srv.dsi.unimi.it/~pisati/libalias/libalias-6.x.tgz fixed the checksum corruption occurring to redirected/generated traffic to/by a local interface on the nat box. For more info: http://wikitest.freebsd.org/moin.cgi/PaoloPisati Hi guys, I was wondering how stable this is at the moment? I am very keen on using it on my production box(es) but would like to hear someone else's experience first. i know there're people using it on their productions boxes and i didn't hear anyone complaining, so i assume the code is stable. BTW i just started to cleanup my patch for HEAD, but it'll take a bit before i finish everything, so fell free to use the previous patch. bye -- Paolo Piso's first law: nothing works as expected! ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
[6.x patchset] Ipfw nat and libalias modules
Released a new revision of my libalias+ipfw work as a patchset for 6.x, get it here: http://mercurio.srv.dsi.unimi.it/~pisati/libalias/libalias-6.x.tgz fixed the checksum corruption occurring to redirected/generated traffic to/by a local interface on the nat box. For more info: http://wikitest.freebsd.org/moin.cgi/PaoloPisati -- Paolo le influenze esterne sono troppe, il mondo reale non e' mica quello fatato dei komunisti :-p - Anonymous Lumbard ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [6.x patchset] Ipfw nat and libalias modules
Nenad Gavrilovic wrote: Paolo Pisati wrote: I just released a new revision of my libalias+ipfw work as a patchset for 6.x, get it here: http://mercurio.srv.dsi.unimi.it/~pisati/libalias/libalias-6.x.tgz To apply it: cp libalias_ipfw.patch /usr/src cd /usr/src patch -p3 libalias_ipfw.patch then you have to recompile install: kernel, sbin/ipfw, sbin/natd, sbin/ppp, lib/libalias, sys/modules/ipfw, sys/modules/libalias or simply do a world. When I do: cd /usr/src make update (2006-05-05) make clean ... and cp libalias_ipfw.patch /usr/src cd /usr/src patch -p3 libalias_ipfw.patch strange... is your src tree clean? cd /usrc/src find . -name *.rej lets's see if some patch didn't apply. P. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
[6.x patchset] Ipfw nat and libalias modules
I just released a new revision of my libalias+ipfw work as a patchset for 6.x, get it here: http://mercurio.srv.dsi.unimi.it/~pisati/libalias/libalias-6.x.tgz To apply it: cp libalias_ipfw.patch /usr/src cd /usr/src patch -p3 libalias_ipfw.patch then you have to recompile install: kernel, sbin/ipfw, sbin/natd, sbin/ppp, lib/libalias, sys/modules/ipfw, sys/modules/libalias or simply do a world. With this patch you get: -ipfw nat + redirect + LSNAT support -libalias modules (both in user and kernel land) -for kernel land, all the libalias modules are installed in /boot/kernel as alias_*.ko. -for user land (natd ppp), modules are shared lib loaded according to /etc/libalias.conf. To reload modules for a known process, just 'kill -HUP $PID' it. -natd ppp are patched to use libalias modules If your natd/ppp/ipfw behaves strangely after you applied my patch (i.e. active ftp stops working), remember to check libalias modules. Some ipfw examples: ipfw add nat 666 all from any to any via $IF ipfw nat 666 confg ip 192.168.0.1 # nat with a fixed address ipfw nat 666 confg if $IF log # dynamic if addr nat and logging ipfw nat 666 confg if $IF redir_port ...# redirect support with ipfw nat 666 confg if $IF redir_addr ...# linkspec natd syntax, ipfw nat 666 confg if $IF redir_proto ... # LSNAT works too. # different ipfw rules can be redirected to use # the same nat instance ipfw add nat 666 all from $IP1 to any via $IF1 ipfw add nat 666 all from any to any via $IF2 out ipfw add nat 666 all from $IP2 to $IP3 ipfw nat show # see logs ipfw nat show config# nat configuration To load/unload a libalias module (kernel): kldload alias_ftp # active ftp work ok now kldunload alias_ftp To load/unload a libalias module (user): [edit /etc/libalias.conf and add/cut needed modules] kill -HUP $PID For more info see the readme inside the archive. TODO: Not tested on SMP !i386, logging ability should be improved(right now it's the same as original libalias), documentation should be man-pagified, patchset for 7.x, etcetc bye -- Paolo le influenze esterne sono troppe, il mondo reale non e' mica quello fatato dei komunisti :-p - Anonymous Lumbard ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: In-Kernel NAT
On Tue, Apr 04, 2006 at 10:09:37AM -0300, Patrick Tracanelli wrote: Hello Paolo, Thanks for the kind reply. I will try it on i386 and amd64. Is http://ubi8.imc.pi.cnr.it/~flag/libalias/libalias.tgz the latest tar ball? I did not find the mentioned README file there, I had to look at it on perforce, but I did not find the fix-base.sh on the tar ball either. that's _really_ 'funny': [server side] [EMAIL PROTECTED] libalias]$ md5 libalias.tgz MD5 (libalias.tgz) = dd2e1c2378f03dd675cb26789dc071b0 [EMAIL PROTECTED] libalias]$ tar zxvf libalias.tgz libalias libalias/.cvsignore libalias/Makefile libalias/TODO libalias/fix-base.sh [snip] [EMAIL PROTECTED] libalias]$ ls libalias Makefilefix-base.sh ipfw2-5 ipfw2-7 ng_nat readme.txt TODOipfw2-4 ipfw2-6 libaliaspatch test [EMAIL PROTECTED] libalias]$ ls -la libalias.tgz -rw-r--r-- 1 flag flag 573905 Apr 4 16:01 libalias.tgz now, if i click on the wiki's link, firefox retrieve this: [on my laptop] [EMAIL PROTECTED] ~] $ md5 libalias.tgz MD5 (libalias.tgz) = 8f71b7f6574b0a30792119213c08b06f [EMAIL PROTECTED] ~] $ ls -la libalias.tgz -rw-r--r-- 1 flag wheel 77347 Apr 4 16:16 libalias.tgz [EMAIL PROTECTED] ~] $ tar zxvf libalias.tgz x libalias x libalias/kld-cuseeme x libalias/.cvsignore x libalias/HISTORY x libalias/Makefile [snip] [EMAIL PROTECTED] ~] $ ls libalias HISTORY alias_irc.c alias_skinny.c kld-nbt lib-libalias Makefilealias_local.h alias_smedia.c kld-pptplib-nbt alias.c alias_mod.c alias_util.ckld-skinny lib-pptp alias.h alias_mod.h kld-cuseeme kld-smedia lib-skinny alias_cuseeme.c alias_nbt.c kld-dummy lib-cuseeme lib-smedia alias_db.c alias_old.c kld-ftp lib-dummy libalias.3 alias_dummy.c alias_pptp.ckld-irc lib-ftp libalias.conf alias_ftp.c alias_proxy.c kld-libaliaslib-irc that's obviously wrong, WTF?!?!?!! But the real fun starts if you try to retrieve the same archive via wget: [EMAIL PROTECTED] ~] $ wget -c http://ubi8.imc.pi.cnr.it/~flag/libalias/libalias.tgz --16:18:39-- http://ubi8.imc.pi.cnr.it/~flag/libalias/libalias.tgz = `libalias.tgz' [snip] [EMAIL PROTECTED] ~] $ md5 libalias.tgz MD5 (libalias.tgz) = dd2e1c2378f03dd675cb26789dc071b0 [EMAIL PROTECTED] ~] $ ls -la libalias.tgz -rw-r--r-- 1 flag wheel 573905 Apr 4 16:01 libalias.tgz and that's the right one! Anyway, i'm not the admin there so i moved the archive to another box: http://mercurio.sm.dsi.unimi.it/~pisati/libalias/libalias.tgz thanks for the report! :) -- Paolo le influenze esterne sono troppe, il mondo reale non e' mica quello fatato dei komunisti :-p - Anonymous Lumbard ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
