From "Brien L. Wheeler" Organization Raptor Systems, Inc. Date Mon, 29 Dec 1997 12:31:57 -0500 Newsgroups comp.security.firewalls Message-ID <34A7DE8D.5493@raptor.com> References 1 Michael Pelletier wrote: > We've been very sucessfully running an application-layer firewall > here, and preventing any routing of internal traffic to external > sites, and vice versa. Everything goes through the application-layer > firewall. However, there's been growing demand for services that > require direct connectivity between the machine inside our network and > the outside world, such as Microsoft NetMeeting, and which don't have > a application-layer proxy (like RealAudio does, for example). > > As a result, I'm trying to figure out what the best approach to > allowing a strictly-filtered route from internal machines out to > the Internet would be. I would plan to leave the application-layer > gateway in place, and only allow very specific ports in or out through > the new packet filtering path, according to specific requirements > of the different applications. > > Would it make sense to install routing and packet filtering on the > application-layer gateway itself (it's a BSD/OS Intel box), or would > it be best to obtain and install a separate router? What security > and performance considerations are involved there? Mike, Lest anyone cry foul, let me say right up front that I work for Raptor Systems, but I have tried to keep this vendor-neutral. As always, judge for yourself... Your problem does not have an easy "one-size-fits-all" solution. You might have to make some uncomfortable decisions to get the functionality you want. You mention NetMeeting, so I'll discuss that application in particular -- other applications may be easier depending on the details of the protocol. NetMeeting is really a combined H.323/T.120 endpoint implementation. H.323 provides audio and video conferencing and T.120 provides data conferencing (whiteboard, chat, application sharing, and file transfer). Audio and video data streams are established as follows -- the endpoints first create a TCP connection on well-known port 1720. This connection (the Q.931 connection) is used to negotiate a second TCP connection (the H.245 connection). This H.245 connection is then used to negotiate addressing for UDP-based RTP/RTCP audio or video data streams. The T.120 connectivity can be established two ways -- on well-known TCP port 1503 or negotiated via the same H.245 connection that is used to negotiate the audio and video streams. Essentially, when you use NM (version 2.1) to call someone, it tries to create a T.120 connection on TCP port 1503 and an H.323 connection on TCP port 1720. If the T.120 connection fails, NM will fall back to using H.323 to negotiate a different connection address for data conferencing capabilities. This channel address negotiation makes static packet filters difficult if not impossible to configure for NM. If you just want data conferencing, then allowing connections to TCP port 1503 may be sufficient because all data conferencing takes place on a single TCP connection (although I haven't tested how NM reacts when it can't establish the H.323 connection). If you "need" audio and video conferencing, you are really in a pickle because not only are the UDP audio and video streams negotiated, but so is the intermediate TCP H.245 control channel. You would essentially have to open up almost all TCP and UDP connectivity for a given host to allow complete NetMeeting support (and we all know what a bad idea this is). Your best solution would be if your firewall vendor came out with an H.323 proxy -- this would allow secure operation of NetMeeting through the firewall by interpreting the address negotiations and only opening up addresses actually used by the communicating endpoints. Barring that, you might try a T.120 only solution on TCP 1503, but I would not recommend attempting full-blown H.323 without an application proxy or a seriously critical inspection of any packet-filter solution (stateful or not). Of course, there are other questions involving your addressing architecture (public vs. private addresses) and routing infrastructure that need to be considered in deploying a complete solution... Best of luck, Brien Wheeler Principal Engineer Raptor Systems, Inc.