2009/6/2 Eric Leblond <eric@xxxxxx>: > Hi, > > Le mardi 02 juin 2009 à 00:47 -0300, Bruno Moreira Guedes a écrit : >> 2009/6/1 Eric Leblond <eric@xxxxxx>: >> > Hi, >> > >> > Le dimanche 31 mai 2009 à 20:05 -0300, Bruno Moreira Guedes a écrit : >> >> 2009/5/27 Bruno Moreira Guedes <thbmatrix@xxxxxxxxx>: >> >> > 2009/5/26 Eric Leblond <eric@xxxxxx>: >> >> >> Hi, >> > >> > If you accept the packet in POSTROUTING nat, it will discard any NAT >> > action done after the NFQUEUE rule. Thus you will need to do NAT by >> > yourself. >> >> Do you have any hint to do the NAT by myself? Where do I start? Thank >> you in the advance. > > You can try to set-up NAT by yourself by modyfing the connection > tracking entry of your packet. You can do so by using > libnetfilter_conntrack. > > I've never tested IP modification via libnetfilter_conntrack but it > should work. > > The painful way is too manually do the translation (ie QUEUE packet in > PREROUTING nat) but has ths chain is placed after connection tracking it > can led to the packet being detected as INVALID by connection tracking > system. > > BR, > -- > Eric Leblond <eric@xxxxxx> > INL: http://www.inl.fr/ > NuFW: http://www.nufw.org/ > I'm taking a look into libnetfilter_conntrack. It's really interesting, but I have another question to ask... Do I need to worry about performance on doing it? My first idea is to use the following ip tables ruleset: nat::PREROUTING, nat:POSTROUTING 1 jump to QUEUE filter::INPUT, filter::OUTPUT, filter::FORWARD 1 ACCEPT ESTABLISHED,RELATED 2 jump to QUEUE But in order to doing "every packet" nat meaning using connection tracking, I need to review this idea to something like: filter::INPUT, filter::OUTPUT, filter::FORWARD 1 jump to QUEUE and also doing all the work here. This is the main reason of my fear. Thank you again!! --Bruno -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
