Multimedia support through a firewall is tricky for two main reasons.
The first is that a firewall often does NAT for the RFC 1918 addresses sitting on the private network behind it. Because many multimedia applications embed IP addresses in some of their payload packets, the firewall has to dig into the packet and change these IP addresses as well in accordance with the NAT rules set up on it.
The second reason why supporting multimedia traffic is often difficult is that many multimedia applications, instead of using fixed and predetermined port numbers, actually negotiate the port numbers that are to be used for the data to be transferred. This creates problems because the firewall must create address translation entries for these ports. It also causes problems because the firewall often must take into account the fact that as soon as the multimedia client sitting behind it has initiated a connection to a multimedia server, the server might try to establish an independent connection back to the client on the negotiated port. The firewall must open a hole for that connection to take place based on the negotiation that took place between the client and the server.
Figure 8-7 illustrates the two problems just discussed.
A good example of one such implementation where PIX has to take care of a complicated transaction between a client and a server is the implementation of VoIP using H.323 with GK (Gate Keeper) or a proxy server with SIP. VoIP deployments usually involve many endpoints, and customers often have limited IP addresses for each of these endpoints, resulting in a need to do PAT. Adding support for PAT with H.323 and SIP allows customers to expand their network address space using a single global address.
To support PAT with the H.323 or SIP fixup, first the correct PAT for the embedded IP/port in the H.323/SIP message needs to be found and the embedded IP address must be changed in the payload. Then the correct media connections based on the ports that were negotiated during the signaling need to be opened. If a PAT does not exist, one needs to be created. A PAT does not exist if there has been no outbound traffic from that particular host on a particular port. Or perhaps a PAT did exist but was torn down because it expired or was removed by the user. This leads to another problem where the clients register with either the proxy server (for SIP) or the GK (for H.323). The registrations tell the proxy server or GK that the client can be reached at a certain IP address/port. These registrations last for a specific timeout value determined by both client and server. This means that PIX must sniff this timeout value from the negotiation between the client and the server and modify the dynamic PAT timeout value on itself to match this VOIP timeout value.
Figure 8-7 PIX Multimedia Support: Two Main Issues and Their Resolutions Problem 1
Was this article helpful?