Linux IP Masq & Netmeeting

Linux IP Masq & Netmeeting

Post by Kelvin Leun » Thu, 24 Sep 1998 04:00:00



Hello,

I am looking for solution on IP Masq server with PC client of
Netmeeting. I still can't get through the IP Masq... Somehow I think
there is some solution out there, like setting up a proxy server rather
IP Masq... I have no clue on it. Can somebody give me some advice?
Thanks a lot!

Kelvin

 
 
 

Linux IP Masq & Netmeeting

Post by tmk » Thu, 24 Sep 1998 04:00:00


Quote:>I am looking for solution on IP Masq server with PC client of
>Netmeeting. I still can't get through the IP Masq... Somehow I think
>there is some solution out there, like setting up a proxy server rather
>IP Masq... I have no clue on it. Can somebody give me some advice?

my advice: search the MS knowledgebase section on netmeeting for "proxy"
That will tell you the various ports that it uses that need to be open on
your firewall. If you only need one computer to access netmeeting, you can
then create a ip forwarding rule with ipfwadmin to forward all packets
coming into your firewall/masq server to that computer. If there are
multiple computers that need netmeeting access, you MAY be able to forward
the port to an arbitrary host in your local network, but i'm not sure how to
do it. I'm pretty sure you could get it working for just one computer. read
the ipfwadmin docs and man pages.

tmk

 
 
 

Linux IP Masq & Netmeeting

Post by Jerry P » Thu, 24 Sep 1998 04:00:00



> Hello,

> I am looking for solution on IP Masq server with PC client of
> Netmeeting. I still can't get through the IP Masq... Somehow I think
> there is some solution out there, like setting up a proxy server rather
> IP Masq... I have no clue on it. Can somebody give me some advice?
> Thanks a lot!

> Kelvin

  I am about to be doing the same thing. My bet is you have to configure
ipfwadm to allow the appropriate UDP/TCP ports to open for a range of IP
address (ISP add and NT box IP) so the packets can pass through in each
direction. Somewhere in the Netmeeting docs it should say what port numbers
it uses. JP
 
 
 

Linux IP Masq & Netmeeting

Post by Hal Ree » Tue, 29 Sep 1998 04:00:00


I've been struggling with this all day and have found the key to why it
doesn't work (or rather, why audio doesn't work).  You *can* in fact
initiate an outgoing connection and get whiteboard, chat, and application
sharing.  You can't however, get incoming requests or incoming audio to
work.

The reason is that Netmeeting (and also Netscape Conference) use an H.323
setup protocol to dynamically assign TCP ports for audio control.  The
calling system contacts the callee system by initiating a connection on port
1503, then establishes an connection on port 1720 to negotiate a free port
for H.323 communications.  The callee then replies to this request with an
address which the caller can use for the control stream.  Unfortunately,
this address includes the ip address of the callee, so if the callee is
behind a firewall, the caller gets an ip address that is valid INSIDE the
callee's network, but is useless outside.  Since NetMeeting uses H.323 on
both ends to establish the audio connection, anything outbound from inside a
firewall works (assuming you've got ipautofw or some similar tool set up
properly), but any connections coming from outside get handed a bogus
address.

Example (simplified):

Frank is inside the firewall, at local (bogus) ip 192.168.0.10, via real
world 1.2.3.4.  Jay is on a 'real' machine at 5.6.7.8.  Frank calls Jay.
Frank's machine (which the outside world thinks is 1.2.3.4) contacts
5.6.7.8:1503 and the machines shake hands.  No prob.  Frank's machine then
contacts 5.6.7.8:1720, and Jay's machine says "oh, you've got audio for me -
contact me at 5.6.7.8:1026 for further info".  Frank's machine now calls
5.6.7.8:1026, and Jay's machine replies with "cool - send your audio via UDP
to 5.6.7.8:40000".  Frank's machine starts sending UDP to 5.6.7.8:40000 and
Jay can hear Frank's voice.  Jay's machine then calls 1.2.3.4:1720, which is
what it thinks Frank's address is.  Frank's firewall, being properly
configured, directs this stream to Frank's internal machine at
192.168.0.10:1720.  Frank's machine then says 'oh, you've got audio for me -
contact me at 192.168.0.10:1028."  HERE'S THE PROBLEM...  Because Frank's
firewall doesn't know about H.323, it doesn't know to translate that
192.168.0.10 to 1.2.3.4.  Thus, Jay's machine tries to establish an audio
control TCP stream to 192.168.0.10:1028, not 1.2.3.4:1028, so it fails.

I'm trying to find a solution.  What we really need is for someone who's a
better C programmer than me to write ip_masq_h323.c, but I've yet to find
anyone working on that.

 
 
 

Linux IP Masq & Netmeeting

Post by Kelvin Leun » Wed, 30 Sep 1998 04:00:00


Yeah,

We need somebody to write this module for IP Masq... Anyone can help? It
would be greatly appreciated...

Kelvin


> I've been struggling with this all day and have found the key to why it
> doesn't work (or rather, why audio doesn't work).  You *can* in fact
> initiate an outgoing connection and get whiteboard, chat, and application
> sharing.  You can't however, get incoming requests or incoming audio to
> work.

> The reason is that Netmeeting (and also Netscape Conference) use an H.323
> setup protocol to dynamically assign TCP ports for audio control.  The
> calling system contacts the callee system by initiating a connection on port
> 1503, then establishes an connection on port 1720 to negotiate a free port
> for H.323 communications.  The callee then replies to this request with an
> address which the caller can use for the control stream.  Unfortunately,
> this address includes the ip address of the callee, so if the callee is
> behind a firewall, the caller gets an ip address that is valid INSIDE the
> callee's network, but is useless outside.  Since NetMeeting uses H.323 on
> both ends to establish the audio connection, anything outbound from inside a
> firewall works (assuming you've got ipautofw or some similar tool set up
> properly), but any connections coming from outside get handed a bogus
> address.

> Example (simplified):

> Frank is inside the firewall, at local (bogus) ip 192.168.0.10, via real
> world 1.2.3.4.  Jay is on a 'real' machine at 5.6.7.8.  Frank calls Jay.
> Frank's machine (which the outside world thinks is 1.2.3.4) contacts
> 5.6.7.8:1503 and the machines shake hands.  No prob.  Frank's machine then
> contacts 5.6.7.8:1720, and Jay's machine says "oh, you've got audio for me -
> contact me at 5.6.7.8:1026 for further info".  Frank's machine now calls
> 5.6.7.8:1026, and Jay's machine replies with "cool - send your audio via UDP
> to 5.6.7.8:40000".  Frank's machine starts sending UDP to 5.6.7.8:40000 and
> Jay can hear Frank's voice.  Jay's machine then calls 1.2.3.4:1720, which is
> what it thinks Frank's address is.  Frank's firewall, being properly
> configured, directs this stream to Frank's internal machine at
> 192.168.0.10:1720.  Frank's machine then says 'oh, you've got audio for me -
> contact me at 192.168.0.10:1028."  HERE'S THE PROBLEM...  Because Frank's
> firewall doesn't know about H.323, it doesn't know to translate that
> 192.168.0.10 to 1.2.3.4.  Thus, Jay's machine tries to establish an audio
> control TCP stream to 192.168.0.10:1028, not 1.2.3.4:1028, so it fails.

> I'm trying to find a solution.  What we really need is for someone who's a
> better C programmer than me to write ip_masq_h323.c, but I've yet to find
> anyone working on that.