OUTPUT ACCEPT, but can't see out

OUTPUT ACCEPT, but can't see out

[Kevin Mulcahy]

Hi All
I have a very simple set of rules, with default policy for INPUT being 
DROP and  default OUTPUT being ACCEPT.
However, I can't hit anything on the outside.  I can't ping, ssh - nothing.
When I flush everything I can see outside no problem.
My script is:

IPTABLES="/sbin/iptables"
INTERFACE="eth0"
SERVER="x.x.x.x"
SSHA1="y.y.y.y"
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P FORWARD DROP
$IPTABLES -A INPUT -i $INTERFACE -p tcp -s $SSHA1 -d $SERVER --dport 22 
-j ACCEPT
$IPTABLES -A INPUT -i $INTERFACE -p tcp -s $ALLIP -d $ALLIP --dport 80 
-j ACCEPT
$IPTABLES -A INPUT -i $INTERFACE -p tcp -s $ALLIP -d $ALLIP --dport 443 
-j ACCEPT
$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


Cheers
Kev.

Re: OUTPUT ACCEPT, but can't see out

[Unknown, Alistair Tonner]

On March 3, 2004 08:11 pm, Kevin Mulcahy wrote:
> Hi All
> I have a very simple set of rules, with default policy for INPUT being
> DROP and  default OUTPUT being ACCEPT.
> However, I can't hit anything on the outside.  I can't ping, ssh - nothing.
> When I flush everything I can see outside no problem.
> My script is:
>
> IPTABLES="/sbin/iptables"
> INTERFACE="eth0"
> SERVER="x.x.x.x"
> SSHA1="y.y.y.y"
> $IPTABLES -P INPUT DROP
> $IPTABLES -P OUTPUT ACCEPT
> $IPTABLES -P FORWARD DROP
> $IPTABLES -A INPUT -i $INTERFACE -p tcp -s $SSHA1 -d $SERVER --dport 22
> -j ACCEPT
> $IPTABLES -A INPUT -i $INTERFACE -p tcp -s $ALLIP -d $ALLIP --dport 80
> -j ACCEPT
> $IPTABLES -A INPUT -i $INTERFACE -p tcp -s $ALLIP -d $ALLIP --dport 443
> -j ACCEPT
> $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.
	
	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.


	Alistair.
>
>
> Cheers
> Kev.

Re: OUTPUT ACCEPT, but can't see out

[Kevin Mulcahy]

>>$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?

> 	
> 	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.

Re: OUTPUT ACCEPT, but can't see out

[Unknown, Alistair Tonner]

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.

Re: OUTPUT ACCEPT, but can't see out

[Kevin Mulcahy]

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.

>