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 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 <jan@xxxxxxxxxxxxxx> 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:jan@xxxxxxxxxxxxxx]
> Sent: Donnerstag, 8. Mai 2014 09:49
> To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
> Subject: Re: 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 : jan@xxxxxxxxxxxxxx
> 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, jan@xxxxxxxxxxxxxx, 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@xxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxx 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/
