Transport Proxies Performance Issues

The other end of the firewall spectrum from packet filtering firewalls are those that make use of application-level and transport-level proxies. These proxies operate at layer 4, where TCP and UDP sit, or higher. NT-based firewalls use protocol specific proxies to link inside and outside users.

In some cases, typically FTP or HTTP, the proxy knows something about the data and may do some additional processing based on the application being run through the firewall. For example, an FTP application-level proxy might allow users to pull files into the secure network, but not to push them out; or an HTTP proxy might silently filter out any Java programs from pages going through the firewall. For most other protocols, the proxy simply passes the data through the firewall without modification. This kind of proxy is often called a “plug gateway,” because it plugs a data stream through the firewall.

---

Note:  A third kind of transport proxy technique, SOCKS proxies, was not part of these performance tests because it is not available on Windows NT.

---

Raptor’s Eagle and Digital’s AltaVista Firewall are two firewalls that rely on application and transport proxies to secure networks. They include many application-specific proxies, such as Telnet, FTP, HTTP, and an SMTP relay. Both also include a generic TCP-level proxy (plug gateway).

Global Internet’s Centri is primarily an application-level firewall. Centri includes the same standard set of proxies and SMTP relay along with limited, simple packet-filtering capabilities. At the same time, Check Point’s Firewall-1 is primarily a packet-filtering firewall, with application-level proxies (Check Point calls them “Security servers”) for FTP, HTTP, and Telnet thrown in. Most networks that fit Firewall-1 wouldn’t necessarily also want the proxies, but Opus One tested both modes just for completeness. These are used when the network security manager wants a higher level of security, such as content-based security, on one of the applications. Generally, these proxies wouldn’t be used in a Firewall-1 environment for application-level security.

One of the advantages of application-level proxies is that they make it very simple for the firewall to implement a NAT, or Network Address Translator, which changes IP addresses as they pass through the firewall. A client application may think that it’s talking to a server on IP address 192.245.12.255, while the real application is running at IP address 10.1.1.1. Because an application proxy really consists of two separate TCP connections bound together by a program, the firewall can hide IP addresses on the inside from being visible on the outside.

If internal addresses are unreachable from the Internet, this IP address hiding increases security. Many organizations choose to use the special unreachable addresses (often called RFC 1918 or RFC 1597 addresses) to make sure that a normal user cannot get packets through the firewall—by using addresses that have no route across the Internet backbone. Unfortunately, many TCP/IP applications, such as FTP, care about what IP addresses are being used—they can’t just be switched out with reckless abandon. In this case, the proxy must also modify IP addresses at the application layer. It is possible to implement a NAT at lower layers by simply switching IP addresses without changing application-layer data, but many applications will not work over such a NAT.

Table 7.2 summarizes the performance testing results on the firewalls. Where a firewall has both proxy and packet filtering capabilities, both were tested (or marked N/A if Not Available). The four tests (TTCP-1, TTCP-5, FTP-1, and FTP-5) are described previously in the section “Evaluating Firewall Performance.” The numbers in the table show throughput in MB/second for each firewall in each configuration.

---

Note:  All numbers are given in MB/second. “N/A” indicates the function either was not available or not tested. “Failed” indicates that the firewall failed to complete the test.

---