Video Conferencing Behind a Firewall?

JShadow21 asks: "I work at a research lab at a hospital. We want to collaborate with colleagues across the pond via video conferencing however the firewall here is very restrictive. There are way too many ports that needed to be opened for H.323 to work so the IT guys won't do that. What alternatives are there? I was considering using an SSH proxy in order to use Netmeeting, or else possibly a web based solution."

Comments

Your IT guys are lazy

[grub]

The Netmeeting rules in our PIX configs need only 5 TCP ports: LDAP, 522, 1503, h323 1731. If you know the IPs of the remote side you can open up a very restrictive set of holes for incoming "calls" or you can initiate the connections and not worry about opening up incoming holes altogether (if you use NAT/PAT this is easiest.)

Remember: your IT guys aren't running the show, they're there to help you do your job (and I'm an IT weenie at a research lab where Netmeetings are not uncommon...)

Re:Your IT guys are lazy

[bill_mcgonigle]

I used to work in hospital IT. The network manager was affectionately known as Mordac the Preventor.

Or it could be that your IT guys aren't lazy, they just don't know anything so they can't characterize the risk associated with H.323 or they don't know how to setup NAT for what you need.

Re:Your IT guys are lazy

[Metzli]

It's also possible that NAT won't work and they're concerned about that. We have some Polycom video conference gear and it won't work with NATs. The box embed the endpoint IP in the packet itself, so NATs cause the system not to function. Yay.

Re:Your IT guys are lazy

[SirLeNerd]

Depending on your firewall this problem can be overcome. For example on a PIX you can use the H323 fixup to re-write the IP addresses to the NAT.

Keep it simple...go with NetMeeting.

[TripMaster Monkey]

I would have to recommend NetMeeting...it's easy to implement, and is already installed on your Windows machines. However, there are quite a few ports that need to be opened...to ensure smooth passage through the firewall, I recommend you take your IT guy to lunch at your local watering hole to discuss it. ^_^

Seriously, though, the opening of these ports should prove to be a minimal security risk if done correctly. A firewall admin who won't open any ports is a firewall admin who doesn't know how to do his job (Ford Motor Company's firewall boys spring to mind here). Remember, this is a valid request you're making, and implementing that request in a safe and secure manner is their job.

Re:Keep it simple...go with NetMeeting.

[__david__]

You are correct. Going straight to the person who could help you the most is a grevious violation of protocol. First you file form 457s22 (making sure to initial paragraphs 3, 41, and 72, obviously). Then Submit this form in triplicate to your supervisor, the current head of the TCP/IP security subcommity and the associate vice chairman of the s22OE working group.

After that has been processed you will recieve form 4208XX which needs to be filled out within 12 hours (!!!) and refiled (in triplicate, of course) to the same people plus the organizational director of document services. Don't worry, after that you only have to wait 6 to 8 weeks for them to approve or deny your request.

Or you could just go right to the IT guys and buy them lunch as someone else suggested. But isn't the red tape method more rewarding in the end?

-David

Re:Keep it simple...go with NetMeeting.

[Euler]

With most TCP-based applications, it is possible to implement a sane firewall strategy, but H.323 (Netmeeting) makes it pretty much impossible to do so. The protocol has a standard port for the control connection, but it sets up any port it feels like for incoming UDP voice/video traffic. The protocol expects you to leave the server AND CLIENTS in the DMZ, with all the problems that brings; limits other hosts in a NAT network, and obvious over-exposure to security attacks. When I started working with H.323, I realized very quickly that this alone is a show stopper that will/has limited the adoption of practical video/voice conferencing.

The main issue is that NAT routers and firewalls work well with outgoing TCP connections, because it is easy to contruct the return route with that information alone. UDP and unsolicited TCP connections are nearly impossible to deal with without some protocol specific knowledge. Most video and voice solutions are stuck in the mindset that they have to use UDP for its unreliable, but timely data transmission. One successful exception are systems like Yahoo chat, which I know for a fact works like a charm behind a NAT firewall. It seems they fall back to a server-based TCP connection if UDP fails to route. Netmeeting seems to just go blissfully along in silence as long as the control connection can be established. It won't even do a sanity check to see if the data traffic is getting through at all.

Only semi-usable solution I know of is to have a extra-fancy router or firewall that does packet inspection and is specifically aware of H.323

It all works great on a LAN or possibly a VLAN or VPN though.

Dedicated VPN/video server

[n1ywb]

Select a machine somewhere to be a dedicated video conference server and have everybody VPN into that machine. Then all those crazy h.whatever ports should be fine.

web based solution

[sycotic]

we use http://www.webex.com/ at our work, works a treat behind a multitude of firewalls and maybe even proxies if I remember rightly.

you should check it out :)

OpenVPN

[Noksagt]

OpenVPN is Free (in both senses), fairly fast, cross-platform, but most of all easy to setup. Tunnel all traffic through a single, CONFIGURABLE port. My IT department is also often inept & they're packet-shaper makes most VPN traffic crawl (as if it were P2P or something). We require fast remote control software to be run, so we put it on port 80 & watched the traffic finally fly along.