I recently installed a Cisco Systems PIX 525 firewall for a client. This firewall has six active interfaces:
1. Internal (local)
2. Sales Department (local)
3. HR Department (local)
4. Internet (T1, remote)
5. Ticket Master (56K line)
6. Background Check Database (128K line, remote)
Because the configuration is so complex, I installed the PIX Device Manager (PDM), so the client can make simple changes to the firewall configuration without needing to call me. Although an experienced PIX administrator can probably make changes faster through the Telnet text-based interface, I installed the PDM, because I think that it’s initially easier to understand than the Telnet interface. Also, if you’re familiar with Cisco’s Internetwork Operating System (IOS) for configuring routers, the PIX syntax is just different enough to drive you bonkers.
After I installed the PDM, all was going well until I started to configure the firewall. I started with a basic rule from the internal network to the Internet. Although I created the correct rule, the rule didn't work correctly. In addition, when I created more than one rule, the description from the rule immediately above was moved to the rule below. This could have been a cosmetic problem, or a symptom of a bigger problem. I called Cisco and discovered that PIX IOS 6.3(1) has a bug when you use the PDM. IOS 18.104.22.168 fixes this bug. So I flashed the PIX and tried to access the Internet, but still couldn't. On a hunch, I erased the PIX configuration and started over, theorizing that the initial configuration was corrupted with the earlier version of the PIX IOS. After I rebuilt the configuration from scratch, the PIX started working.
I have a standing rule for all my clients: If an external digital line is connected to their internal network, the line must pass through the firewall. This setup provides some protection for the client and the remote company in situations in which the client or remote company gets hacked. Of course, I limit access to specific IP addresses when possible, and open only the necessary ports required for proper communication. Because the Sales Department is the only department authorized to connect to the Ticket Master Service, I decided to segregate the Sales Department onto a separate subnet. The same was true for the HR Department, which is the only department authorized to access a background check database via a private frame line. By segmenting the Sales, Ticket Master, HR, and Background Check line, the client has a centralized management point through the PIX firewall. Of course I created a rule on the firewall so only the Sales Department can access the Ticket Master 56K line, and only the HR Department can access the background check database on the frame relay line.
This client is running Windows Server 2003 and Microsoft Exchange Server 2003. The Sales Department has its own Exchange 2003 server (a domain controller—DC), and the HR users are on the same Exchange server as the rest of the company. This Exchange server resides on the internal subnet. As you know, quite a few ports must be open to allow proper Active Directory (AD) replication. Rather than create a group of open ports, I decided to allow all traffic between the DCs to simplify the PIX configuration. I could have limited the traffic to only the necessary ports, but at that point, the traffic between the DCs was almost wide open anyway, so I decided to let all traffic pass between the DCs.
During the testing phase, I had problems with the main Exchange server on the internal subnet communicating with the Exchange server on the Sales subnet. When I viewed the queues via the Exchange System Manager (ESM), messages had started backing up, and when I tried to force the connection, it eventually timed out. As you know, Exchange 2000 and later uses Extended Simple Mail Transfer Protocol (ESMTP) by default to transfer messages between Exchange servers in the same organization. I knew that a firewall rule wasn’t blocking port 25, so the mail should work, but it wasn’t. I called Cisco support, and was able to quickly resolve the solution. The PIX uses a SMTP Proxy that is turned on by default. This setup works fine for external SMTP mail traffic from the Internet, but it blocks messages between internal Exchange servers that use ESMTP. I opened a command-line and entered the command
no fixup protocol smtp 25
on the PIX to disable the SMTP proxy. The mail then started working again.
For any firewall configuration, I suggest you invest in a label maker and label each port on the firewall and each patch cable connected to the firewall. Using that approach, you should be able to properly reconnect each line to the proper port on the firewall. I also suggest that you label the front of the firewall with the name, IP address, and subnet mask. This lets you identify the IP addresses of the PIX firewall by simply glancing at the PIX box. Also, make sure you have a good backup of the firewall configuration, both in hard copy and electronic form.
On Windows XP you can use HyperTerminal as your Telnet interface, instead of entering telnet at a command prompt. Start HyperTerminal, and in the Connect using field, select TCP/IP (Winsock) from the drop-down menu, and specify the target IP address. HyperTerminal is a better interface than the Telnet text interface, especially if you want to capture information from a Telnet session.