ip_conntrack cleanup on reconnection?

ip_conntrack cleanup on reconnection?

[Daimonion]

Hi!

I have a with my DSL uplink reconnects (ppp restart) for kernels with  
higher versions than 2.4.23.
I am using Teamspeak (TS) connected to a public server.
With 2.4.23 I can restart the ppp-connection and my TS-client still keeps  
connected with the TS-server, which
I appreciate. But eversince 2.4.25 or 2.6.x a ppp reconnect disconnects  
the TS-client and I have to reconnect
manually.
Additionally, if I played a game (Enemy Territory) while getting  
disconnected, I can?t reconnect to that
server anymore for a while. It seems like an entry in ip_conntrack  
prevents me from reconnecting (UDP) until
it has timed out.

Any suggestions, or ideas on this one?

Having a look at net/ip_MASQUARDE.c the ip_conntrack list should be empty  
after a device was down (cleanup?), but
the list still is full of entries.
Shouldnt the list be empty or, at least rewritten with the new  
ip-addresses?

Regards,
Richard

Re: ip_conntrack cleanup on reconnection?

[Herve Eychenne]

On Mon, Jul 05, 2004 at 03:20:28PM +0200, Daimonion wrote:

 Hi,

> Having a look at net/ip_MASQUARDE.c the ip_conntrack list should be empty  
> after a device was down (cleanup?), but
> the list still is full of entries.
> Shouldnt the list be empty or, at least rewritten with the new  
> ip-addresses?

Yes, it should. During the last netfilter workshop, after one of my remarks,
Rusty Russell wrote a patch to the MASQUERADE target which cleans the tables
only if the address changes (before, they were cleaned
unconditionnaly).
I don't know when the patch was applied upstream in 2.4 or if it's related
to your problem...

 Herve

-- 
 _
(°=  Hervé Eychenne
//)
v_/_ WallFire project:  http://www.wallfire.org/

Re: ip_conntrack cleanup on reconnection?

[Pablo Neira]

Hi Herve,

Herve Eychenne wrote:

>>Having a look at net/ip_MASQUARDE.c the ip_conntrack list should be empty  
>>after a device was down (cleanup?), but
>>the list still is full of entries.
>>Shouldnt the list be empty or, at least rewritten with the new  
>>ip-addresses?
>>    
>>
>
>Yes, it should. During the last netfilter workshop, after one of my remarks,
>Rusty Russell wrote a patch to the MASQUERADE target which cleans the tables
>only if the address changes (before, they were cleaned
>unconditionnaly).
>I don't know when the patch was applied upstream in 2.4 or if it's related
>to your problem...
>  
>

If I think that I observed a similar behaviour in 2.6, but using 
DNAT/SNAT targets instead of MASQUERADE. Well, actually I'm not sure if 
this exactly what you mean.

root@legba:/home/pablo# iptables -I POSTROUTING -t nat -j SNAT --to 
192.168.30.30
root@legba:/home/pablo# telnet 192.168.0.44 80
Trying 192.168.0.44... ^c
root@legba:/home/pablo# cat /proc/net/ip_conntrack
tcp      6 114 SYN_SENT src=192.168.0.3 dst=192.168.0.44 sport=32779 
dport=80 [UNREPLIED] src=192.168.0.44 dst=192.168.30.30 sport=80 
dport=32779 use=1
                                          ^^^

root@legba:/home/pablo# iptables -D POSTROUTING -t nat -j SNAT --to 
192.168.30.30
root@legba:/home/pablo# cat /proc/net/ip_conntrack
tcp      6 108 SYN_SENT src=192.168.0.3 dst=192.168.0.44 sport=32779 
dport=80 [UNREPLIED] src=192.168.0.44 dst=192.168.30.30 sport=80 
dport=32779 use=1
                                          ^^^

root@legba:/home/pablo# telnet 192.168.0.44 80
Trying 192.168.0.44...
root@legba:/home/pablo# cat /proc/net/ip_conntrack
tcp      6 2 SYN_SENT src=192.168.0.3 dst=192.168.0.44 sport=32779 
dport=80 [UNREPLIED] src=192.168.0.44 dst=192.168.30.30 sport=80 
dport=32779 use=1
                                       ^^^
tcp      6 106 SYN_SENT src=192.168.0.3 dst=192.168.0.44 sport=32780 
dport=80 [UNREPLIED] src=192.168.0.44 dst=192.168.0.3 sport=80 
dport=32780 use=1
                                        ^^^

I'll have a look at this issue (just for fun (tm)), I'll also look for 
that Rusty's patch if someone doesn't post it to the list before. This 
could generate a lot of established (for tcp) entries with a long 
timeout but, it's also true that I don't usually remove NAT rules once 
the box is configured.

regards,
Pablo

Re: ip_conntrack cleanup on reconnection?

[Henrik Nordstrom]

On Sat, 10 Jul 2004, Pablo Neira wrote:

> If I think that I observed a similar behaviour in 2.6, but using 
> DNAT/SNAT targets instead of MASQUERADE. Well, actually I'm not sure if 
> this exactly what you mean.

Only MASQUERADE cleans entries on interface change. DNAT/SNAT assumes 
static networking.

> root@legba:/home/pablo# iptables -I POSTROUTING -t nat -j SNAT --to 
> 192.168.30.30
> root@legba:/home/pablo# telnet 192.168.0.44 80
> Trying 192.168.0.44... ^c
> root@legba:/home/pablo# cat /proc/net/ip_conntrack
> tcp      6 114 SYN_SENT src=192.168.0.3 dst=192.168.0.44 sport=32779 
> dport=80 [UNREPLIED] src=192.168.0.44 dst=192.168.30.30 sport=80 
> dport=32779 use=1
>                                           ^^^
> 
> root@legba:/home/pablo# iptables -D POSTROUTING -t nat -j SNAT --to 
> 192.168.30.30
> 
> root@legba:/home/pablo# telnet 192.168.0.44 80
> Trying 192.168.0.44...
> root@legba:/home/pablo# cat /proc/net/ip_conntrack
> tcp      6 2 SYN_SENT src=192.168.0.3 dst=192.168.0.44 sport=32779 
> dport=80 [UNREPLIED] src=192.168.0.44 dst=192.168.30.30 sport=80 
> dport=32779 use=1

This is the old entry created in your first attempt..

> tcp      6 106 SYN_SENT src=192.168.0.3 dst=192.168.0.44 sport=32780 
> dport=80 [UNREPLIED] src=192.168.0.44 dst=192.168.0.3 sport=80 
> dport=32780 use=1

And this is the new.



This is 100% how it should be.  Alreaty set up NAT sessions should not go 
away only because you delete thre NAT rule, but there won't be any new NAT 
sessions after the rule is deleted.

Regards
Henrik