Gotta love Firewalls (yeah, right)

[Gary Miyakawa]

Folks,

I believe this could be a very useful thread for those of us that have to live (and die) with customer established firewalls. I'm sure that a number of you have had to work with (and around) these fine software/hardware products. What I would like to see here is a listing of the firewalls that you have had success (and failures) with so we (the group) have a place to go and look for assistance when having fun with them. (read, not passing the good stuff).

Anyway, if you all would be so kind as to list Make, Model, soft/firm ware version and what policies you had to use/create it would be a great reference point for us all!

Thanks for any help folks !

Gary Miyakawa

[NormMorrison]

Firewalls are easy. Supply a network connection and a bit of power and they work just fine.
It's the guy administering it that needs to be coddled, bribed and sometimes struck with a big stick.

[Janine]

I totally agree Gary. I'm in K12, at an educational service agency serving 26 units in 18 school districts (all with their own type of firewall). We are just starting to move to IP and I need help telling the network administrators at each district what they need to do to make their Polycom Viewstations work through firewalls (Watchguard 1000, BorderManager, and a homegrown linux firewall are three that I know of out there so far).

My immediate problem is a Polycom VSX 7000 connecting behind BorderManager 3.8 SP 2. It's configured with a static NAT. We also had the filters turned off during testing, but they want them turned on eventually, of course. We can inititate an H.323 call but cannot receive one. Also, the Polycom will not register with our Radvision 323 Gatekeeper.

I have an education background and our network people aren't familiar with H.323 so we're really looking for information! Any tips, URLS, training suggestions, would be very welcome!

Another thing we need help with is ways to ensure QoS. I have an inkling that such a thing is possible for our districts with a T-1 line maxed out most of the time but also want to do videoconferencing. Any tips for reading, software solutions, etc. that I could send along to the network people at these districts?

Thank you for any assistance you can give me!

-Janine

[tom9933]

Probably a great place to start would be the Videoconferencing Cookbook, its available at: http://www.videnet.gatech.edu/cookbook.en/
There is a section that specifically talks about firewall configuration. As for a QOS solution I’d recommend a few packet shapers. They aren’t the cheapest solution in the world but properly configured they can make life much easier.
Check out: http://www.packeteer.com/prod-sol/products/packetshaper.cfm

[Glen Sykes]

I've sucessfully implemented a VC network behind a PIX 535 using the Cisco MCM gatekeeper and IP to IP gateway.

A good rule of thumb for firewall traversal (true firewall traversal, i.e. going through it) is knowing when you can and can't do it. It's simple, if the firewall is not PIX or Checkpoint on the Nokia box, don't try to go through it with H.323 traffic. Instead consider something like Tandbergs Ridgeway solution that 'tunnels' the traffic through the firewall on 2 static ports.

The alternative is to go around the firewall (co-edge) with an application layer gateway. The downside to this is convincing the network manager that you're not creating a backdoor. The key words here are application layer, i.e. the gateway is specific to H.323 applications and nothing else.

For what it's worth the Cisco MCM solution can be deployed in either behind the firewall or co-edge network models, and is codec transparent, highly scaleable and extremely reliable (Cisco ought to be paying me for all the good PR I give them!)

[Sean Lessman]

I've sucessfully implemented a VC network behind a PIX 535 using the Cisco MCM gatekeeper and IP to IP gateway.

A good rule of thumb for firewall traversal (true firewall traversal, i.e. going through it) is knowing when you can and can't do it. It's simple, if the firewall is not PIX or Checkpoint on the Nokia box, don't try to go through it with H.323 traffic. Instead consider something like Tandbergs Ridgeway solution that 'tunnels' the traffic through the firewall on 2 static ports.

The alternative is to go around the firewall (co-edge) with an application layer gateway. The downside to this is convincing the network manager that you're not creating a backdoor. The key words here are application layer, i.e. the gateway is specific to H.323 applications and nothing else.

For what it's worth the Cisco MCM solution can be deployed in either behind the firewall or co-edge network models, and is codec transparent, highly scaleable and extremely reliable (Cisco ought to be paying me for all the good PR I give them!)Glen, FYI the TANDBERG firewall solution does not use tunnels. Tunnels imply open connections in and out of the firewall. Our solution requires allowing outbound connections only on a few ports to one specific address, there are no inbound connections. Its more secure than tunnels, requires no interoperability with H.323 aware firewalls, and works with all codec features (including proprietary features like People+Content and Siren14) and it works with any vendor's codec, its a true multivendor friendly solution.

In addition the technology can firewall any vendor's infrastructure (MCUs etc) and increase the functionality of any vendor's gatekeeper solution. Its additive to your existing solution and does not require any products to be replaced to gain this functionality. There are of course benefits to buying TANDBERG in this environment, but you will not lose any functionality because you bought the competition infrastructure or endpoints.

Other solutions solve the immediate border at your location, ours solves the border at your location AND the border at the far end. And it works through ANY number of firewalls or NATs.

(takes off marketing hat and sits down) :-)

Sean

[Glen Sykes]

Hi Sean,

Thanks for the info. My peice was based on old information from IP Freedom, and written prior to the launch of Expressway, which is similar but different, in all the ways you just pointed out :)

Where expressway is concerned, I'm unsure about something, maybe you can help.

Where MXP endpoints exist behind a firewall, and the Tandberg Border controller is on the outside, a session is created directly between the MXP and the Border Controller in order to traverse the firewall. How is E.164 resolution acheived in this model? Can a 3rd party GK be used?

If non MXP endpoints are behind the firewall, a Tandberg GK is required to handle the session establishment through the firewall, and therefore E.164 resolution is also part of the package.

So in a case where mixed endpoints are employed (MXP and non-MXP) it makes sense for everything to use the Tandberg GK, in which case, what's the point in the MXP's being able to establish sessions with the BC as I see this as by far the most common deployment (given that the MXP's in this model will use the GK's session establishment and not their own).

...or have I misunderstood something?

[Sean Lessman]

Hi Sean,

Thanks for the info. My peice was based on old information from IP Freedom, and written prior to the launch of Expressway, which is similar but different, in all the ways you just pointed out :)

Where expressway is concerned, I'm unsure about something, maybe you can help.

Where MXP endpoints exist behind a firewall, and the Tandberg Border controller is on the outside, a session is created directly between the MXP and the Border Controller in order to traverse the firewall. How is E.164 resolution acheived in this model? Can a 3rd party GK be used?

If non MXP endpoints are behind the firewall, a Tandberg GK is required to handle the session establishment through the firewall, and therefore E.164 resolution is also part of the package.

So in a case where mixed endpoints are employed (MXP and non-MXP) it makes sense for everything to use the Tandberg GK, in which case, what's the point in the MXP's being able to establish sessions with the BC as I see this as by far the most common deployment (given that the MXP's in this model will use the GK's session establishment and not their own).

...or have I misunderstood something?Hi Glen,

It may be hard to explain exactly how it works in this forum unless you have indepth knowledge of how H.323 works. The solution requires (for lack of a better term) a client-server relationship between 2 devices. In our model the 'client' is found in both the TANDBERG GK and MXP endpoints while the 'server' is found inside the TANDBERG Border Controller.

The simplest way to think about it is the TANDBERG GK and TANDBERG BC are a neighbored set of routed Gatekeepers that do some very clever things to ensure all UDP/TCP connections are outbound through the firewall ONLY. On those outbound connections, we do all the communications you would find in a normal H323 call.

So to answer your question, you can neighbor any 3rd party gatekeeper to either the TANDBERG GK (inside the border) or the TANDBERG BC (outside the firewall) and still make use of all the unique features of your Gatekeeper of choice AND the firewall traversal features of the TANDBERG solution. This means we can firewall traversal enable any existing infrastructure and do not require you to replace or remove any of your existing equipment. If you use all Polycom for example, we can make your solution better without you changing anything. The user experience will remain the same, except now you can call systems outside the firewall.

Because the MXP also has the secret sauce, we can solve the local firewall problem AND the firewall problem at the far end. This is the bonus for using MXP. The far end can be a part of your local dialing plan using E.164, H.323 ID or the system name of the product. In addition, both the TANDBERG GK and BC support URI dialing according the H.323 Annex O. The URI (DNS) dialing allows you to do a 'dynamic neighbor' for lack of a better term. So rather than neighboring to every gatekeeper in the world for the purpose of sending LRQs, you can achieve this through DNS lookup. Not to mention this can greatly simplify your dialing plan (i.e. everyone's video number could be your email address).

Summary for Expressway:
1. Doesn't require any replacement of any products
2. No software upgrades to 'H323 enable' your firewall
3. Supports all endpoint features (even proprietary ones like Siren 14 and People+Content)
4. Not Windows based so it can reside on the public internet
5. Requires outbound traffic only on well known defined ports (1719, 2776, 2777)
6. It is not a firewall, its an addon to work with ANY brand firewall
7. Solves the local firewall problem AND the far end firewall problem (H323 aware firewalls do not do this, nor does using a MCU to bridge the firewall)
8. Works on incoming and outgoing calls (most H323 aware firewalls only do outbound)
9. Solves the dial plan problem, remote offices can have the same 4 digit dialing etc
10. Its made by TANDBERG so it will be developed alongside the total solution moving forward

We are pretty excited about all the possibilities for this feature in the future.

Hope this helps,

Sean

[bdldunworthy]

Hi Sean,

I was wondering if you could answer a tandberg question for me.

This is my situation... I have a tandberg 880MXP system and a border controller in place. I would like to communicate with another school that doesnt have tandberg equipment. The school can call outside of their firewall but they cannot accept incoming video calls. With the BC and MXP endpoints i have in place is it possible for their systems to call me?


Thanks
Robert

[rl3]

Has anyone configured a vsx7000 behind a PIX 535 without gatekeeper software?

I am pulling my hair out on this one. I have try opening all ports to my static IP but am unable to make a call or receive one. Even outside the firewall I can not receive calls to my vc unit.

any comments welcome.
thx, rl3

[senthil]

hi

did u fixup ports h323 h225 and 1720. Disable the H.239 dual video pix will not support.Better to upgrade pix 53x to version 6 software .
Senthil

[pzaloumis]

make sure to turn off H323 fixup.

[ksoliz]

Ok here is my situation...

I'm working on a telemedicine project in the "Valley" South Texas. We have a mobile medical clinic RV with an MXP 880 on board. In addition we have several MXP placed directly at the schools. This RV visits several schools in the region and they use the local schools network to connect to the Internet and this is how video calls are received. The RV and local clinics provide free medical services with the biggest draw being the ability to video conference with UT doctors in Houston so they can assist with diagnosing and helping patients in the area.

Here is the issue... I work for UT Health Science Center is Houston where the video calls originate from. So here is the connection path...

Source: UT Tandberg in Houston (129.106.x.x)
Destination: RV Tandberg in San Benito, TX (10.x.x.x nat'd to 67.x.x.x)

Path...

UT Tandberg
|
|
\/
UT firewall (check point)
|
|
\/
over the Internet
|
|
\/
Region One ISP firewall (Cisco PIX IOS 6.3)
|
|
\/
local school district firewall (Sonicwall)
|
|
\/
school Tandberg in San Benito, TX

Finally the problem… everything with a normal call works great. As soon as we enable encryption (AES or DES) the call fails. With encryption enabled the call will initially connect but never completes the setup. If you look at the path above there are three firewalls in place. Both the Sonicwall and Checkpoint are allowing the equivalent to permit any any, anything and everything; those rules are only limited to source and destination. Now the PIX is allowing tcp/upd any any and also has h323 fixup enabled, not as open as the Sonic and Checkpoint rules. The question is how does encryption work with the Tandberg, does the encryption happen before the typical H323 call setup or after. In other words if it’s after is the encryption occurring in the payload of the TCP/UDP packets? This is something we are in the process of getting Tandberg to answer. This would greatly effect how the rules would need to be setup on the PIX.

Any thoughts on the issues would be greatly appreciated.

[tom9933]

I can’t comment on the Tandberg specifics but generally speaking the H.323 fix-up in a Cisco PIX will break calls using any of the newer features (AES, H.239 etc). To fix the problem you either have to dumb down the call or find a way to connect without using fix-up. I keep hearing that there is a new version of the PIX that fixes this issue but I haven’t seen it yet. We have a similar issue with a local hospital where the PIX is blocking H.239 traffic.

[Joe Vallender]

Don't the firewalls have to be encryption enabled to exchange the encryption keys?

[trapehzoid]

earlier versions of PIX firewalls using fix-up and PIX's acting like VPNs would cause encrypted (h.235) calls to fail. Supposedly v7 PIX software addresses this. Look at the version of your pix and consider upgrading

[Sean Lessman]

Finally the problem… everything with a normal call works great. As soon as we enable encryption (AES or DES) the call fails.

Usually a dead giveaway the firewall is preventing the call. In a H.320 call the call is connected *then* the encryption is negotiated and keys exchanged. In a H.323 call, the encryption capability is presented during call setup. If the firewall doesn't understand encryption it is likely to shut down or deny the call setup message altogether.

The question is how does encryption work with the Tandberg, does the encryption happen before the typical H323 call setup or after.

Works the same with everyone, based on the H.235 standard (IP) and H.233 standard (ISDN). See above for the reason it is possibly failing.

Any thoughts on the issues would be greatly appreciated.

Get TANDBERG Expressway :)

Sean