What is a proxy firewall and how does it differ from other firewalls?

A proxy firewall, also called an application-proxy gateway, sits between two hosts and relays their traffic without ever letting them connect directly. Because it terminates each connection and inspects the content, it can enforce rules a packet filter cannot, at the cost of speed and flexibility.

How does an application-proxy gateway work?

NIST SP 800-41 Revision 1 describes it as a feature of advanced firewalls that combines lower-layer access control with upper-layer functionality. A proxy agent acts as an intermediary between two hosts and never allows a direct connection between them. Each successful connection attempt creates two separate connections: one from the client to the proxy server and another from the proxy server to the true destination. To each host it looks like a direct connection, and external hosts only ever talk to the proxy, so internal IP addresses are not visible to the outside world.

The proxy agent works with the firewall ruleset to decide whether traffic may pass. Some agents can also require authentication of each individual user, with a user ID and password, a hardware or software token, a source address, or biometrics.

What can it see that a packet filter cannot?

It operates at the application layer and can inspect the actual content of the traffic. The guide says it performs the TCP handshake with the source system and can protect against exploitation at each step of a communication, and it can allow or deny traffic based on information in application protocol headers or payloads. Some gateways can decrypt SSL protected payloads, examine them and re-encrypt them before forwarding, while data they cannot decrypt is passed through to the application.

What are the trade-offs?

NIST lists the disadvantages next to the advantages. Because of the full packet awareness, the firewall spends much more time reading and interpreting each packet, so some gateways are poorly suited to high bandwidth or real time applications, although high bandwidth models exist. A dedicated proxy server can take on less time sensitive services such as email and most web traffic to reduce the load. Support for new applications and protocols tends to be limited, since a separate proxy agent is needed for each type of traffic. Generic agents exist for undefined protocols, but NIST notes they tend to negate many of the strengths of the architecture because they simply let traffic tunnel through.

How is it different from a dedicated proxy server?

NIST treats dedicated proxy servers as a separate topic. They retain proxy control of traffic but usually have much more limited firewalling capabilities, so they are typically deployed behind traditional firewalls. A main firewall accepts traffic, decides which application is targeted and hands it to the right proxy, such as an email proxy, which filters or logs it before forwarding. An HTTP proxy for outbound web traffic is the standard example. NIST says dedicated proxies are generally used to decrease firewall workload and to do specialized filtering and logging that is hard to do on the firewall itself.

A constructed example

A hospital wants staff to browse the web but not upload files to unknown sites. A packet filter can allow or block a destination. It cannot tell a harmless page load from a file upload to that destination. A proxy in the path sees the HTTP method and the content type, allows reads, blocks uploads to unapproved categories, and logs the user who made the request. The same proxy cannot keep up with the imaging system's high speed transfers, so those flows bypass it through a narrowly scoped rule to a fixed destination. The exception is documented and reviewed.

How to check or apply this

1. List the traffic you want to inspect by content, and the traffic that only needs address and port rules.
2. Put content inspection where the policy needs it, such as web and mail, and use simpler controls for high volume flows.
3. Decide where decryption is allowed. Record what is excluded for legal or privacy reasons.
4. Require user authentication at the proxy so logs tie to people.
5. Avoid generic pass-through agents. Each one is a hole in the policy.
6. Test throughput with real traffic before production.
7. Keep the ruleset reviewed and short, and log every exception with an owner and an expiry date.
8. Use NIST SP 800-41 Revision 1 as the checklist for policy, testing and management.

Quick check

Sources

• NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy
• NIST SP 800-41 Rev. 1 full text (PDF)

Last reviewed: 18 October 2026.