On 05/03/2004, at 12:03 AM, Alistair Tonner wrote:
On March 3, 2004 09:06 pm, Kevin Mulcahy wrote:$IPTABLES -A INPUT -i $INTERFACE -p ALL -m state --state ESTABLISHED,RELATED -j ACCEPT #Note - this appears to generate an error # iptables: No chain/target/match by that name # but would that affect OUTPUT ??? $IPTABLES -A INPUT -i $INTERFACE -p ALL -j RETURN
$IPTABLES -A OUTPUT -o $INTERFACE -p ALL -j ACCEPT
Remove the -p ALL from your established related line. dont put one it ...covers all.
Done. But I still get the error.
I've read that loading in the appropriate module will solve this, but
unfortunately my hosting company has built their own monolithic kernels
which don't support loadable modules.
Is there any way around this?
Uck.
state matching is the heart and soul of connection tracking.
it strikes me as weird that it isn't included. ipt_state
and ip_conntrack are the symbol names that should be
found in the kernel (grep System.map and /proc/kysms or /proc/kallsyms)
if not found you are going to have to explicitly allow connections by port
which just plain .... is awful.
grep on ipt_state and ip_conntrack turned up nothing in System.map. neither /proc/kysms nor /proc/kallsyms exist!
One other thing that can cause this issue is if the kernel version that the
userspace application was built against does not match the running kernel.
the resolution is to rebuilt the userspace application against the current kernel.
What kernel version and iptables version are you working with?
iptables v1.2.5 kernel 2.4.24 #1 SMP
Kev.
