Re: How to create a "persistent" expectation with newnat?

[netfilter@interlinx.bc.ca]

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

On Thu, Feb 27, 2003 at 09:53:45AM +1100, Ian Latter wrote:
> 
> ahhh .. Brian ;-)  Didn't see your sig b4 ...

S'ok.  It was funny.

> Instead of relying on outgoing connections to maintain the live session,
> leave that out for the time being, and set up an untimed inbound expectation.

But unless I am mistaken, inbound expectations have to be related to
an ESTABLISHED connection.  That is fine, except as soon as the
ESTABLISHED connection goes away so does it's expectation(s).  With the
nature of P2P like Gnutella, connections come and go like the wind.

That is why the expectation (which is the same for every outgoing and
incoming connection) needs to be refreshed with new master
connections.

> s'cool ... let one out set it off ... and the ins can look after themselves ...

Right.  I do refresh the expecation for every outbound connection, but
need to refresh on inbound connections as well as outbound connections
can be few and far between once the client has made it's presence
known.

> Whenever your "end condition" occurs for the client ... then unload all
> of the open expectations ....

Well, the expectation (there is only one, it's the same expectation
for all masters everybody:allports->client:localport) goes away when
it times out or the master connection goes away.  That is clean enough
for me.

> so ... a or b rings true, then trash the open
> expects ..

It's just cleaner to let the framework do that for me.

> Even if there's nothing in the payload ... if the NAT has been a masq or
> some other non ip-to-ip mapping, then the helper will need to rewrite the
> ip headers ...

Right.  I am already doing that.  I do alter the payload in the
outgoing connection if needed -- although with gtk-gnutella, it somehow
determines the outside address of the iptables box so technically it's
not needed.

> this had to be done in rsh .. which works like ftp ... one
> out with a port in the proto for where a new one should come back ..
> this then hits the firewall (tables) as a local port, which then needs to
> be re-written.

Right.  That I am doing already as well.  I have successfully run two
different clients behind my modules and they both work (while both are
using the same local port), so I must be doing something right.  :-)

> I don't see your proto as being tremendously different from ftp ... 'cept
> that the data sessions can be many+ and they can come from
> the universe and not the master destination ...  should be pretty straight
> forward ...

'Tis really.  In my original message, I think I said it was 99%
working and thought I had to use a hack to get it to work when indeed
my hack was (close to) the right solution.  I based heavily on the ftp
and/or irc modules.

b.

-- 
Brian J. Murrell

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]