Exploring the NAT and Crystal Enterprise Relationship

It has been established that within Crystal Enterprise, server-to-server communication takes the single TCP connection approach one step further. A second TCP connection is made when servers communicate in Crystal Enterprise (listen on one, communicate on another). When it comes to firewalls, it is important to recognize that two ports need to be open.

However, with translated IP addresses in the NAT instance, there is an additional concern because it is the IOR that tells the servers which IP to use; this is not directly retrieved from the packets themselves. This section explains what is required to make Crystal Enterprise work with a NAT firewallthe WC and WCS communication as an example.

When the WC communicates to the Web server, it is on the outside of the firewall. This is how it will be in most configurations and the assumption made during this chapter. The WC/Web server will reside in a DMZ and the rest of the servers inside the corporate network. As before, when the WC needs to communicate with the WCS, it will send a TCP Connection request. To get there, it will need to resolve the name of the WCS machine. Because the WCS is inside the firewall, this can potentially create a problem with a NAT firewall. As you saw with the Telnet example in the previous section, generally the incoming rules for NAT firewalls only accept packets with destination IPs going to the firewall.

In the Telnet example, the client was inside the firewall and the outbound firewall rules allowed all IP destinations outside the wall, as well as any port (this is normal). The NAT firewall then altered the packet and sent it onto the Telnet server. The Telnet server responded back to the firewall. The firewall was expecting the response and allowed it through because it was expected. The NAT firewall altered the destination of this response back to the internal private IP of the Telnet client and routed it onto the Telnet client machine.

In Crystal Enterprise, the WC needs to send the initial TCP Connection request to the WCS. This is somewhat different from the Telnet application because the machine in the external network (the WC) is initializing the communication instead of the machine inside the network. Because the request didn originate inside the firewall, the firewall isn expecting any communication. When the WC resolves the machine name of the WCS to an IP address, this won always be the IP as it exists on the internal network in a NAT environment. There are a number of options available where the features of NAT firewalls could be configured to work in this situation:

• The NAT firewall could be configured to allow packets whose destination is the firewall.
• The NAT firewall could be configured to allow packets whose destination is inside the firewall and have rules on which of these are allowed.
• The NAT firewall could use a group of IP addresses in the external network that each represents one IP address in the internal network.

There is still one outstanding question, however: To which IP address should the request be sent? Crystal Enterprise requires that the machine on the outside of the firewall be able to send packets to the private IP address of the WCS. It might be possible to get away with not using the private IP address for the initial connection; if the initial connection request was sent to a statically mapped IP address or to the IP address of the firewall itself, the firewall could inspect its destination and forward it on without issue.

Remember that the data that is sent in the initial connection from the WCS to the WC is the IOR of the WCS. The IOR contains the IP address and the port of the WCS. Moreover, this is the internal IP address of the WCSit is not the address of the firewall or a static IP address of the firewall that is mapped to the internal IP address. To allow this traffic through, therefore, on a NAT firewall, the rule that needs to be in place for WC to WCS communication is that the packets to the internal IP address must be allowed through the firewall. (This might, of course, require further rules to route these packets on the firewall.)

The ports that are allowed through can be narrowed, of course. The destination port on which the WCS is listening and its request port need to be allowed through the firewall. In the end, the firewall rules with a NAT firewall are pretty much in line with what the firewall rules are on an IP Filter firewall. For example, Table 26.4 assumes the WCS is inside the network and the WC is external to the network.

Table 26.4. Firewall Configuration Rules (WCS Internal and WC External)

Source	Destination	Port	Action
Internal IP of WCS	External IP of WC	Any	Accept
External IP of WC	Internal IP of WCS	WCS listening port (6401 by default), -requestport	Accept
External Network	Internal Network	Any	Reject

If packets from the hosts on the external network sent to the internal IOP addresses are routed to the firewall and the firewall accepts the packets, the connection will be established successfully. Given that in many cases the external network is a DMZ and the firewall is a router on the LAN, this configuration is possible by adding static routes on the hosts in the DMZ to the firewall. Depending on network configuration, even static routes on the hosts won be necessary if the firewall between the internal network and DMZ is the default route for all traffic.