conntrack problems

conntrack problems

[Giovanni Cardone]

Hi, on a dial-up(56k) machine I'm looking at iptables 1.2.6a with both kernel
2.4.13 and 2.4.18. It's 1 months that I'm having troubles with the conntrack.
I have a lot of packets like 'new not syn'(you know what I'm talking about..)
with some combos of flags on them:

ACK FIN
ACK PSH FIN
ACK RST
ACK only

They come from connections with web servers like Google.com, 
SecurityFocus.com and so on and from news server like
Powernews.libero.it(Libero is one of the biggest provider in Italy). So, I
suspect that, because I've found only few cases like mine, those ones aren't 
broken at all :) 
I think the problem is in my conntrack that loss some(a lot...) of packets.
I've used some scripts for the iptables configuration, but it always happen.
then, I read about a patch from Rusty some month ago that increase one of the
timeouts in the kernel source(It was the TCP_CONNTRACK_CLOSE_WAIT timeout from
60 SECS to 2 MINS). I got it but nothing change. Then, I was thinking it could
be really a problem with timeouts, especially because this machine have a poor
dial-up access to the Net and it often goes sooo slow...
So I did this: I run tcpdump and capture some sessions that presents the loss
of packest trouble. Then I looked at those 'lossed packets' and I noticed that
the 'arrival time' of the losed packets had a distance with the one that
precede it(and that was traced correctly by iptables) of circa 12-14
SECS(never more than that). I mean:

arrival time 	type
............    traced packet
18.24.23.4456   traced packet
18.24.35.5678   losed packets
-------------
      12 secs

Then I looked into the kernel source for a timeout that match my(stupid)
thought. I've found TCP_CONNTRACK_CLOSE with 10 SECS, and I changed this to 2
MINS. Initially it seems(yep, <cite>I have a dream...</cite> :) to me that the 
losed packets decrements, but these days I receive costantly a lot of them.
With no other ideas, I've played a little with the timeouts, increasing them
like this 

5 MINS,     /*      TCP_CONNTRACK_CLOSE_WAIT	*/,
1 MINS,     /*      TCP_CONNTRACK_LAST_ACK, */

