Oliver,
I have a couple of points for you:
1. Video call routing is what a gatekeeper does. Having only one public IP
is no impediment. You need to register your two endpoints with two
different H323IDs and call them via their registration alias, not via IP
address. As Jan said, you can call any number of the endpoints behind
firewall using their H323ID of the type User1@public-IP, user2@public-IP,
etc. Polycom devices will also take ip##userN address and connect the
calls. In general, calling H323 EPs via IP address is no longer considered
state-of-the art.
2. You stated that your firewall supports NAT. This may mean a bunch of
different things but in the VoIP context the most important feature is
opening pinholes. If your firewall does not prohibit outgoing UDP packets
then you should be able to use the pinholes to get incoming calls thru
firewall. Again, this is easier said than done since there are 4 different
types of NAT and typically FW vendors do not identify the type they
implemented, so it takes some FW forensics to establish NAT type (STUN
server is a very useful tool)
3.Note Jan's argument about the safest possible solution. A blanket
prohibition of putting application-specific network devices in front of
firewall is a bad security practice. Gatekeepers - also commercial ones -
are very hard to hack into. The only real issues may be a DOS attack. You
put 2nd gatekeeper inside and then establish a tunnel via using 460.18/19
protocol. If you start the the tunnel from inside of the firewall, NAT
pinholing will open it for you and the two gatekeepers will keep it
forever. The firewall nazis won't be any wiser. BTW, a prohibition on
putting servers in front of the firewall is sort of naive, since there is
whole Internet out there. Unless your firewall has a very sophisticated
configuration, your external gatekeeper could be in New Zealand. [?]
Marek J. Podgorny
<http://www.linkedin.com/in/marekjpodgorny>
CollabWorx <http://www.collabworx.com/>
Phone: 315-373-6345
Text/SMS: +13153736345
CONFIDENTIALITY NOTICE: This electronic mail transmission is intended only
for the use of the individual or entity to which it is addressed. It may
contain confidential and protected information belonging to the sender. If
you are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or taking of any action in reliance on
the contents of this information is strictly prohibited. If you have
received this transmission in error, please notify the sender immediately
by e-mail and delete the original message.
On Thu, May 8, 2014 at 7:24 AM, Jan Willamowius <j...@willamowius.de> wrote:
> Hi,
>
> in theory, you can use port forwarding on a number of port ranges to
> send incoming calls from the firewall to GnuGk, but thats a very trick
> configuration and I wouldn't recommend using that.
>
> Putting a server in front of the firewall is how most commercial
> products do it (if you ignore those that install full firewall
> bypasses, eg. Polycom VBPs). In my view thats the most secure option,
> because your firewall remains closed.
>
> Regards,
> Jan
>
>
> Oliver Weinmann wrote:
> > Hi Jan,
> >
> > This is a problem for us. We are not allowed to put any machines in
> front of the firewall, neither can we request to open any additional ports
> on the firewall. It's a bit of a let's say political problem. :( We assumed
> something like this would be possible:
> >
> > ((( INTERNET )))
> > |
> > | NAT: External IP for GnuGK
> > -----------
> > | |-------------------------------|
> > | | Port 1719 UDP -------------
> > | FW | Internal Network |Polycom|
> > ----------- |QDX |
> > |
> -------------
> > |
> > | DMZ
> > |------------------|
> > ------------ -------------
> > | | |Polycom|
> > |GnuGK | |HDX |
> > ------------ -------------
> >
> > Sorry for the very simple drawing, but this is how we assumed we could
> get it working without any further changes to firewall or our
> infrastructure. If there is no change required on the firewall we could
> probably put it in front of the firewall, but it would be better if not.
> >
> > Thanks for your help.
> >
> > -----Original Message-----
> > From: Jan Willamowius [mailto:j...@willamowius.de]
> > Sent: Donnerstag, 8. Mai 2014 09:49
> > To: openh323gk-users@lists.sourceforge.net
> > Subject: Re: [Openh323gk-users] Polycom QDX 6000 and HDX 7000 / GnuGK as
> Proxy???
> >
> > Hi Oliver,
> >
> > you should place a GnuGk in front of your firewall and register your
> Polycoms with it. Your Polycoms support H.460 NAT traversal so you don't
> have to open any ports in the firewall.
> >
> > Then you can call them from the outside as user@public-ip or
> public-ip##user.
> >
> > Regards,
> > Jan
> >
> > --
> > Jan Willamowius, Founder of the GNU Gatekeeper Project EMail :
> j...@willamowius.de
> > Website: http://www.gnugk.org
> > Support: http://www.willamowius.com/gnugk-support.html
> >
> > Relaxed Communications GmbH
> > Frahmredder 91
> > 22393 Hamburg
> > Geschäftsführer: Jan Willamowius
> > HRB 125261 (Amtsgericht Hamburg)
> > USt-IdNr: DE286003584
> >
> >
> > Oliver Weinmann wrote:
> > > Hi,
> > >
> > > we have two Polycom systems (QDX 6000 and HDX 7000). We would like to
> use GnuGK as a proxy for both systems as they are behind a firewall that we
> can't administer. Is this possible and how does it work? Currently we can
> receive calls via ISDN and IP on one of the systems. We would like to use
> this systems IP, as it has a NAT on the firewall and all the required ports
> for videoconferencing are already opened, for the GnuGK machine. But we
> wonder how we can receive calls via IP on both Polycoms if there is only
> one NATed IP address. Is there some sort of Name-based routing like in
> Apache virtual hosts? And maybe there is an example configuration?
> Currently we can register one of the Polycoms just fine with GnuGK but we
> can't call any outside IPs. I have not yet been able to test an internal IP
> call as the other Polycom system was not available at that time.
> > >
> > > Best Regards,
> > > Oliver Weinmann
>
> --
> Jan Willamowius, j...@willamowius.de, http://www.gnugk.org/
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find
> out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________________
>
> Posting: mailto:Openh323gk-users@lists.sourceforge.net
> Archive:
> http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users
> Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
> Homepage: http://www.gnugk.org/
>
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________________
Posting: mailto:Openh323gk-users@lists.sourceforge.net
Archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users
Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/
