Deploying Crystal Enterprise with an IP Packet Filtering Firewall

Earlier this chapter noted that IP Filter firewalls restrict network traffic based on IP address and port number. Crystal Enterprise works well with IP Filter firewalls with the proviso that the IP address and TCP port number used by the servers are predetermined. This section discusses a scenario where the Crystal Enterprise WC/Web server and WCS has one IP Filter between the two of them and the WCS is separated from the rest of the Crystal Enterprise servers by a second firewall. In other words, its the common firewall scenario you looked at in the previous section. This is illustrated in Figure 26.5.

Figure 26.5. IP Filteringfirewall definition.

Lets look at two distinct parts of communication across the networks: first, the most external portion (that is, between Network C and Network B), and second, the communication between the WCS and the other Crystal Enterprise serversthe internal portion between Network B and Network A (see Figure 26.6).

Figure 26.6. Configuration with IP Filteringexternal firewall.

An External Packet Filtering Firewall Scenario

Any requests of the WC machine would follow the same steps as described in the previous section. Initially, the WC would have to establish a TCP connection to the WCS. The WC would initiate this handshake communication. The IP Filter firewall would certainly stand to convolute this communication:

• Destination IP The IP of the WCS as determined by network name resolution. The lookup would occur on the side of the Web serverusually by a DNS server in this zone.
• Destination port The port to use for this communication is taken from the Registryits the value as entered in the WC Configuration dialog box in the Crystal Configuration Manager. By default, this is port 6401.
• Source IP:port The IP:port of the Web server/WC machine as determined by a call to the operating system.

The network rules of this side of the firewall will quickly determine that the destination IP of this request will have to go through the firewall. Therefore, the network forwards this TCP connection request to the firewall. The firewall then evaluates the information within the requestthe destination port and IP address, as well as the source IP and source port. The firewall must have rules that allow this connection to go throughit must accept requests for the WCSs IP from the WCs IP and the request must be on the specified port. At this point in the request, the firewall will have to allow traffic through it that follows this configuration:

• Source IP The IP of the WC/Web server
• Source port Any
• Destination IP The IP of the WCS
• Destination port 6401 (or whichever is the WCSs listening port)
• Action Accept

When the WCS receives this request, it must respond to it. It garners the information about where to respond from the information within the request. It takes the Source IP and Port and makes this the destination. Because this is a random port, the firewall must be configured to allow any ports to leave Network B and go to Network C. This is a generally accepted practicestrict port enforcement is done at the bastion host. Therefore, the firewall rules to complete this request should resemble the following:

• Source IP Any IP from Network B
• Source port Any
• Destination IP Any IP outside the network
• Destination port Any
• Action Accept

When the connection request gets through the firewall, the network resolution will determine that the destination is in Network C. The request will hit the Web server/WC. At this point, there is a TCP connection between the two machines, going through the firewall. The WCS will send the WC its IOR and the WC will close this TCP connection.

The IOR contains the IP and port on which the second connection will be made. The port number in the IOR will be one of many values depending on the existence or nonexistence of the -requestport xxxx directive on the WCSs command line. If there is a -requestport, this is the value that will be in the IOR. If there isn , it will be a random port as chosen by the WCSs operating system. Generally, a random port is not acceptable because administrators won enable their firewall rules to accept any ports from a specific IP.

NOTE

The Crystal Enterprise Administrators Guide suggests that the use of the -requestport option is required with IP Filter firewalls.

When this second connection is made, the -requestport directive should be set to a fixed port number and this port number should be accepted if the IP is from the Web server/Connector machine. This second TCP connection information will look like this:

• Destination IP The IP of the WCS as read from the IOR.
• Destination port The port as read from the IOR, the recommendation being to use the -requestport directive to define this value.
• Source IP The IP of the Web server/WC machine as determined by a call to the operating system.
• Source port The free port as returned by a request to the operating system.

The firewall will evaluate this request and the port will have to be open. As an example, if the -requestport directive uses port 3333, the firewall rules will have to look like this:

• Source IP The IP of the WC/Web server
• Source port Any
• Destination The IP of the WCS
• Destination port 3333 (or whichever is used with -requestport directive)
• Action Accept

The WCS will respond to this request on whichever port the Web server/WC found to be available. This will be allowed through the firewall because any port is allowed from the internal network to the external. There will then be an established connection between the WCS and the WC, and IP packets will be sent on this channel. The configuration of the firewall rules for an IP Filter firewall between a WCS and WC are summarized in Table 26.1.

Table 26.1. Firewall Configuration Rules

Source	Destination	Port	Action
Network B	Any	Any	Accept
IP of WC	IP of WCS	6401, -requestport	Accept
Network C	Any	Any	Reject

NOTE

When the WCS is started with the -requestport switch, this port will have to be open going from Network B to Network C for the IP of the WCS.

An Internal Packet Filtering Firewall Scenario

