We install firewalls to prevent computers on the outside of the protected network from initiating connections to computers on the inside. The problem is that we sometimes WANT to allow computers on the outside to access services inside the network. Examples would be when we want to allow remote access to a computer, or when we want to make services (such as a web server, mail server, or ftp server) available to clients outside the network. VOIP and Peer-to-Peer protocols also require internal computers to offer services that can be accessed from the outside.

Offering these services means that we must "poke some holes" through our firewalls. We want to do this in a way that only allows the connections we want, but any "hole" that allows inbound connections can also be exploited by malicious programs.

The easiest way to get inbound packets through a firewall is to simply configure an inbound rule that allows packets that meet specific criteria to pass through. An example would be to allow incoming packets bound for port 80 to pass through the firewall so an incoming http connection can be established.

Most firewalls also provide Network Address Translation (NAT) or Port Address Translation (PAT), so firewall rules also need to change the packet's destination address to that of the internal host that is offering the service. This is generally known as "port forwarding". Incoming connections can be directed to any host that is offering a service on a well-known port. We can also move services to non-standard ports. This means that the connection can only be established if the connecting computer knows which port the service is running on.

Another common approach to solving this problem is to run a small program on the internal computer that maintains a constant OUTBOUND connection to server outside the network. This connection is established as soon as the computer boots. In this way, there is no need to allow an inbound connection. When we want to connect to the internal computer, we connect to the same server, which then relays communications.

NAT and PAT pose additional problems for IPSec, which has long been the preferred protocol for VPNs. IPSec and NAT do not work well together for two reasons.

1. The first one is that IPSec provides for message integrity, as well as confidentiality. When the IP address in the packet header is changed by NAT, this also changes the checksum for the packet. Since the checksum no longer matches the one calculated before the packet was sent, packet integrity has been compromised and the packet is dropped.
2. The second problem is that when the Encapsulating Security Protocol (ESP) is used, the packet headers are encrypted. The NAT service cannot change encrypted headers. The typical solution to this problem is to encapsulate the entire IPSec packet inside a UDP packet, which is then routed to the destination machine and un-encapsulated. The "IPSec Passthrough" feature on many routers automatically opens the UDP ports necessary for IPSec NAT traversal. As discussed in the series on VPNs, this IPSec / NAT incompatibility is the main reason that SSL VPNs have become more common and IPSec VPNs are falling from favor.

There are at least five or six methods of NAT traversal, and the discussion above is greatly simplified. If you really want to dig into the details of NAT traversal, here is a Wikipedia article with links to the relevant RFCs and other articles describing the details of each method. Have fun nerding it up.

Next: Part 8 - Outbound Firewalls

Dennis H in West Virginia, US

January 26, 2009