Firewalls In General Firewalls sit between two or more networks and mediate traffic. At least one network interface on the firewall contains private and trusted resources and the others are public, containing malefactors against whom the firewall provides protection, or semi-public/private, containing web servers, remote access servers, etc (these networks are generally referred to as 'service networks' or 'DMZ's, though the latter is deprecated due to ambiguity). There are generally two kinds of firewalls which can be deployed to provide network protection: Application Proxies and Circuit Layer Gateways.
 To fully comprehend firewall protection mechanisms, it's important to understand the network layers at which firewalls operate. The following is the familiar diagram of the ISO 7-layer network model, describing where in the stack different IP functions are handled:

SMTP, HTTP, etc.

7

Application

Application Proxy

6

Presentation

5

Session

TCP/UDP

4

Transport

Circuit Layer Gateway

IP

3

Network

Packet Filter

2

Data Link

1

Physical

Packet Filters & Circuit Layer Gateways Packet Filters are usually implemented in routers. In times past, they only had access to layer 3 information, or simply the IP packet, and not layer 4 information. In most modern implementations, they have access to both layer 3 and 4 (Network and Transport) information.
Circuit Layer Gateways also have access up to layer 4. These include firewalls such as CheckPoint Firewall-1/VPN-1, Cisco PIX, and NetScreen.
In both modern routers and Circuit Layer Gateways, since they have access to layer 4, they can make basic authorization decisions based on source and destination IP address as well as protocol type and port (e.g., tcp/80 or HTTP).
Application Proxies Application Proxies have access to the entire range of information in the network stack. This allows them to not only make decisions based on basic authorization (source, destination, and protocol), but also filter offensive or disallowed commands in the data stream.
To truly understand the security provided by an Application Proxy, it's useful to take a simple case of an application data vulnerability. In an early incarnation of sendmail, the original implementation of an SMTP mail server, a backdoor command was inserted to assist in debugging the application. SMTP is based on a simple, human-readable, text-based dialog between the client and server, using commands such as 'HELO', 'QUIT', and 'DATA'. The backdoor command was 'WIZ', which allowed the client machine to gain root shell access on the remote sendmail server.
Since neither Packet Filters nor Circuit Layer Gateways examine application data, they were vulnerable to this backdoor exploit. Essentially, this means that if you need to allow access to protected systems, you must accept the risk of possible vulnerabilities in application data.
With Application Proxies, commands can and are examined to protect against known data stream vulnerabilities. In addition, common application attacks are protected against, such as buffer overruns, illicit redirects, and other general-purpose bugs and exploits. With the most secure firewalls, such as the Axent Raptor Firewall, protection is provided from exploits before they reach the operating system's native IP stack. This provides security against port scans, Denial-of-Service (DoS) attacks (such as the 'ping of death'), and IP spoofing.
Stateful Connections One property of Application Proxies is that they keep 'state' of connections inherently. This simply means that when a packet attempts to pass through the firewall which matches an established connection which has satisfied the implemented rules, it is allowed. Contrasted with simple packet filters, this means that a rule only needs to be written to permit the 'direction' of the connection from the client to the server, and packets returning as part of that connection are allowed as part of the original rule.
Let's use some examples:
TCP is the easiest example to make since it is inherently stateful, or connection oriented. When a host wants to establish a connection to another, it must go through a negotiation process, known as the 'three way handshake', which establishes bidirectional communications between the two hosts. The host desiring to make a connection, let's say a Linux box running a browser, sends an IP packet with the SYN flag turned on in the header (needless to say, the IP protocol field contains the number 6 for TCP, and the encapsulated Transport layer information specifies port 80 as a destination). If the destination host agrees to establish a connection (e.g., it has a process listening on port 80/tcp and authorizes the connection), it sends back a packet with both the SYN and ACK fields turned on in the IP header. To finalize the connection, the initiating host sends back a packet with just the ACK flag present.
This negotiation is like a phone call: You call a friend and their phone rings (SYN); they answer it and say 'Hello?' (SYN/ACK); you then say 'Hi Herb, it's Beula!' (ACK). The protocol has been established, and you're now ready to have an interactive conversation. With Packet Filters, you must specify that not only is the initial connection allowed, which means from a random-high (1024-65535) TCP source port to destination port 80, but you must also explicitly allow the return connection, TCP source port of 80 to a random-high destination. With Stateful Connections, which include both Circuit Layer Gateways and Application Proxies, you need only specify the initial connection; the return packets are implied because there is state associated with them (the connection has already been authorized). As an additional technical point, all packets associated with a TCP connection have the ACK flag set, ostensibly to signify that their part of an established connection. From a security standpoint, though, this should not be trusted as it's trivial to set in an attempt to gain the trust of Stateful Inspection Engines.
UDP is a little trickier, because it's stateless. There is no three way handshake connection setup, but there are source and destination ports. So a Stateful Inspection Engine can authorize an initial packet (one that doesn't match an entry in its state table) based on source and destination address and port. Consequently, a DNS resolver packet, sourced on a random high UDP port destined for port 53 on a nameserver may be authorized and an entry made in the state table. When a packet from the the original destination, source on port 53/udp, and destined for the original source on the original random-high source port arrives, the Stateful Inspection Engine allows it through as part of the loosely 'established' connection. It determines when a connection has ended by a specified timeout period instead of the presence of a FIN or RST flag in an IP header for TCP.
For non-TCP or -UDP packets, special configurations must be defined. For example, ICMP echo_reply packets are considered a stateful return to an ICMP echo_request. This gets more complicated with protocols which rely on random ports. For example, active mode FTP (which is the default for most FTP client implementations except web browsers) establish a control connection from a random high TCP port to port 21 on the FTP server. For data transfer, including directory listings, the server initiates a new connection back to the client based upon data exchanged in the application protocol on the control connection. This data connection is sourced on port 20 and bound for the negotiated random high port, which a firewall with no knowledge of the Application layer, can't predict in advance. This is where Application Proxies come back into the picture.
It's obvious, then, that Application Proxies are the only secure defense against the network perimeter exposed to the Internet. For Intranet protection, this level of security may not be necessary, depending on the individual needs of the organization. In any case, products which started out as Circuit Layer Gateways, such as CheckPoint Firewall-1/VPN-1 and Cisco PIX, have responded by providing application proxies for common Internet services, such as SMTP, HTTP, FTP, etc. This acknowledges that Application Proxies are the only secure method of Internet protection.
Application Proxies (again) Obviously, It's imperative that functional firewalls understand certain application protocols, such as FTP, RealAudio, and SQLNet, in order to determine which protocols and ports should be allowed based on an initial connection, which establishes state. Consequently, all respectable Circuit Layer Gateways provide some sort of Application Layer scanning. CheckPoint calls theirs Security Servers, Cisco PIX calls theirs Fixup Protocols.
Performance Considerations Since there is always a trade-off, it turns out that in the case of firewalls, it's performance. Since passing traffic at layers 3 and 4 is clearly faster than passing it all the way up the stack and back down again, manufacturers of Packet Filters and Circuit Layer Gateways leverage this as fodder to promote their products. However, the issue is not as clear-cut as simple performance.
When viewed as a whole, Circuit Layer Gateways do not operate purely at layer 4, as discussed previously. Therefore, they've become hybrid software implementations to address the need for stringent Internet security. This technology, by the way, is generally marketed under vague terms, such as 'Stateful Multi-Layer Inspection', which simply means that the software operates at many layers in the IP stack. Obviously, since software is not passed exclusively through layer 4, but is often forced to the application layer (which is often for firewalls deployed at the border of the private network and the Internet), the performance benefits are not as great as marketing would have you believe.
Conversely, Application Layer firewalls do not solely function at the application layer. For example, in the Axent Raptor Firewall, it's possible to pass traffic through local-tunnels, a stateless layer 3 mechanism, or layer 4 Generic Service Proxies (GSPs with no application data scanning). The Axent Raptor Firewall can pass 50-90 Mbps of throughput with noticeable latency; whereas, Cisco and CheckPoint pass over 140 Mbps with less latency than an Application Proxy. In both cases, the firewalls are fast enough to saturate a T3 circuit, so a full T1 is easily handled.
Stability One other major difference between Application Proxies and Circuit Layer Gateways is that Application Proxies perform most of their operation in application space. Circuit Layer Gateways perform most of their operation in kernel space. If the program has a stray pointer or other coding issue, when operating in application space, the operating system will protect the system as well as other applications from the programming gaffe. When running in kernel space, coding issues run the risk of corrupting not only other kernel-level drivers, but also the operating system itself. Consequently, firewalls which are written primarily at the kernel level have a much greater chance of causing the firewall system to be unstable. They generally have a longer period of stabilization when released for distribution and a long and complex patch release history.
Most/all commercial Circuit Layer Gateways are written as a kernel level driver or complete operating system. Most Application Proxies are written for application layer execution, and the better ones have some kernel layer component to enhance security.
Summary / Utopia All things considered, the fundamental difference between Application Proxies and Circuit Layer Gateway firewalls is that Application Proxies are more secure and Circuit Layer Gateways are faster.
You'll hear many arguments of security vs performance; however, it all depends on your particular needs. In a perfect world, you'd have an Application Proxy securing your corporate network, the crown jewels of your company, so to speak; but a Circuit Layer Gateway to protect your corporate web presence without impeding performance.