There are several servers in the Crystal Enterprise environment with which the WCS communicates. It must communicate with the CMS as part of logon/security procedures, while the Cache Server will also be involved in a communication with the WCS for report viewing requests. (Additionally, the WCS will communicate with the Input File Repository Server, where the report objects are maintained when the thumbnail of a report is displayed on the Web page.) Obviously, traffic to each of these servers from the WCS will have to be allowed by the IP Filter firewall (see Figure 26.7).

Figure 26.7. Configuring an IP Filteringinternal firewall.

First and foremost, the WCS will have to communicate with the CMS. The CMS provides the Name Service in the Crystal Enterprise environment. Without this service, the WCS will not be able to communicate with any of the servers. The CMS listens for requests on the port designated, shown in Figure 26.8 under the configuration tab in the Crystal Configuration Manager (the default value for this port is 6400).

Figure 26.8. This screen shows CMS port configuration.

Whenever the WCS needs to communicate with the Name Service of the CMS, it does so on port 6400 by default. The first time the WCS has to communicate with the Name Service is when it starts. When the WCS starts, it must register itself with the Name Service as part of its initialization process. This communication occurs on port 6400. A TCP connection occurs between the WCS and CMS for this to happen. The request will have the following information in it:

• Destination IP The IP of the CMS as determined by network name resolution.
• Destination port The port number of the CMS as defined in the SERVICES file.
• Source IP The IP of the WCS as determined by a call to the OS of the WCS.
• Source port A random available port as determined by a call to the OS of the WCS.

After the CMS receives this TCP connection request, it responds back to the WCS to complete the initial connection. This connection response contains the following information:

• Destination IP The IP of the WCS as determined by reading the Source IP from the TCP connection request.
• Destination port The port the WCS is using as determined by reading the Source Port from the TCP connection request.
• Source IP The IP of the CMS as determined by a call to the OS of the CMS.
• Source port A random port as determined by a call to the OS of the CMS.

After this initial connection is complete, the CMS sends the WCS its IOR. The WCS then closes the initial connection and establishes a connection to the CMS using the IP and port that is in the IOR. If the CMS is using the -requestport directive, this is the port that the WCS will use to initiate communication with the CMS. This second connection request will contain this information:

• Source IP The IP of the WCS as determined by a call to the OS of the WCS.
• Source port The port number of the WCS as determined by a call to the OS of the WCS.
• Destination IP The IP of the CMS as read from the IOR that the CMS sent to the WCS in the initial connection.
• Destination port The port the CMS put in the IOR. If using the -requestport directive, this is the port the CMS put in the IOR. Otherwise, it will be a port deemed available as per a request to the OS of the CMS.

The CMS responds to this request to complete the connection. This response contains the following information:

• Source IP The IP of the CMS as determined by a call to the OS.
• Source port A free port on the CMS as determined by a call to the OS of the CMS.
• Destination IP The IP of the WCS as read from the Source IP of the connection request.
• Destination port The port being used by the WCS as read from the Source Port of the connection request.

When this connection is complete, the WCS and CMS will hold it open and use it whenever communication between the two is required. From a firewall configuration perspective, two ports are involved in the communication between the CMS and the WCS: first, the port the CMS listens onthis is port 6400 by defaultand second, the port that is established as the main communication channel between these two processesthis should be the value as defined by the -requestport directive. The "rules" for the firewall configuration can be defined as shown in Table 26.2.

Table 26.2. Firewall Configurations Rules (Network A to Network B)

Source	Destination	Port	Action
Network A	Any	Any	Accept
WCS	CMS	6400, -requestport*	Accept
Network B	Any	Any	Reject

NOTE

When the CMS is started with the -requestport switch, this port will have to be open going from Network B to Network A for the IP of the WCS.

However, this is only one of three servers with which the WCS would need to communicate. Requests to the Input FRS and Cache Server would still need to be allowed through the firewall. The standard practice is when servers need to communicate with one another, they ask the Name Service for a copy of the IOR of the server they need to contact. To communicate with either the Input FRS or the Cache Server, therefore, the WCS needs to ask the CMS for information about the server to which it needs access.

When these servers start, they give the Name Service portion of the CMS a copy of their IOR. As the other servers require access to it, they ask the CMS for a copy of the IOR of the server they need information about. To determine the IOR of a given server, the WCS and CMS collaborate. When the WCS has a copy of the IOR of the particular server, it attempts to make a connection to the server using the information in the IOR. The information in the IOR contains both the IP address and the port to be used for communication and security information. If the -requestport directive is used, the port will be that defined port; otherwise, its a random port. When working with firewalls, the preferred method is to use -requestport so you can control on which port traffic will be allowed in. As a conclusion, therefore, the firewall rules between Network B and Network A would need to be set up as shown in Table 26.3.

Table 26.3. Firewall Configuration Rules (Network B to Network A)

Source	Destination	Port	Action
Network A	Any	Any	Accept
IP of WCS	IP of CMS	6400, -requestport for each of the servers (CMS, Input FRS, Cache Server)	Accept
Network B	Any	Any	Reject

The use of NAT within the IP Filtering firewall adds an additional level of complexity, something explored in the next section.