netfilter digest, Vol 1 #1202 - 12 msgs
Fri, 19 Oct 2001 14:55:11 +0530 (IST)
> Message: 7
> Date: Wed, 17 Oct 2001 23:44:56 +0100 (BST)
> From: root <email@example.com>
> To: <firstname.lastname@example.org>
> Subject: iptbales, NAT, and 'sendto: Operation not permitted'
> First off, I'm a bit of a newbie to this all - I've only been *nixing for
> about four months and so there's still a huuuuge amount I don't even know
> about. But after coming across a problem and searching around for a
> solution but failing to find one, I thought I'd post my workaround just in
> case I hadn't missed the solution.
> After upgrading to iptables 1.2.2 and kernel 2.4.9 over a month ago, i
> noticed that my nmap, ping, traceroute, samba, etc etc were broken, and
> whenever I tried to use them #I was greeted by the infamous 'sendto:
> operation not permitted'. At the time I had just run the Bastille security
> script and presumed that this was an issue with suid bits and nothing to
> do with NAT. I use my linux box to do nat for my internal network, along
> with ating as a file server.
How you have upgraded the iptables using rpm or tar.gz format.
Ofcourse if you are using Kernel 2.4.9 what are the options you have
selected while configuring the kernel. Without this I think whatever I
suggest may not work.
The error which you are getting has blocked the things( means the
default policies). Thats why you are not able to get any ino other than
What I can suggest you is log all the packets keeping the default
policies DROP and allow those packets which has been logged after running
the namp or traceroute. This is the best way to configure the firewall if
you dont know what to do further.
And I am working with kernel version 2.4.10 and having no
problems. Everything is working fine and it should work for you also.
> Anyway, whilst searching through archives and documentation and finding
> that although other people had come across this problem but not found a
> solution, i decided to have a play, and discovered that by setting the
> default policy of the postrouting chain in the nat table to ACCEPT as
> opposed to DROP as it previously was, magically my nmap, samba, ping and
> traceroute are all working again (with an exception in the case where the
> target is the local machine - wither throught loopback or other
> I know it's weak and only a workaround at best, but I'm confident that my
> input and output chains are going to block the vast majority of any
> malicious traffic headed towards the postrouting chain, and my internal
> network is comprised of trusted hosts anyway; imho it's a small price to
> pay for the use of ping!
> Anyway.. sorry if this is an old bug or a known fix or anything, but I
> thought I'd post anyway just in case.
nSecure Software(P) Ltd.