because I was thinking that maybe the 56k goes really slow some times but I
can't see good results :(
So I tried with this stupid methods, have you any advice at this? What it
could be? And then, I tried to add the tcp-window-tracking patch(the one in
iptables-1.2.6a) by Jozsef Kadlecsik on both 2.4.13 and 2.4.18 but it fails to
apply :( What version of iptables(maybe 1.2.7 ???) is known to work properly 
with 2.4.18 at this time? Maybe a new kernel? What I've to download?


Many thanks for your patience in advice

alternate tables and ipv6

[Gabriel Paues]

Hello!

I want to route IPv6 packages differenlty depending on what is in the flowlabel.
I've written a flowlabel match module which works flawlessly. I have done an
experiment with IPv4 and the TOS flag, where I routed IPv4 packages differently,
depending on what was in the TOS flag. I marked packages (fwmark) depending on
the TOS flag and set everything up like this:

iptables -A PREROUTING -i eth0 -t mangle -m tos --tos 0 -j MARK --set-mark 1
ip rule add fwmark 1 table host2.out
ip route add default via 192.168.2.3 dev eth2 table host2.out

where 192.168.2.3 is different from what is default gw in the main-table.

All is working fine in the IPv6 case except the last statement (slightly altered
for IPv6):

#ip -6 route add default via fec0::192.168.2.3 dev eth2 table host2.out
RTNETLINK answers: File exists

Is this approach incompatible with IPv6 in any way? Is there any problems with
using IPv6-addresses and the "table" object?

Sincerily,

Gabriel Paues

Re: alternate tables and ipv6

[Andras Kis-Szabo]

Hi,

> iptables -A PREROUTING -i eth0 -t mangle -m tos --tos 0 -j MARK --set-mark 1
> ip rule add fwmark 1 table host2.out
> ip route add default via 192.168.2.3 dev eth2 table host2.out
> 
> All is working fine in the IPv6 case except the last statement (slightly altered
> for IPv6):
> #ip -6 route add default via fec0::192.168.2.3 dev eth2 table host2.out
> RTNETLINK answers: File exists
> 
> Is this approach incompatible with IPv6 in any way? Is there any problems with
> using IPv6-addresses and the "table" object?
I think this is not a Netfilter-related question, but I try to answer.

The basic rtnetlink functions are supported in IPv6 too, but not all.
Configuration options for IPv4:
- TCP/IP networking
-   IP: multicasting
-     IP: advanced router
-       IP: policy routing
-         IP: use netfilter MARK value as routing key
With this You set the CONFIG_IP_ROUTE_FWMARK flag in the configuration.
This flag is interperted in the IPv4 code, but its whole function is
missing from the IPv6 code.

The related files and structures:
/usr/src/linux/net/ipv4/devinet.c
static struct rtnetlink_link inet_rtnetlink_table[RTM_MAX-RTM_BASE+1]
/usr/src/linux/net/ipv6/addrconf.c
static struct rtnetlink_link inet6_rtnetlink_table[RTM_MAX-RTM_BASE+1]
And severeal other functions and structures in the routing code.

When you try to add a rule with a 'table' object, the 'ip' command -
maybe - simply discards the 'table' tag.

Regards,

	kisza
 
-- 
    Andras Kis-Szabo       Security Development, Design and Audit
-------------------------/        Zorp, NetFilter and IPv6
 kisza@SecurityAudit.hu /-----Member of the BUTE-MIS-SEARCHlab------>

Re: alternate tables and ipv6

[Gabriel Paues]

I guess I have to implement it myself, then...

Be back when I have, with a patch!

Sincerily,
Gabriel

Andras Kis-Szabo wrote:

> Hi,
>
> > iptables -A PREROUTING -i eth0 -t mangle -m tos --tos 0 -j MARK --set-mark 1
> > ip rule add fwmark 1 table host2.out
> > ip route add default via 192.168.2.3 dev eth2 table host2.out
> >
> > All is working fine in the IPv6 case except the last statement (slightly altered
> > for IPv6):
> > #ip -6 route add default via fec0::192.168.2.3 dev eth2 table host2.out
> > RTNETLINK answers: File exists
> >
> > Is this approach incompatible with IPv6 in any way? Is there any problems with
> > using IPv6-addresses and the "table" object?
> I think this is not a Netfilter-related question, but I try to answer.
>
> The basic rtnetlink functions are supported in IPv6 too, but not all.
> Configuration options for IPv4:
> - TCP/IP networking
> -   IP: multicasting
> -     IP: advanced router
> -       IP: policy routing
> -         IP: use netfilter MARK value as routing key
> With this You set the CONFIG_IP_ROUTE_FWMARK flag in the configuration.
> This flag is interperted in the IPv4 code, but its whole function is
> missing from the IPv6 code.
>
> The related files and structures:
> /usr/src/linux/net/ipv4/devinet.c
> static struct rtnetlink_link inet_rtnetlink_table[RTM_MAX-RTM_BASE+1]
> /usr/src/linux/net/ipv6/addrconf.c
> static struct rtnetlink_link inet6_rtnetlink_table[RTM_MAX-RTM_BASE+1]
> And severeal other functions and structures in the routing code.
>
> When you try to add a rule with a 'table' object, the 'ip' command -
> maybe - simply discards the 'table' tag.
>
> Regards,
>
>         kisza
>
> --
>     Andras Kis-Szabo       Security Development, Design and Audit
> -------------------------/        Zorp, NetFilter and IPv6
>  kisza@SecurityAudit.hu /-----Member of the BUTE-MIS-SEARCHlab------>

Re: conntrack problems

[Nick Drage]

On Tue, Jun 04, 2002 at 12:24:34PM +0200, Giovanni Cardone wrote:
> Hi, on a dial-up(56k) machine I'm looking at iptables 1.2.6a with both kernel
> 2.4.13 and 2.4.18. It's 1 months that I'm having troubles with the conntrack.
> I have a lot of packets like 'new not syn'(you know what I'm talking about..)
> with some combos of flags on them:
> 
> ACK FIN
> ACK PSH FIN
> ACK RST
> ACK only

<snip>

> Then I looked into the kernel source for a timeout that match my(stupid)
> thought. I've found TCP_CONNTRACK_CLOSE with 10 SECS, and I changed this
> to 2 MINS. Initially it seems(yep, <cite>I have a dream...</cite> :) to me
> that the losed packets decrements, but these days I receive costantly a
> lot of them. With no other ideas, I've played a little with the timeouts,
> increasing them like this
> 
> 5 MINS,     /*      TCP_CONNTRACK_CLOSE_WAIT	*/,
> 1 MINS,     /*      TCP_CONNTRACK_LAST_ACK, */
> 
> because I was thinking that maybe the 56k goes really slow some times but
> I can't see good results :(
> So I tried with this stupid methods, have you any advice at this? What it
> could be? And then, I tried to add the tcp-window-tracking patch(the one
> in iptables-1.2.6a) by Jozsef Kadlecsik on both 2.4.13 and 2.4.18 but it
> fails to apply :( What version of iptables(maybe 1.2.7 ???) is known to
> work properly with 2.4.18 at this time? Maybe a new kernel? What I've to
> download?

Hi.  Sorry, I don't have much to add, except to reassure you that I've seen
similar in my logs.  I hope you will keep the mailing list informed on any
progress you make, I hope I can add to your research at some point.

-- 
FunkyJesus System Administration Team

Re: conntrack problems

[Tom Eastep]

On Wed, 5 Jun 2002, Nick Drage wrote:

> > It's 1 months that I'm having troubles with the conntrack. I have a
> > lot of packets like 'new not syn'(you know what I'm talking about..)
> > with some combos of flags on them:
> > 
> > ACK FIN
> > ACK PSH FIN
> > ACK RST
> > ACK only
> 
> Hi.  Sorry, I don't have much to add, except to reassure you that I've seen
> similar in my logs.  I hope you will keep the mailing list informed on any
> progress you make, I hope I can add to your research at some point.
> 

Since day one, Shorewall has included the following rule:

  457 67312 ACCEPT     tcp  --  *      *       0.0.0.0/0            
0.0.0.0/0          tcp flags:0x10/0x10

As you can see, I get a fair number packets with the ACK flag that aren't 
picked up by an earlier ESTABLISHED,RELATED rule. After experimenting with 
various strategies (DROP, REJECT --reject-with tcp-reset), I settled on 
ACCEPT as it seemed to have the fewest side effects. 

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
AIM: tmeastep  \ http://www.shorewall.net
ICQ: #60745924  \ teastep@shorewall.net