I’ve been trying to get a desktop video conferencing system working here but have encountered a bit of a brick wall and I’m hoping you may be able to help.
We use two firewalls, both MS ISA Servers, one (ISA2004)as a back-end firewall and web proxy, the other(TMG) as a front-end firewall and to publish services. Normally, we would place a given service like our web sites on a 192.168.x.x segment and use NAT on the front-end firewall to handle the routing between an incoming request and the serving of a web page or facility. Similarly for FTP and other services.
When it comes to this VC Desktop, we have had no problems in installing the software and making suitable firewall rules to connect outwards (UDP 5082) but our front-end firewall insists on blocking the returning signal as it is returned to the firewall external address with no indicator which would enable it to route to the correct internal address. We are also not ‘publishing’ a server in the classic sense as this is more of a pass-though issue. We will need users behind the back-end firewall to be able to use this service.
We should perhaps be using secondary ports but we are unclear as to how and what to configure.
Ita may well be that we have completely the wrong approach so any help v gratefully received
Take a look at RHUB web conferencing appliance. It has guaranteed connection. It could be deployed behind the firewall for internal use only. You could find more info here http://www.rhubcom.com/v4/web_conferencing/security.html
Posts: 2228
Joined: 12.Apr.2004
From: Taylorville, IL
Status: offline
quote:
desktop video conferencing system
Meaning individual user's workstations? Never gonna happen
There is no such thing as "pass-through" in this particular context with ISA or TMG
It can only possibly be done with a centralized VC Server sitting on the LAN that all the VC Clients connect to. Then even with some of those it just absolutely will not work because of the poor communication design of the products.
So check out Susan7's suggestion,..if that product is designed to work over firewalls then that is you only real hope.
Why is this true? Because all of the Protocols designed for Video Conferencing and for things like VoIP were not designed properly for this. They were designed for operation only within a controlled open LAN. Some of the protocols embed the Client's IP# within them,..which is an RFC Private Non-Internet Routable address,...so when the host on the opposite end opens the packets it retrieves the Client Private Source IP#,...but cannot do anything with it because their is no way for it to reach any such IP#. For products to use such Protocols across NAT and Proxying Devices they have to dissemble those packets and replace the embedded IP#s with the IP#s of the NAT or Proxy Device,..and then repeat the process in reverse when going back the other direction. Now if you look at RHUB that Susan7 suggest it appears that they are positioning the RHUB server into a place where it is in position to "broker" the session between the Hosts at each end which bypasses the above problem. Then, I don't use that product myself, but I suspect that it encapsulates those packets within a more firewall friendly protocol (like maybe HTTP or HTTPS) to go over the Firewalls.
|
My Subscription |
My Forums |
Address Book |
Member List |
Search |
FAQ |
Ticket List |
Log Out
Printable Version
All Forums >> [Forefront Unified Access Gateway 2010] >> General >> desktop video conferencing 
desktop video conferencing - 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread