recommended firewall

[ryness]

after wrastling with our Firebox only to discover it "doesn't support H323" I'm now asking myself if we shouldn't just replace the firewall with something that can deal with video conferencing.

We have three network segments (main lan, servers, testing), plus a video conferencing network. I'm wondering what firewall (make/mdoel) would you recommend for a modern medium-sized business that does QoS and can handle video conferencing?

[senthil]

Hi

Try firewall traversal instead of changing your existing firewall. Even if you are going for any other firewall solution without firewall traversal you will limit your self and may be facing same problem.

Senthil

[ryness]

ok... what about recommended solutions for Firewall traversal?

[ryness]

ok... what about recommended solutions for Firewall traversal?

[Howex]

The V2iu from polycom is a cost effective unit.

[Sean Lessman]

The V2iu from polycom is a cost effective unit.

I would argue that isn't firewall traversal, its firewall bypass. The V2IU works in one of two modes:

1. replace your firewall with the Edgewater OEM H.323 aware firewall
2. put the Edgewater H.323 firewall in parallel with your own and bypass your firewall's security policies

If you want an H.323 aware firewall, most firewalls offer that option. But this introduces another interoperability point. With true firewall traversal, the firewall is taken out of the mix when it comes to interoperability.

You will also need Edgewater devices at both ends. That means you need to convince the other sites you talk with to also go through the process above.

H.460.18/19 is a better solution. TANDBERG offers this today, and if you do not want a TANDBERG solution, the others have announced H.460.18/19 support in the future at some point.

Sean

[Guyver1]

Hi sean

I would take issue with
"You will also need Edgewater devices at both ends. That means you need to convince the other sites you talk with to also go through the process above."

You do not need a V2IU at each end. It is perfectly possible for someone outside your secure LAN to call to any endpoint within your lan even if the party calling does not have a V2IU.
The other party can do one of 2 things either dial the E164 of your system @ ipaddress of your V2IU.
or use <V2IU ipaddress+ extention/E164 number of your system> for example 62.54.67.89 + 1234. Most endpoints support the extention field on the home screen. Altho you may have to enable it in the system setup.

regards
guyver1

[trapehzoid]

for example 62.54.67.89 + 1234. Most endpoints support the extention field on the home screen. Altho you may have to enable it in the system setup.

define most.. I've never seen that used.

[Guyver1]

Perhaps most wasn't the appropriate wording.

I should have used "most Polycom endpoints".

But I am sure other manufacturers endpoint support this function as well.

[Sean Lessman]

You do not need a V2IU at each end. It is perfectly possible for someone outside your secure LAN to call to any endpoint within your lan even if the party calling does not have a V2IU.

Sure you do. Unless you are assuming the far end has no security policy and is sitting wide open on the Internet. If it is, they don't need firewall traversal.

Sean

[Sean Lessman]

Perhaps most wasn't the appropriate wording.

I should have used "most Polycom endpoints".

But I am sure other manufacturers endpoint support this function as well.

its actually a non standard method of dialing so the endpoint would have to specifically support the feature of the Edgewater. Registering to the device using H.323 would be the standards compliant way to do it.

Sean

[ryness]

With true firewall traversal, the firewall is taken out of the mix when it comes to interoperability.

Sean could you please elaborate on that... how do you mean "interoperability"?

[Sean Lessman]

Sean could you please elaborate on that... how do you mean "interoperability"?

The H.460.18/19 standard puts forth the concept of an inside and outside box for the firewall. We call ours the TANDBERG GK or MXP endpoint (inside) and the TANDBERG Border Controller (outside). These devices are H.323 devices. They must interoperate with the H.323 devices on the market today.

A H.323 aware firewall is also a H323 device and must interoperate with the H.323 devices on the market today. These devices tend to be behind the VTC industry in terms of stacks, features etc and will likely cause interoperability issues. A good example is AES through a PIX...this has been an issue for years and has only recently been addressed (I think!).

Sean

[ryness]

For small to medium sized businesses like mine, the cost of the VTC equipment alone is substantial. Our firewall (firebox x1000), which worked fine pre-VTC, can't deal with the H.323/NAT traffic (it can't accept inbound connections). Hence, this thread.

For the same cost of one Tandberg Border Controller ($8000) I could buy a firewall that can deal with H.323 through NAT (Cisco ASA 5520?). So I don't see why I would want to consider the Border Controller.

It's a bit ridiculous to have to traverse a firewall, IMO, and probably only necessary nowadays because H.323 is so much older than NAT. But it seems modern firewalls should be developed to handle it. Which leads me back to my original question: Anyone recommend any firewalls that can deal properly with inbound and outbound VTC/H.323 via NAT?

[Sean Lessman]

For small to medium sized businesses like mine, the cost of the VTC equipment alone is substantial. Our firewall (firebox x1000), which worked fine pre-VTC, can't deal with the H.323/NAT traffic (it can't accept inbound connections). Hence, this thread.

Yep, you found another limitation of H.323 aware firewalls. They do not allow inbound calls. So, everybody has a H.323 firewall nobody can call anyone because nobody can accept incoming calls.

For the same cost of one Tandberg Border Controller ($8000) I could buy a firewall that can deal with H.323 through NAT (Cisco ASA 5520?). So I don't see why I would want to consider the Border Controller.

Deal with outbound calls only. Like any technology you need to weigh the benefits versus the $$$. If there is no ROI for you, then it probably doesn't make sense. If you do not care about security, but the endpoint on the outside of the firewall. If you do not care about communications with your supply chain or business partners outside your firewall (and behind yours) then you probably do not need the solution.

H.323 firewalls do not solve your dial plan so you will still need gatekeepers.

Having responsibilities for the IT health of the TANDBERG Americas part of the company and being challenged by the CEO to 'take us to IP' -- this solution took months of work and allowed me to implement a robust solution regardless of number of firewalls, simple dial plan, and dynamic neighboring pretty much over the weekend. Today we have 3 theaters with 500+ endpoints able to talk reliably because of this technology. Before then, with Ip address dialing only and firewalls -- it was hit or miss, and mostly miss.

The support of our internal video network is handled by one person in the Americas because of this technology. Having to make constant changes to NAT, firewalls and deploying software clients and hardware at each site would take a small army.

Sean

[James Flockton]

ryness,

In summary for this thread, if you have a h.323 aware firewall all this will do is dynamically open ports for h323 signalling. Which with a video endpoint that is capable of re-writting the headers of the IP packet with the correct IP information of the outside will allow a device within your network to dial to another h.323 endpoint (Not taking far end firewall issues). If the far end is not firewalled and you only need to call out then this will not cause you a problem. If you use a boarder controller or Edgemark box this will allow external endpoints to register to the external interface of the device and then call into the network. As far as I'm aware though the Edgemark does not do gatekeeper functions so a Gatekeeper will be required for the Edgemark to register endpoints onto....

Chaps please correct me if I'm wrong.

[gsrcomm]

Ryeness: The problem with looking for a video-savvy firewall to fix your problem is that you are attempting to a address a multi-layer (in OSI model) need with hardward designed to support only lower layers. There are many factors/processes involved in passing real-time multimedia (or...cringe...."rich media") traffic through a firewall that occur above Layer 3--or 4, for that matter. Firewall manufacturers generally try to respond by creating patches/fixes that make their products "aware" of certain information in Layer 5 headers, etc.

Sean's comment "If you want an H.323 aware firewall, most firewalls offer that option. But this introduces another interoperability point. With true firewall traversal, the firewall is taken out of the mix when it comes to interoperability." is UNBELIEVABLY true. I could sit for a couple of hours and tell stories about the wrenches thrown into working video solutions when a simple s/w upgrade or patch is applied to a firewall that was happy with video traffic upto that point.

Rather than torque on "vanilla" firewalls in an effort to try and monkey-wrench video through them--or around them, in the case of the original V2IU platform--the most effective approach is to traverse the existing firewall with a standards-complaint solution (H.460.17-19) for H.323 traffic.

Currently, there are three players touting standards-compliant solutions: Tandberg, Polycom and Radvision. Tandberg uses an in-house client/server approach, Polycom uses an Edgewater solution--which isn't a traversal solution, rather a separate video-only firewall, and Radvision appears to have created a Linux-based server solutio which is a mixture of the other two.

My organization currently has a Tandberg Expressway Solution in place. It works very well--through our firewall. We tested the V2IU and passed for several reasons: It wasn't H.460-compliant at the time, and, per our vendor, only certain chassis/models will be going forward. We predicted this due to the fact that their solution was OEM'd by a third-party. (That and the fact that Polycom struggles to get things right on the first try, and then fall behind the curve while they do get it closer to right.) It also didn't integrate well with traditional zone control. To provide zone managment inside and outside the firewall (which IS important if your are using URIs, etc. for global dialing), external GKs had to be proxied through the firewall. If you use Cisco MCM running on 7200s even, the proxy limit (at the time) was a total of 75 calls at 384kbps. More realistically, (since implementing two 7200s to do nothign but proxy video is hard sell in my shop) if running MCM on a couple of 2600s, the proxy can handle 4 simultaneous 384k connections. So much for the V2IU limited by wire speed....

Having been told the Radvision solution was based on Linux server(s), wep opted not to consider it. We are a video group, not a sys admin group.

Now, having said all that, Guyver1 is correct: it is perfectly possible for someone outside your secure LAN to call to any endpoint within your lan even if the party calling does not have a V2IU, Expressway solution or similar security measures. If you choose to set an external GK outside your firewall AND implement an H.460-compliant traversal solution, anyone with publicly-accessible IP-based video codecs can register with your solution and call into it. There are MANY organizations that hang their appliance-based codecs outside the firewall or in their DMZ on a little video-only subnet.

It really bothers me when a manufacturer's rep speaks negatively about another brand's product(s)--especially when the comment is so glib....

Greg

[Armyjazzer]

I discovered this trick today. :banana:

Set the Tandberg enpoint to dial using call manager.

Set the Call manager address to the address of the V2IU interface you are calling to ( Wan or Lan ).

Dial using E.164 address of endpoint registered to V2IU.

You can also do this style of dialing in Peer-Proxy mode on the V2IU, but I have only done a limited amount of testing.

Tested with V2.6 on 990 and V4.1 on 550.

Enjoy!

Roger

[Yukikaze]

Now, having said all that, Guyver1 is correct: it is perfectly possible for someone outside your secure LAN to call to any endpoint within your lan even if the party calling does not have a V2IU, Expressway solution or similar security measures. If you choose to set an external GK outside your firewall AND implement an H.460-compliant traversal solution, anyone with publicly-accessible IP-based video codecs can register with your solution and call into it. There are MANY organizations that hang their appliance-based codecs outside the firewall or in their DMZ on a little video-only subnet.

It really bothers me when a manufacturer's rep speaks negatively about another brand's product(s)--especially when the comment is so glib....


...

You are saying exactly the same thing Sean was. It works, but only if one end is completely open. Which means it is not a general solution and it is almost guaranteed to come back and haunt the administrators when their assumptions about "all important remote sites being wide open" break, due to remote sites applying a security policy or new sites appearing that already have secure networks.

Just because a unit is appliance based doesn't mean it can't be affected by malicious network activity, so having them firewalled is definitly a good idea and this will only become more widespread. In the past we've seen virus activity actually crashing codecs when it tried to break into them. Although the attacks themselves never would have worked, due to the codecs not being PCs, some of them still managed to interrupted video communications.

[Sean Lessman]

It works, but only if one end is completely open.

Not sure I understand your statement. Can you clarify? I know our TANDBERG Border Controller it has gone through some extensive 3rd party 'ethical hacking' by the same folks who do this for firewalls and other security gear to help us harden the box. We have made tremendous strides in this area over the last 2 software versions.

There only needs to be a few ports between the internal device (H.460 endpoing or H.460 Gatekeeper) and the external device (H.460 Border Controller) that needs to allow outbound connections -- you do NOT need to 'open' ports. Four ports between two specific IP addesses (GK and BC). The BC is designed and has been hardened to allow placement on the public internet.

Which means it is not a general solution and it is almost guaranteed to come back and haunt the administrators when their assumptions about "all important remote sites being wide open" break, due to remote sites applying a security policy or new sites appearing that already have secure networks.

If deployed correctly, a H.460 solution will not require you to change your security policies -- at either end.

Just because a unit is appliance based doesn't mean it can't be affected by malicious network activity, so having them firewalled is definitly a good idea and this will only become more widespread.

Fair point, although we have yet to receive ANY reports of this sort of thing. It also helps to remove all services from the OS that are not required and that may be exploited which we have also done.

In the past we've seen virus activity actually crashing codecs when it tried to break into them. Although the attacks themselves never would have worked, due to the codecs not being PCs, some of them still managed to interrupted video communications.

The only example of this I have seen is a worm or similiar that overloads the internal webserver of the codec with too many requests at one time. In no way was it actually a virus causing the problem or infecting the system. As a workaround you can password protect (always a good idea) the codec or turn off the webserver if it becomes an issue.

Sean

[Harvell]

Ryness.... Considering this thread originally started in 2005, what kind of firewall did you get???

The V2IU is a small - medium sized firewall that allows H.323 connectivity. It is a multilayer device that is running Linux with IP tables and some proprietary software.