Firewall Configuration Problems

By Brian Boguhn
Updated: August 29, 2011

Firewalls have come a long way. At one time, configuration was strictly text based, with the administrator typing in line after line of code to program the system properly. Today, graphical user interfaces (GUIs) exist to make the configuration process easier. That said, configuration issues can still occur even for the seasoned network administrator. This article will point out some issues that administrators have run into and talk about how they can be avoided.

HTTP and HTTPS

This one happens all the time. The firewall gets configured to allow HTTP traffic (port 80) through. Invariably, though, there is a server that requires HTTPS (port 443). Let’s say it’s an Exchange Outlook Web Access (OWA) server. A user on the outside will go to access the URL for the OWA server and won’t be able to reach it. The administrator missed the need for port 443 to be open. Opening port 443 resolves the issue immediately.

E-mail and ESMTP

This one isn’t so common, but with a Cisco PIX it can be a problem of which administrators should be aware.

The issue that will be seen is that an outside sender will report that e-mails to some of your users will often bounce. At other times the messages will go through without issue. What is going on behind thefir scenes is that if Transport Layer Security (TLS) encryption for e-mail communication is being used, then the ESMTP inspection feature (enabled by default on the PIX) drops the packets. The sender retransmits until it gives up, resulting in the bounce message. To resolve this issue, disable the ESMTP inspection feature.

Note that this is an issue with PIX firewalls running only certain firmware versions.

Incorrect NAT Configuration

Network Address Translation (NAT) involves configuring the firewall to recognize that an IP address on the internal network corresponds to an external address on the Internet. For example, an Exchange server running OWA will have a private address on the internal network, but it will also have a public address for the Internet so that users can access it from outside of the company. The firewall is programmed to translate between the two addresses, making sure that traffic from the external address is directed towards the proper internal address, and vice versa.

The issue that can arise with NAT is that one or both of the IP addresses programmed in for the translation could be incorrect or keyed in improperly. Results can be mixed. A user might see the proper initial contact, but not get a response. Or, no contact can occur at all. The easiest way to address this is simply to make sure that all of the addresses used are correct, that they are entered into the firewall correctly, and that they correspond to the proper address on each side.

IP Address Conflicts

This can occur if an IP address already in use in the internal network is assigned to the internal port of the firewall, either accidentally or because of lack of network documentation. Results in this case can vary wildly. The firewall may appear to be operating correctly as far as it is concerned. However, there could be disruptions in e-mail, web access, and other services the company relies on. Determining that an IP address is indeed the problem isn’t as straightforward as the other issues discussed above. In this case, if the firewall was working properly and some work was done which resulted in the issues occurring, backtrack through what was done and the address conflict should be apparent. The network administrator may even realize immediately that an incorrect address was used. If not, examining error logs will be the best solution in this case to identify and correct the error.

Be Prepared

This is obviously only a very small sampling of the configuration issues that can occur on a firewall. The key is to be prepared to address a configuration issue if one does occur. Make sure the network administrators are well versed in the equipment being used. Have current support contracts with the firewall vendor. It would probably also be wise to have contact with a third party consulting firm that can assist if a large issue occurs. Not every firewall problem that occurs is going to be like one that was encountered by someone else before. Having resources to fall back on when an issue does occur will be the difference in a company staying online and in business, or going dark until the issue is resolved.