Linux Netfilter discussions
 help / color / mirror / Atom feed
* Deleting Connection Tracking information
@ 2002-07-08 12:31 Tsachi Sharfman
  0 siblings, 0 replies; 3+ messages in thread
From: Tsachi Sharfman @ 2002-07-08 12:31 UTC (permalink / raw)
  To: netfilter, netfilter-devel

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

Hi,

 

I would like to add a NAT rule on a gateway while connections are passing through it, and have the rule apply to existing connections. I understand this is not the behavior when the rule is simply added to the NAT table, since netfilter consults the NAT table only for the first packet of the connection. I assume that if I can delete connection tracking information on the gateway, once a packet belonging to an existing connection passes through the gateway netfilter will regard it as a new connection (since there is no connection tracking information for it), and apply the new NAT rules that existing connection. My questions are:

 

1.	Is my assumption correct?
2.	Is the answer to the first question is yes, how can I delete connection tracking information?

 

Thanks,

Tsachi Sharfman.


[-- Attachment #2: Type: text/html, Size: 2769 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Deleting Connection Tracking information
       [not found]   ` <20020708233153.GB30970@aaricia.hemmet.chalmers.se>
@ 2002-07-08 23:50     ` Antony Stone
  2002-07-09  0:44       ` Ramin Alidousti
  0 siblings, 1 reply; 3+ messages in thread
From: Antony Stone @ 2002-07-08 23:50 UTC (permalink / raw)
  To: netfilter

On Tuesday 09 July 2002 12:31 am, Joakim Axelsson wrote:

> 2002-07-08 12:43:01+0100, Antony Stone <Antony@Soft-Solutions.co.uk> ->
>
> > If you are talking about TCP, then I do not believe this assumption is
> > valid, because only the very first packet of a connection contains the
> > SYN flag, and only the second packet contains the SYN/ACK, which are the
> > first two steps of the TCP three-way handshake.   Without those the
> > connection tracking system won't set up an ESTABLISHED connection, and
> > the automatic NAT rules won't apply.
>
> That is not true. I suggest reading some old mails in the archive and
> documents. Conntrack's state of NEW is NOT the same things as a TCP with
> SYN-flag. The FIRST packet is sees in a flow is marked state NEW.

Okay, let's think about this a little further...

Suppose I have two netfilter boxes sitting side by side with identical rules 
on them, including NAT, identical addresses on the interfaces (suppose for 
the time being I've arranged to have identical MACs on the ethernet cards as 
well) and identical routing tables.

One box is plugged into my network, client on one side, server on the other - 
the other netfilter box is switched on but disconnected from the network.

After a bit of traffic has flowed, the netfilter box has some conntracking 
table entries, and the client and server have an established connection (or 
maybe several).

Suddenly I decide to pull out the network cables from netfilter box 1 and 
connect them to netfilter box 2 instead.

Are you saying that the first packet to flow between the client and server 
through this second netfilter machine, which has no connection tracking table 
on it yet, will cause a NEW entry to be placed in the connection tracking 
table, and that the reply packet will cause that entry to become ESTABLISHED, 
and that the NAT rules will work ?

Even though both of these packets are just mid-connection ACK packets with no 
SYN flags in them ?

If this is true, what stops us having high-availability automatic-failover 
netfilter machines ?

 

Antony.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Deleting Connection Tracking information
  2002-07-08 23:50     ` Antony Stone
@ 2002-07-09  0:44       ` Ramin Alidousti
  0 siblings, 0 replies; 3+ messages in thread
From: Ramin Alidousti @ 2002-07-09  0:44 UTC (permalink / raw)
  To: Antony Stone; +Cc: netfilter

On Tue, Jul 09, 2002 at 12:50:51AM +0100, Antony Stone wrote:

> > That is not true. I suggest reading some old mails in the archive and
> > documents. Conntrack's state of NEW is NOT the same things as a TCP with
> > SYN-flag. The FIRST packet is sees in a flow is marked state NEW.
> 
> Okay, let's think about this a little further...
> 
> Suppose I have two netfilter boxes sitting side by side with identical rules 
> on them, including NAT, identical addresses on the interfaces (suppose for 
> the time being I've arranged to have identical MACs on the ethernet cards as 
> well) and identical routing tables.
> 
> One box is plugged into my network, client on one side, server on the other - 
> the other netfilter box is switched on but disconnected from the network.

It doesn't have to. You can connect both and run vrrpd.

> 
> After a bit of traffic has flowed, the netfilter box has some conntracking 
> table entries, and the client and server have an established connection (or 
> maybe several).
> 
> Suddenly I decide to pull out the network cables from netfilter box 1 and 
> connect them to netfilter box 2 instead.
> 
> Are you saying that the first packet to flow between the client and server 
> through this second netfilter machine, which has no connection tracking table 
> on it yet, will cause a NEW entry to be placed in the connection tracking 
> table, and that the reply packet will cause that entry to become ESTABLISHED, 
> and that the NAT rules will work ?

Yes.

> 
> Even though both of these packets are just mid-connection ACK packets with no 
> SYN flags in them ?

Yes.

> 
> If this is true, what stops us having high-availability automatic-failover 
> netfilter machines ?

1) Just think about the case where the NEW packet arrives in the wrong
   direction.
2) What happens to the helper information gathered by the first one?
3) What happens to the information you had from many other modules like
   ipt_recent...
4) ...

Ramin

> 
>  
> 
> Antony.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-07-09  0:44 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-07-08 12:31 Deleting Connection Tracking information Tsachi Sharfman
     [not found] <AE696B0F5B44A348B8D18E40F976D9571BA92E@mailsrv.etagon.com>
     [not found] ` <200207081143.g68Bh6806571@vulcan.rissington.net>
     [not found]   ` <20020708233153.GB30970@aaricia.hemmet.chalmers.se>
2002-07-08 23:50     ` Antony Stone
2002-07-09  0:44       ` Ramin Alidousti

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox