How to debug RST filter ?

How to debug RST filter ?

[Andre Schild]

Hello,

we are using Debian 2.6.26-2-amd64 with a database server listening on 
tcp port 2638.
Usually everything works just fine, but sometimes we get connection 
errors on the server, and then, each time we see firewall entries like 
this in the syslog:


Feb  1 07:41:26 sv16 kernel: [34944777.631090] RULE 17 -- DENY IN= 
OUT=lo SRC=188.myip DST=188.myip LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID
=0 DF PROTO=TCP SPT=41562 DPT=2638 SEQ=1506091366 ACK=0 WINDOW=0 
RES=0x00 RST URGP=0
Feb  1 07:41:29 sv16 kernel: [34944786.286850] RULE 17 -- DENY IN= 
OUT=lo SRC=188.myip DST=188.myip LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID
=0 DF PROTO=TCP SPT=41562 DPT=2638 SEQ=1506091366 ACK=0 WINDOW=0 
RES=0x00 RST URGP=0

In the firewal we even have a rule which allows everything in/out on the 
lo interface.

It looks like there are some timeouts or state filters which do not work 
as intended by us.

Any ideas how I can debug this ?
I can't trace all the traffic on the lo interface, because there is 
quite heavy load/traffic
on that interface.

André

Re: How to debug RST filter ?

[Remzi AKYÜZ]

Hello,

Can you see "RULE 17"?

Andre Schild wrote:
> Hello,
>
> we are using Debian 2.6.26-2-amd64 with a database server listening on 
> tcp port 2638.
> Usually everything works just fine, but sometimes we get connection 
> errors on the server, and then, each time we see firewall entries like 
> this in the syslog:
>
>
> Feb  1 07:41:26 sv16 kernel: [34944777.631090] RULE 17 -- DENY IN= 
> OUT=lo SRC=188.myip DST=188.myip LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID
> =0 DF PROTO=TCP SPT=41562 DPT=2638 SEQ=1506091366 ACK=0 WINDOW=0 
> RES=0x00 RST URGP=0
> Feb  1 07:41:29 sv16 kernel: [34944786.286850] RULE 17 -- DENY IN= 
> OUT=lo SRC=188.myip DST=188.myip LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID
> =0 DF PROTO=TCP SPT=41562 DPT=2638 SEQ=1506091366 ACK=0 WINDOW=0 
> RES=0x00 RST URGP=0
>
> In the firewal we even have a rule which allows everything in/out on the 
> lo interface.
>
> It looks like there are some timeouts or state filters which do not work 
> as intended by us.
>
> Any ideas how I can debug this ?
> I can't trace all the traffic on the lo interface, because there is 
> quite heavy load/traffic
> on that interface.
>
> André
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

RE: Re: How to debug RST filter ?

[a.schild]

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

Hello,

> Can you see "RULE 17"?


Rule 17 is the final deny everything else rule.
Rule 15 is the one which should allow everything "local" on the firewall

#
# Rule 15 (global)
#
echo "Rule 15 (global)"
#
#
#
$IPTABLES -N Cid4A4A84F123430.0
$IPTABLES -A INPUT  -s myip   -m state --state NEW  -j Cid4A4A84F123430.0
$IPTABLES -A INPUT  -s 127.0.0.1   -m state --state NEW  -j
Cid4A4A84F123430.0
$IPTABLES -A Cid4A4A84F123430.0  -d myip   -j ACCEPT
$IPTABLES -A Cid4A4A84F123430.0  -d 127.0.0.1   -j ACCEPT
$IPTABLES -N Cid4A4A84F123430.1
$IPTABLES -A OUTPUT  -s myip    -m state --state NEW  -j Cid4A4A84F123430.1
$IPTABLES -A OUTPUT  -s 127.0.0.1   -m state --state NEW  -j
Cid4A4A84F123430.1
$IPTABLES -A Cid4A4A84F123430.1  -d myip   -j ACCEPT
$IPTABLES -A Cid4A4A84F123430.1  -d 127.0.0.1   -j ACCEPT



#
# Rule 17 (global)
#
echo "Rule 17 (global)"
#
#
#
$IPTABLES -N RULE_17
$IPTABLES -A OUTPUT  -j RULE_17
$IPTABLES -A INPUT  -j RULE_17
$IPTABLES -A RULE_17  -j LOG  --log-level info --log-prefix "RULE 17 -- DENY
" --log-tcp-sequence  --log-tcp-options  --log-ip-options
$IPTABLES -A RULE_17  -j DROP


As we normaly can connect, but just a few random connection don't work,
I assume that there is some timeout or some entries flushed somewhere in
the filter stuff.


André


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4444 bytes --]

Re: How to debug RST filter ?

[Mart Frauenlob]

