* [Apr 04, 2003] Alex Combas <[EMAIL PROTECTED]>: > On Fri, 2003-04-04 at 06:28, Anupam Kapoor wrote: > > Matt Neimeyer wrote : > > > I'm running through the IPMasq setup portion (section 3.4.1) of the > > > IPMasq How-To at > > > http://www.ecst.csuchico.edu/~dranch/LINUX/ipmasq/c-html/index.html > > > > > > I've gotten to the line "iptables -t nat -A POSTROUTING -o eth5 -j > > > MASQUERADE" in the part about enabling SNAT functionality. eth5 is my > > > cable modem... Suffice to say that iptables doesn't seem to like that > > > one... (invalid arguments) > > > > > > Any ideas on how to fix that command to make NAT work? > > > > > > Also... the /var/lib/iptables/rules-save... is it safe to manually > > > edit that? And how exactly does that work? Is that just a last state > > > file? So if I get it working right once I don't need to fiddle with > > > that? Basically, I'm wondering if I get the one NIC to do NAT properly > > > if I should just set up all the other NICs manually or whether it > > > would be quicker to copy the commands in the rules-save file. > > > > i think i saw a post with a similar problem as yours. it was suggested > > that you need to emerge iptables again. > > > > it worked for me. > > I have serious iptables problems of my own. I have recompiled my kernel > and copied it to /boot serveral times, rebooting the comp after first > rerunning lilo each time. I have also emerged ip_tables several times, > however this is what i get when i try to modprobe ip_tables: > > # modprobe ip_tables > /lib/modules/2.4.20-ck4/kernel/net/ipv4/netfilter/ip_tables.o: > unresolved symbol > nf_unregister_sockopt > /lib/modules/2.4.20-ck4/kernel/net/ipv4/netfilter/ip_tables.o: > unresolved symbol > nf_register_sockopt > /lib/modules/2.4.20-ck4/kernel/net/ipv4/netfilter/ip_tables.o: insmod > /lib/modul > es/2.4.20-ck4/kernel/net/ipv4/netfilter/ip_tables.o failed > /lib/modules/2.4.20-ck4/kernel/net/ipv4/netfilter/ip_tables.o: insmod > ip_tables > failed > > Im thinking of just deleting my entire kernel sources and trying another > kernel, but ive used this kernel before on this system and it has always > seemed rock steady until now. Im using a downloaded version of vanilla > which I have patched myself with Con Konval's standard patchset.
First of all, I had to correct _several_ layers of top-posting, which made this thread almost impossible to follow. This thread stands out as a poster child of why top posting is a really bad idea. Anyway, rants aside, the first thing that you want to do if you're using iptables is to go into your kernel config and under Loadable Module Support, make sure you *disable* set version information on all modules. I'm not sure why this is an issue, but there was some kernel thread way back in the day (you can probably find it through google) that this option breaks iptables sometimes. Next, you want to re-emerge iptables after you recompile your kernel. Iptables uses some stuff in /usr/src/linux (oh yeah, make sure that symlink is pointing to your current kernel) so every time you modify something in your kernel reflecting areas it might touch (netfilter configs and whatnot) or you install a new kernel, you have to do this. Let me know if you still have issues after trying this. P.S. Let's please try to keep this list readable. Long threads are really, really hard to follow when everyone's top posting and when attributions are missing. -- /* * Bob Phan <[EMAIL PROTECTED],[EMAIL PROTECTED]> * Computational Chemistry Informatics * Neurogen Corporation * (203)488-8201 x4645 * * To understand recursion, you must first understand recursion. * http://www.endlessrecursion.net/ */ -- [EMAIL PROTECTED] mailing list
