Polycom and Watchguard Firebox 500

Hey there, thanks for the advice.

I put the filters on and it shows that port 0 is being denied.

Hey there, thanks for the additional comments, guys.

I have an X500, running version 7.30-B2938.

I did everything you two said, and its still showing no audio/video incoming, but my video/audio is showing up on their screen. On the Polycom, it has an option for NAT transversal, or setting it to show the outside IP address as its own. I'll try playing around with that, but I don't know if that would be beneficial in this situation or not. Regardless, I'll keep trying and any more help would be GREATLY appreciated!

Additionally, when I view the connection through the hostwatch, these are the connections I get:

Source:            Destination:     Port:   Connection:      Details
192.168.5.222  12.31.173.174  2852    Dynamic NAT    to <MyPublicIPHere>:32778
192.168.5.222  12.31.173.174       0    Denied              rsvp Thu Sept 7 05:35:44

I hadn't noticed that before, but it seems as though the internal address is STILL trying to use Dynamic NAT even though I told it not to. Is this normal? The log spits out this repeatedly, until I disconnect:

09/07/06 01:35  firewalld[127]:  log out eth1 160 rsvp 24 30 192.168.5.222 12.31.173.174 unknown ? (ip options)

Is there a way to edit these things, 'cause I hate to keep adding more comments...

Anyway, I added 192.168.5.222 to external as a rule in addition to 192.168.5.222 to <MyPublicIPHere>, and that actually caused me to be unable to even connect to the Polycom help desk. It just kept dialing, and nothing showed up on Hostwatch. I assume this means that it is trying to use 1-to-1 NAT, but is failing for some reason. I tried it with and without NAT transversal and still no luck.

OK, I've spent a little time reviewing the documentation on the Polycom7000 and the watchguard.  The digging I have done on this subject doesn't look promising.  All searching on the Watchguard site leads me to the same Watchguard support page about H.323, and it says that incoming calls are not supported with incoming static-NAT.  Incoming static NAT is how Watchguard boxes handle incoming traffic (incoming connections).  
From Watchguard:

"Allowing this service inbound

In order to allow external clients to connect to H.323 systems behind the Firebox, an H.323 service icon must be added to the Policy Manager with appropriate incoming and outgoing rules. Note that this service does not work properly with incoming static-NAT, which means that if your clients are to accept incoming H.323 connections, they must have public IP addresses. This does not affect clients creating outgoing connections with private IP addresses. There are other video applications like CUseeMe that do work properly with an incoming static-NAT rule.

Allowing this service outbound

In order to allow your internal users to connect to other H.323 endpoints on the Internet, simply add an H.323 service icon to your Policy Manager configuration with the desired outgoing properties. This service works fine from clients with internal private or public IP addresses. The Firebox is able to follow the dynamic negotiation required for H.323 and route private IP address requests appropriately."


There may be a brute force (though extremely insecure) way to handle this.  You say you now have 2 public IP addresses.  Assign one of them to the watchguard's external interface, and the other to the polycom.  Buy a small 4 port or 8 port network switch.  Go to the wiring closet and find the ethernet interface that is your internet connection (WAN side).  Plug the internet WAN ethernet link into the switch.  PLug a patch cable from this small switch to the wathguard external interface.  Find the exact network drop that goes to the polycom, disconnect it from your production network switch, and plug it into the small network switch.  This places your polycom unit directly on the INternet, without firewall interference (or protection) of any kind.  If it doesn't work now, something else is wrong.