On 01.02.2010 09:13, netfilter-owner@vger.kernel.org wrote:
> Hello,
> 
>> Can you see "RULE 17"?
> 
> 
> Rule 17 is the final deny everything else rule.
> Rule 15 is the one which should allow everything "local" on the firewall
> 
> #
> # Rule 15 (global)
> #
> echo "Rule 15 (global)"
> #
> #
> #
> $IPTABLES -N Cid4A4A84F123430.0
> $IPTABLES -A INPUT  -s myip   -m state --state NEW  -j Cid4A4A84F123430.0
> $IPTABLES -A INPUT  -s 127.0.0.1   -m state --state NEW  -j
> Cid4A4A84F123430.0
> $IPTABLES -A Cid4A4A84F123430.0  -d myip   -j ACCEPT
> $IPTABLES -A Cid4A4A84F123430.0  -d 127.0.0.1   -j ACCEPT
> $IPTABLES -N Cid4A4A84F123430.1
> $IPTABLES -A OUTPUT  -s myip    -m state --state NEW  -j Cid4A4A84F123430.1
> $IPTABLES -A OUTPUT  -s 127.0.0.1   -m state --state NEW  -j
> Cid4A4A84F123430.1
> $IPTABLES -A Cid4A4A84F123430.1  -d myip   -j ACCEPT
> $IPTABLES -A Cid4A4A84F123430.1  -d 127.0.0.1   -j ACCEPT
> 
> 
> 
> #
> # Rule 17 (global)
> #
> echo "Rule 17 (global)"
> #
> #
> #
> $IPTABLES -N RULE_17
> $IPTABLES -A OUTPUT  -j RULE_17
> $IPTABLES -A INPUT  -j RULE_17
> $IPTABLES -A RULE_17  -j LOG  --log-level info --log-prefix "RULE 17 -- DENY
> " --log-tcp-sequence  --log-tcp-options  --log-ip-options
> $IPTABLES -A RULE_17  -j DROP
> 
> 
> As we normaly can connect, but just a few random connection don't work,
> I assume that there is some timeout or some entries flushed somewhere in
> the filter stuff.
> 
> 
> André

shot in the dark, try to insert into rule 17:
$IPTABLES -I RULE_17 -o lo -m state --state INVALID -j LOG \
--log-level info --log-prefix "RULE 17 -- INVALID" --log-tcp-sequence \
--log-tcp-options --log-ip-options

and see if it matches the other logged packets.
if so, these packets are classified as invalid by the connection tracker.

best regards


Mart

Re: How to debug RST filter ?

[Pascal Hambourg]

Hello,

a.schild@aarboard.ch a écrit :
> 
> Rule 15 is the one which should allow everything "local" on the firewall
> 
> #
> # Rule 15 (global)
> #
> echo "Rule 15 (global)"
> #
> #
> #
> $IPTABLES -N Cid4A4A84F123430.0
> $IPTABLES -A INPUT  -s myip   -m state --state NEW  -j Cid4A4A84F123430.0
> $IPTABLES -A INPUT  -s 127.0.0.1   -m state --state NEW  -j Cid4A4A84F123430.0
> $IPTABLES -A Cid4A4A84F123430.0  -d myip   -j ACCEPT
> $IPTABLES -A Cid4A4A84F123430.0  -d 127.0.0.1   -j ACCEPT
> $IPTABLES -N Cid4A4A84F123430.1
> $IPTABLES -A OUTPUT  -s myip    -m state --state NEW  -j Cid4A4A84F123430.1
> $IPTABLES -A OUTPUT  -s 127.0.0.1   -m state --state NEW  -j Cid4A4A84F123430.1
> $IPTABLES -A Cid4A4A84F123430.1  -d myip   -j ACCEPT
> $IPTABLES -A Cid4A4A84F123430.1  -d 127.0.0.1   -j ACCEPT

I do not see here "a rule which allows everything in/out on the
lo interface". Such rules would be :

iptables -A INPUT -i lo -j ACCCEPT
iptables -A OUTPUT -o lo -j ACCCEPT

Instead, your rules accept only packets in the NEW state (RST packets
are never in that state) whose source and destination addresses are
"myip" or 127.0.0.1 (not only 127.0.0.1 but also the whole 127.0.0.0/8
range may be used on the loopback interface).

RE: Re: How to debug RST filter ?

[Andre Schild]

Hello Pascal,

> > Rule 15 is the one which should allow everything "local" on the
> firewall
> >
> > #
> > # Rule 15 (global)
> > #
> > echo "Rule 15 (global)"
> > #
> > #
> > #
> > $IPTABLES -N Cid4A4A84F123430.0
> > $IPTABLES -A INPUT  -s myip   -m state --state NEW  -j
> Cid4A4A84F123430.0
> > $IPTABLES -A INPUT  -s 127.0.0.1   -m state --state NEW  -j
> Cid4A4A84F123430.0
> > $IPTABLES -A Cid4A4A84F123430.0  -d myip   -j ACCEPT
> > $IPTABLES -A Cid4A4A84F123430.0  -d 127.0.0.1   -j ACCEPT
> > $IPTABLES -N Cid4A4A84F123430.1
> > $IPTABLES -A OUTPUT  -s myip    -m state --state NEW  -j
> Cid4A4A84F123430.1
> > $IPTABLES -A OUTPUT  -s 127.0.0.1   -m state --state NEW  -j
> Cid4A4A84F123430.1
> > $IPTABLES -A Cid4A4A84F123430.1  -d myip   -j ACCEPT
> > $IPTABLES -A Cid4A4A84F123430.1  -d 127.0.0.1   -j ACCEPT
> 
> I do not see here "a rule which allows everything in/out on the
> lo interface". Such rules would be :
> 
> iptables -A INPUT -i lo -j ACCCEPT
> iptables -A OUTPUT -o lo -j ACCCEPT
> 
> Instead, your rules accept only packets in the NEW state (RST packets
> are never in that state) whose source and destination addresses are
> "myip" or 127.0.0.1 (not only 127.0.0.1 but also the whole 127.0.0.0/8
> range may be used on the loopback interface).

