New H.323 conntrack & NAT helper module

Jing Min Zhao zhaojingmin at hotmail.com
Sat Feb 25 07:00:00 CET 2006


On Friday February 24, 2006 11:00 PM,  Greg Scott wrote:
>
> Holey moley - this is GREAT news!!

Thanks!

> A couple questions.  Will this module work with 2.6.16 and upcoming
> newer kernels?

Yes. I'll keep tracking the kernel development. Once a big version comes 
out,
I'll update this patch. I think maybe Patrick McHardy is inspecting my code, 
if
I'm lucky, it may go into the kernel tree, and you won't need a separate 
patch
any more. I really hope so.

>  And - this is a biggie - the documentation says all I
> need to do is SNAT TCP 1720 for outbound calls and DNAT TCP 1720 for
> inbound calls.  No more tinkering by hand with zillions of TCP/UDP ports
> - no more trying to figure out if Polycom or Tandberg or whatever is on
> which end.  Is this really true???

Yes, and it's more than that. Actually, you don't need to specify the port 
1720 -
the module knows it, unless you want NAT only H.323 traffic. For inbound 
calls,
if you use a gatekeeper, you don't need the DNAT rule.

>  Will this patch really figure out
> and track the dynamic ports these devices use by default?

Yes.

> If so, then
> HOT DOGGIES!!!!

:)

> Also - will it work with proxy ARP?

This does nothing to do with the module. Sorry I'm not sure.

> Let's say I proxy ARP an H.323
> device behind the firewall.  Will this patch still handle connection
> tracking, even though there is no NAT?

Yes, it support this mode. Just don't load ip_nat_h323, load only
ip_conntrack_h323.

> The idea is, I would put a rule
> in the FORWARD table for TCP 1720 and the patch would "know" it's an
> H.323 device and also track and forward the appropriate TCP and UDP
> ports.  But it would be to a public IP Address proxy ARP'd behind the
> firewall instead of a NAT'd device.
>
> thanks
>
> - Greg Scott

Thanks

Jing Min Zhao



More information about the netfilter-devel mailing list