This should be seen as a temporary and last-ditch measure.  You may wish to explore the security features of the polycom (which don't look very robust).  It probably means that anyone who hits your IP address will be able to connect, whether you want them to or not.  This does NOT expose your production network, just the polycom unit.  Try it and let me know what happens.

Thanks again for the reply StonewallJacoby.

I went ahead and set all the public info on the Polycom and bypassed the firewall. First try I was connected fully and able to see into Polycom's office! So it does in fact work, it's just proof that the firewall is causing problems. I honestly don't know what else to try, and I think you're correct in assuming that this probably isn't going to work without bypassing the firewall altogether-something we'd definately like to avoid.

According to the wording in that first article you quoted about inbound H.323 connections, do you think it would work to assign the Polycom the public IP address, leave it behind the firewall, remove the alias from the external port and do a manual route instead?

Here's the problem: Even if you could do that, you would still be effectively bypassing the firewall by routing traffic from that public IP to the polycom.  ANyway, I don't think the watchguard box will tolerate having IP's from the same subnet on two different interfaces (in your case, trusted and external).  



Are you trying to host videoconferences?  Are you trying to videoconference with just one other location?  If it is just one other location, then consider setting up a VPN tunnel between your partner and yourselves:
http://www.h323forum.org/papers/polycom/DeployingSecureIPVideoNetworks.pdf#search=%22polycom%20video%20conferencing%20authentication%22


Maybe you should investigate polycom's videoconferencing gear related to hosting, authentication and security, etc.  See the third article on this page:
http://bcisdvcs.wordpress.com/tag/rus-grant/


hmmmm...I just found this....
"A common problem with VC through NAT is that the H.323 payload itself makes a reference to the inside IP address of the VC system. In other words, the system that you are making a call to on the other side of the firewall will try to send the return streams to an unroutable IP address.

There are a few ways of overcoming this. Both Polycom and Tandberg (and others) for example allow you to configure your system so that it uses the outside NAT'ed address rather than its private address in the payload."

I remember something from your polycom setup where you can tell the polycom unit the outside (public IP) address it will use.  This must be for the reason stated above.  (That part of the polycom setup is on pages 3-16 and 3-17 of the downloadable polycom manual "Administrator's Guide for the VSX Series Version 8.5").  Try configuring the H.323 proxy on the watchguard with incoming and outgoing rules allowing traffic to and from the NAT (inside) IP of the polycom to / from "Any".  Configure the polycom "NAT Configuration - Manual" and "NAT Public WAN Address - your public IP".

If that don't work, I don't think it's gonna.

As a compromise, try setting up an ANY rule for the Polycom but still using the 1-1 NAT exceptions procedure I described earlier.  It may well be that the Firebox, in acting as H323 proxy is indeed causing problems with outbound traffic.

Thanks for the replies you two.

StonewallJacoby:
I tried using the NAT transversal thing, which allows me to set the polycom to report the public IP as its personal IP and it continues to be be a one way conversation.

hstiles:
I tried setting the Any rule and trying it, and it still gave me the one way viewing, so then I enabled the 1-to-1 Nat without changing anything and it wouldn't let me connect at all. But in enabling the 1-to-1 NAT, I did have to enable the Exceptions to Dynamic Routing or it would ignore the 1-to-1.

We use an application that sends a simple outbound wakeup packet to an external host.  This packet needs to come from the actual NAT base IP not the external IP of the Firebox.

Therefore I would assume that this configuration is similar to what the Polycom requires.  Using the H323 proxy may complicate matters because the Firebox may be masquerading as the Polycom device.

I would therefore hope that an ANY rule, in conjunction with 1-1 NAT and a dynamic NAT exception would solve the problem.

If not, I can't think of what else you can try.

Yeah, I tried your last suggestion hstiles, but dynamic takes precedence over 1-1 and then just gives me the original problems. We decided the only solution was to switch it before it hits the firebox, then run a dedicated line to the conference room. Thanks all for your help anyway.

I too ran into this same problem witrh an X1000 and X1250e, my solution was simple, remove one of the public IPs from the alias table, install a 5 port switch in front of the firebox, then connect a residential Netgear router to the switch, setup the Netgrear with the removed public IP and a different subnet for the LAN interface, connect that to my LAN, and set the VC system to this other subnet, works great!  Costa few dollars more but no issues since I did this.  This also protects your VC system from sitting directly on the internet.