[plug] netmeeting

[Craig Ringer]

> The H.323 protocol that these programs (NetMeeting, GnoMeeting, etc) use 
> open a control connection on port 1720, then use that connection to 
> negotiate which other ports they will use for the video and audio 
> connections.  These other ports are chosen at random, so you can't 
> easily program iptables rules for them (other than 'forward everything', 
> which kind of defeats the purpose).

Its worse than that. I gather that H.323 also sends the client IP in its 
negotiations. Unfortunately, if you're on a NATed host, that means an 
incorrect non-routable (and hopefully non-routable) private IP. As a 
result, even with a firewall that is set to "forward everything", H.323 
will not work behind nat. That's my understanding of the situation, 
anyway. It could be possible to write a very smart NAT module similar to 
what was done on a lesser scale for ICQ (enabling file transfers) and 
FTP (enabling both modes) where normal NAT wasn't adequate. There is no 
such module for linux that I've heard of - instead, the common approach 
is the H.323 gateway server Jon mentioned:

> You need to have an application proxy that can sit on the firewall and 
> handle H.323 connections for you.  The Checkpoint Firewall-1 product has 
> one, which works fine.  A group called openh323.org (I think) had a 
> product called 'phonepatch' a while back which worked OK (I had it going 
> on Linux) and it also functioned as a H.323 gateway, since inbound calls 
> to a NATted network get confusing - who is the call for?  The gateway 
> presents a directory and asks who you want to contact, and routes the 
> call to that person.

I suggest you look for openh323gk or opengate. There are debian packages 
for both those under those names. I've got openh323gk installed but 
haven't had much of a chance to play with it yet.

Craig