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:

• Internal clients must be configured to use the Gatekeeper’s internal interface
• The Gatekeeper must be configured to listen on the internal interface
• External clients directly connected to the Internet (not behind a gatekeeper) must be configured to use the external interface of the ISA Server as their gateway
• External clients directly connected to the Internet can call an internal host by using the phone number the internal client registers with the Gatekeeper
• External clients that are behind their own Gatekeeper can call your internal users by their email address if a Q931 record has been created for your domain

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:

Protocol Rule:

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.

Questions Unanswered

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.