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. 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? > > in answer to the question you commented in there, YES it will ..your > > policy on input is DROP -- thus you are getting out, but nothing is > > getting BACK to you. > > makes perfect sense. > > Kev.
