Re: [GnomeMeeting-list] Gnomemeeting behind a Cisco Nat Firewall

[Damien Sandras <dsandras seconix com>]

Le mer 05/03/2003 à 18:34, Marc Williams a écrit :
> On Wed, 2003-03-05 at 11:11, Damien Sandras wrote:


> Ok, I certainly know when to defer to the h.323 expert.  But maybe this
> is an opportunity for me to learn something.
> 
> By saying that it's only because my router is h.323 aware that I am able
> to do what I'm doing, I think you are implying that there are other
> dynamic ports being used behind the scenes that I am not specifying in
> my gnugk.ini file.  I've got my h.245 and RTP covered (and also q.931
> and t.120 but I don't think they count for purposes of this discussion)
> as well as the usual static ports.  Am I understanding your implication
> correctly?  If so, what other ports are being used?  it was my perhaps

Actually the problem is not with dynamic ports that are used.
The problem is different and a bit tricky to explain for a non-native
speaker like me ;)

Let's imagine that your gateway is not H.323-aware and let's explain
GnomeMeeting's case as it is easier to understand than with the
gatekeeper. You will admit that gnomemeeting, being H.323, works like
the gatekeeper.

You tell to your non-h323 aware gateway that GnomeMeeting will use the
30000-30010 range of TCP ports for the H.245 channel (the same will
apply to the gatekeeper), and you allow those ports on the gateway. Is
it enough to make things work? No, for 2 reasons:
	1) even if you are calling yourself to the outside, it is 	possible
that the remote endpoint opens the H.245 channel itself
	back to you. Even if you allowed port 30010 and that port 30010
	is used when the remote opens the connection back to you, the 	gateway
doesn't see that this connection is a result of the 
	H.323 connection established by you. The gateway will see an 	incoming
connection on port 30010, which is allowed, but the gateway
	will not know that this connection is for your NATted computer 	inside
your LAN. The only way for the gateway to know that is if
	that gateway supports H.323, then it will see that the 	connection
opened by the remote endpoint to you is the result of you
	connection to the remote and thus it will know that the packet
	has to be forwarded to the internal endpoint.
	If the gateway is not H.323 aware, it has no way to determine to
	which internal host the packet coming on port 30010 has to be
	directed.

	2) H.323 puts your local IP inside H.323 packets' body. It means
	that the remote endpoint will see your private IP and try to 	send data
back to that private IP => the packet will be lost.

There are thus several solutions to those problems:

Solution 1)
Solution to problem 1) : forward the given port ranges to the internal
machine so that if the remote endpoint opens the H.245 channel back to
you, it knows where to send the packet.
Solution to problem 2) : Enable IP Translation.

Solution 2)
Place the gatekeeper on a public IP, and ask him to proxy the calls. It
will thus take care of the connections and make sure that all
connections coming from your LAN are outgoing connections. That way it
is not possible that one of the 2 endpoints tries to open a connection
back to you.

The problem is not with dynamic ports used from behind the scenes. The
problem is that the remote endpoint can open a connection back to you
and if the gateway doesn't understand H.323, it will not know that
connection is the result of an H.323 call and it will not know what to
do with the packet.

Am I clear? :)



> mistaken understanding that h.323 only used dynamic port assignments for
> h.245 and rtp.
> 
> And thanks for covering this with me.  Even though this might have
> strayed a little more than either of us originally intended, it's good
> stuff to know.
> 
> 
> _______________________________________________
> GnomeMeeting-list mailing list
> GnomeMeeting-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-list
-- 
 _	Damien Sandras
(o-	GnomeMeeting: http://www.gnomemeeting.org/
//\	FOSDEM 2003:  http://www.fosdem.org
v_/_	H.323 phone:  callto://ils.seconix.com/dsandras seconix com