When ISA Server was in beta testing, and shortly after its release, there were a lot of questions about how the H.323 Gatekeeper worked. In the last several months I haven’t noticed many questions about the Gatekeeper. Perhaps everyone has got the Gatekeeper all figured out and there’s no reason to ask questions. Or maybe the Gatekeeper is so impossible to figure out that everyone has given up! Hopefully it’s the former and not the latter because the H.323 Gatekeeper is really cool and promises to find a larger place now that gratuitous travel can be a dangerous adventure.
The H.323 Gatekeeper is on optional component you can choose when you install ISA Server. You can use this feature to allow H.323 client applications such as NetMeeting to call external NetMeeting hosts on the Internet. NetMeeting clients on the Internet can also call internal NetMeeting hosts behind the Gatekeeper. The Gatekeeper mediates the communications between the NetMeeting clients and is responsible to call routing and call control.
Configuring ISA Server 2000 : Building Firewalls for Windows 2000
By Deb and Tom Shinder
It’s relatively simple to get the Gatekeeper working, but there are a couple of tricks. Once you have the tricks ironed out, you’ll have yourself a powerful audio/video conferencing tool.
Basic Laws of the Gatekeeper
First, some basic laws regarding the Gatekeeper:
Why Won’t it Work?
We had recently moved our own office from a 128K ISDN line to a full T1. Instead of moving the ISA Server that was connected to the ISDN line over to the T1, I decided to start from scratch. That way I could avoid issues that sometimes pop up when you change the external interface configuration. I wiped out the old machine and reinstalled Windows 2000 and ISA Server and installed the hotfixes. Everything seemed to work fine after doing some quick configuration.
The following are the changes from the default installation:
All IP Protocols outbound allowed for Domain Users
Site and Content Rule:
Added Site and Content Rule to block spammers and ad sites
Incoming Web Requests Listener:
Added two Incoming Web Requests listeners, one for each IP address bound to the external interface
Web Publishing Rules:
Added several Web Publishing Rules to publishing sites on the internal network
Web Publishing Rules:
Added several Server Publishing Rules to publish DNS servers and an internal SMTP relay on the internal network
Policy elements were created to support the rules. Note that Authentication was not being forced on the Outgoing Web Requests listener.
The H.323 Gateway was configured to listen on the internal interface of the ISA Server. A Destination was configured to make the internal interface of the ISA Server a Gateway or Proxy. I don’t believe this is required, but since Q289581 says to do it, I go ahead and do it anyway J. It also allows me to stick a graphic in here.
After setting up the Gatekeeper I tested it with a laptop with a modem dialed into another ISP. Over and over again, I would get the message that the call was rejected. What was really odd was that the call appeared to make it to the gatekeeper. However, once the Gatekeeper got the call, it immediately disconnected.
If that wasn’t enough, when I ran netstat -na I found that the connection was made but apparently not completed.
Can you guess what was causing the problems?
The Answer is Simple – Sort of
We beat our heads against the wall on this for about five hours straight. At about 3AM we all decided to give up and maybe cooler heads would reign in the morning. I started working on the problem on my own as soon as I got up and of course beat my head into the same dent that I created the night before.
Then something occurred to me. The setup I had on the previous ISA Server incarnation had a Protocol Rule that allowed All IP Traffic to everyone outbound. That worked for us because no one else came into our office, but when our son decided to move home, I figured that a certain level of accountability was required so while all outbound traffic was still allowed, the user still had to authenticate as a domain user (that way I could pin up reports of unsavory activity on the refrigerator door).
Apparently, the Gatekeeper doesn’t like this configuration. When I changed the access control for the All IP Traffic rule to allow everyone access, the gatekeeper started working again! However, the prospect of allowing all outbound traffic to everyone wasn’t very enticing since we have to deal with a college age kid who’s traffic I need to easily keep an eye on.
The solution was easy. All I need to do was create a Protocol Rule for the H.323 Protocol that allowed outbound access to everyone. That way I could continue to demand authentication for all protocols except for H.323. Since no one but Debi and I would use NetMeeting, I felt this was a safe configuration.
The real question is why doesn’t it work when access control is required? The NetMeeting clients were configured as both SecureNAT and Firewall clients. The Firewall client should have been able to authenticate with the ISA Server. The Firewall logs didn’t show anything instructive and in fact didn’t show any packets had been dropped. I also did a Network Monitor session, but that didn’t show anything useful either.
So, the celebrity challenge is to figure out if its possible to use the H.323 Gatekeeper and still allow outbound access control for the H.323 Protocol. I’ll keep you updated if I find anything helpful. If you find something, be sure to post your findings on the message boards!
I hope you found this article interesting and/or helpful. If you have any questions on the issues brought up in this article, please post them on the www.isaserver.org message boards. You can also write to me at [email protected] and I’ll get to you as soon as I can. Please put the title of this article in the subject line. Thanks! –Tom.