Ok,

I see what you mean, is the RST not (one of) the last packet when a 
connection
is closed/dropped ?



André

RE: RE: Re: How to debug RST filter ?

[a.schild]

[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]

Hello Pascal,

> > > $IPTABLES -N Cid4A4A84F123430.0
> > > $IPTABLES -A INPUT  -s myip   -m state --state NEW  -j
> > Cid4A4A84F123430.0
> > > $IPTABLES -A INPUT  -s 127.0.0.1   -m state --state NEW  -j
> > Cid4A4A84F123430.0
> > > $IPTABLES -A Cid4A4A84F123430.0  -d myip   -j ACCEPT
> > > $IPTABLES -A Cid4A4A84F123430.0  -d 127.0.0.1   -j ACCEPT
> > > $IPTABLES -N Cid4A4A84F123430.1
> > > $IPTABLES -A OUTPUT  -s myip    -m state --state NEW  -j
> > Cid4A4A84F123430.1
> > > $IPTABLES -A OUTPUT  -s 127.0.0.1   -m state --state NEW  -j
> > Cid4A4A84F123430.1
> > > $IPTABLES -A Cid4A4A84F123430.1  -d myip   -j ACCEPT
> > > $IPTABLES -A Cid4A4A84F123430.1  -d 127.0.0.1   -j ACCEPT
> >
> > I do not see here "a rule which allows everything in/out on the
> > lo interface". Such rules would be :
> >
> > iptables -A INPUT -i lo -j ACCCEPT
> > iptables -A OUTPUT -o lo -j ACCCEPT
> >
> > Instead, your rules accept only packets in the NEW state (RST packets
> > are never in that state) whose source and destination addresses are
> > "myip" or 127.0.0.1 (not only 127.0.0.1 but also the whole
> 127.0.0.0/8
> > range may be used on the loopback interface).
> 
> Ok,
> 
> I see what you mean, is the RST not (one of) the last packet when a
> connection
> is closed/dropped ?


I had a rule as #1 in the chain with:

$IPTABLES -A INPUT  -i lo   -m state --state NEW  -j ACCEPT
$IPTABLES -A OUTPUT  -o lo   -m state --state NEW  -j ACCEPT

So I assume here also the --state NEW is causing the RTS not be matched,
even it was related to some established connection...

André


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4444 bytes --]

Regarding Iptables Redirect Target rule

[Vikram Ragukumar]

Hello,

Interface 1                  Interface 2
9090(encrypted)  ---------  9000(decrypted)
   ------>-------|Fire wall|--->-----
   ------>-------|         |--->-----
9000(unencrypted)--------- 9000(unencrypted)

I need to encrypt/decrypt and port translate traffic coming in on a 
particular port (9090).

I first perform decryption by queuing packets to a userspace program 
with the following iptables rule
(a) iptables -t mangle -A PREROUTING -p udp --dport 9090 -j NFQUEUE

To achieve port translation i use the REDIRECT target as shown below
(b) iptables -t nat -A PREROUTING -p udp --dport 9090 -j REDIRECT 
--to-port 9000

The iptables rule with the REDIRECT target ensures that traffic on port 
9000 on Interface 2 gets port translated to port 9090 while going out 
through Interface 1, only if they belong to a connection that was port 
translated from 9090 to 9000 while coming in on Interface 1.

I would like to know how to construct a rule to intercept packets that 
belong to the port translated stream, but now are coming from Interface 
2 and would like to encrypt them before they go out on Interface 1 ? 
There are other connections that use port 9000, however these do not 
belong to the port translated stream.

Will the following rule work ?

iptables -t mangle -A POSTROUTING -p udp --sport 9090 -j NFQUEUE
i.e. Will REDIRECT, ensure that the source port is rewritten from 9000 
to 9090 by the time the packet hits mangle POSTROUTING ?

Thanks in advance,
Vikram.

Re: Regarding Iptables Redirect Target rule

[Pascal Hambourg]

Hello,

Please don't reply to an existing thread when posting a new topic.

Vikram Ragukumar a écrit :
> 
> I would like to know how to construct a rule to intercept packets that 
> belong to the port translated stream, but now are coming from Interface 
> 2 and would like to encrypt them before they go out on Interface 1 ? 

I guess that connmark+CONNMARK would do the job.