NAT reservations

NAT reservations

[Patrick McHardy]

Hi Krisztian,

I'm currently working on the H.323 connection tracking helper and
need to NAT addresses that are later used in an expectation, but
I don't want to create the expectation immediately. This can't
be done currently because the final port number is unknown before
the expectation is created. Your NAT reservations patch looks like
it solves exactly this problem. Is there a version for current
kernels?

Regards
Patrick

Re: NAT reservations

[KOVACS Krisztian]

  Hi,

On Wed, 2005-06-08 at 20:45 +0200, Patrick McHardy wrote:
> I'm currently working on the H.323 connection tracking helper and
> need to NAT addresses that are later used in an expectation, but
> I don't want to create the expectation immediately. This can't
> be done currently because the final port number is unknown before
> the expectation is created. Your NAT reservations patch looks like
> it solves exactly this problem. Is there a version for current
> kernels?

  Unfortunately I did not have time to port the patch for new NAT code
of 2.6.11, but a 2.6.10 version can be found in the latest tproxy
release tarball:

  http://www.balabit.com/downloads/tproxy/linux-2.6/

  That's the most up-to-date version available.

  Plus, I think the whole patch would require a thorough refresh, I
don't really like the idea of that extra hash table, etc. (And even that
hash table is poorly implemented, obsolete hash function, etc.)

--
 Regards, 
  Krisztian Kovacs

Re: NAT reservations

[Patrick McHardy]

KOVACS Krisztian wrote:
>   Unfortunately I did not have time to port the patch for new NAT code
> of 2.6.11, but a 2.6.10 version can be found in the latest tproxy
> release tarball:
> 
>   http://www.balabit.com/downloads/tproxy/linux-2.6/
> 
>   That's the most up-to-date version available.

Thanks.

>   Plus, I think the whole patch would require a thorough refresh, I
> don't really like the idea of that extra hash table, etc. (And even that
> hash table is poorly implemented, obsolete hash function, etc.)

I haven't looked closer at it yet, but I'll probably port it to
2.6.12-rc in the next couple of days, perhaps a good idea will hit me :)

Regards
Patrick

Re: NAT reservations

[chentschel2]

Mensaje citado por: Patrick McHardy <kaber@trash.net>:

Hi Patrick!

> I\'m currently working on the H.323 connection tracking helper and
> need to NAT addresses that are later used in an expectation, but
> I don\'t want to create the expectation immediately.

This is just to fulfill my curiosity. Is there some special reason for this?. 
I´m very interested in this, but I think i don´t really get your point :( 

Best regards,
Christian. 
__________________________________
Registrate desde http://servicios.arnet.com.ar/registracion/registracion.asp?origenid=9 y participá de todos los beneficios del Portal Arnet.

Re: NAT reservations

[Patrick McHardy]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1423 bytes --]

On Wed, 8 Jun 2005 chentschel2@arnet.com.ar wrote:

> Mensaje citado por: Patrick McHardy <kaber@trash.net>:
>
>> I\'m currently working on the H.323 connection tracking helper and
>> need to NAT addresses that are later used in an expectation, but
>> I don\'t want to create the expectation immediately.
>
> This is just to fulfill my curiosity. Is there some special reason for this?.
> I´m very interested in this, but I think i don´t really get your point :(

There are a couple of cases where it would be useful.
For example H.225 RAS RRQ (Registration Request) messages to Gatekeepers
contain the call signaling address of the Endpoint that registers.
I want to create an expectation that expects incoming calls when the
Gatekeeper replies with an RCF (Registration Confirm), but if we do NAT,
the call signaling address in the RRQ needs to be NATed before the final
port is known. So the only solution is to create the expectation
immediately and cancel it after some timeout or when an Registration
Reject is seen.

Same problem with Registration Confirm. It contains the call signaling
address of the Gatekeeper, but there is nothing to expect because every
signaling connection is preceeded by admissionRequest/admissionConfirm,
which contain the address again. But it should be NATed similar to the
ones in the admission messages, which can't be done reliably at all.

Regards
Patrick

Re: NAT reservations

[Christian Hentschel]

> I want to create an expectation that expects incoming calls when the
> Gatekeeper replies with an RCF (Registration Confirm), but if we do NAT,
> the call signaling address in the RRQ needs to be NATed before the final
> port is known. So the only solution is to create the expectation
> immediately and cancel it after some timeout or when an Registration
> Reject is seen.

mm.. i see. But is it worth doing that?. I mean if u have a ptp call
without RAS signalling u won't have this situation. Maybe registering
the module to look for RAS and h225 signalling port would be ok. ie. udp
171{8,9} and tcp 1720. 
I think RAS signalling separated from h225/Q931 signalling, cisco, ie,
have ras fixup and h255 fixup, but this may be is not a happy example
anyways =P

> Same problem with Registration Confirm. It contains the call signaling
> address of the Gatekeeper, but there is nothing to expect because every
> signaling connection is preceeded by admissionRequest/admissionConfirm,
> which contain the address again. But it should be NATed similar to the
> ones in the admission messages, which can't be done reliably at all.

This would be the same i think. Letting through h225signalling port 1720
should be ok, and h245 and RTP stuff will be the dynamic data to
expect/mangle.

I hope this helps and sorry for my english.. :)
Regards,

-- 
Christian Hentschel <chentschel2@arnet.com.ar>