An employee’s laptop has made a connection to an unfamiliar domain; this was an encrypted connection, and a successful session was recorded in the firewall logs alongside an IP address and port number. That left the security operations center (SOC) with a somewhat straightforward issue: they know a connection occurred but they do not know what went across it.
What exactly is a proxy firewall, and how would this help? A proxy firewall will accept an incoming client connection and create its own outgoing connection to the desired destination. By sitting in the middle of these connections, it provides an opportunity for the proxy firewall to review traffic for the applications it supports and make determinations about which traffic to allow. Depending on its features and configuration, these determinations can be based upon who initiated the connection, what application created the request, or even what content is being requested.
How a Proxy Firewall Handles Network Traffic
Basic packet filtering checks information such as addresses, ports, and protocols. Stateful filtering also tracks connection state. A proxy firewall can go further by interpreting the application’s requests and responses.
For additional background on this distinction, this guide on what is proxy firewall explains the intermediary model and its relationship to application-layer inspection.
It Splits One Session Into Two
The employee’s computer is connecting to a proxy server, which establishes a separate connection to the destination server for this proxied transaction. Therefore, there isn’t a direct session between the client and the destination.
A proxy server can perform many services including validating incoming requests; validating outgoing responses; enforcing access policies (which can include rejecting the user’s request prior to connecting to the destination); and potentially concealing local IP addresses in order to provide additional security by preventing disclosure via HTTP headers or other communication methods. That concealment depends on the headers and settings in use.
It Interprets Application Behavior
An HTTPS connection may carry an application used in a legitimate business environment, an unauthorized download, or malicious traffic. A single port number will not tell an investigator what type of data was transferred.
A proxy server that supports the appropriate protocol (for example HTTP) can look at each detail of the URL, method, header, and file type. Some organizations authorize their proxies to decrypt and inspect TLS traffic before it is re-encrypted and forwarded on to another server. A proxy server that simply forwards encrypted traffic without decrypting it will not allow the investigator to see the application content within the encrypted traffic.
When setting up your inspection criteria, you should take into consideration certificate management, the protection of confidential information, legal restrictions regarding privacy, and compatibility issues with certain applications. While enabling decryption throughout may protect against malicious activities, this action may disrupt legitimate services and may expose the organization to confidential information they have no reason to inspect.
It Applies Policy Before Forwarding Traffic
The policy decision may consider:
- User or device identity
- Requested application or destination
- Content type and file characteristics
- Authentication status
- Time, location, or network segment
- Known malicious indicators
- Data movement rules
All traffic will need to be compliant with relevant policies prior to being forwarded. Logs from such transactions can be used by investigators to determine what request was made of the network, which policy was applied to that request, and how the request was permitted or denied. This level of detail will depend upon the type of inspection that the proxy performs, as well as the configuration of the proxy for recording.
Proxy Firewall Strengths and Trade-Offs
The attraction is better control over application traffic. The cost is extra work for the equipment and the people running it. Both sides need to be considered before making the proxy a dependency for everyday business services.
| Aspect | Strengths | Trade-Offs |
|---|---|---|
| Traffic inspection and control | Examines application-layer activity, rejects malformed requests, restricts unsupported commands, and applies policies using user and application context. | Content buffering and detailed inspection can add latency, particularly for large transfers, interactive applications, and encrypted sessions. |
| Visibility and investigation | Produces richer records, including requested domains, URL categories, authenticated identities, file actions, policy decisions, and permitted or blocked activity. | Higher log volumes may increase storage and analysis demands. TLS inspection also introduces certificate, privacy, compliance, and cryptographic overhead. |
| Architecture and operations | Separates internal clients from external destinations, conceals internal addressing, and blocks prohibited requests before forwarding them. | Unsupported protocols may fail or require exceptions. Poor capacity planning can also turn the proxy into an availability chokepoint. |
These are potential capabilities rather than a feature list shared by every product. Protocol support and configuration determine which are available.
Where Proxy Firewalls Fit in Enterprise Architecture
Start with the traffic path. A proxy that works well for employee browsing may be unsuitable for a sensitive internal application with strict timing requirements. The useful question is where mediation will reduce risk without making the service unreliable.
Controlling Outbound Web Access
Forward proxies handle connections from users or workloads to external services. With the appropriate security features enabled, they can restrict destinations, enforce acceptable-use policies, inspect downloads, and help detect sensitive information leaving the business.
Australia’s gateway technology guidance discusses web proxies alongside other gateway services and stresses that gateways remain only one part of an organization’s people, processes, and technology.
Protecting Published Services
Reverse proxies receive requests for servers. They can also perform some type of authentication, rate limit access to your server, check protocols in use by clients accessing your server (e.g. HTTP/HTTPS), or apply restrictions to a specific web application. For these controls to work, origin servers should receive connections from users solely via the intended proxy path.
While a reverse proxy and a web application firewall have many similar characteristics, they are two distinct concepts. Reverse proxies handle the routing of client to server connections, whereas web application firewalls look for and block attacks against a web application. A company could possibly offer one product which combines all features as well.
The UK Government Digital Service recommends application-layer protection as one part of layered web security, backed by testing, patching, logging, threat modeling, and incident processes in its web application firewall guidance.
Segmenting Sensitive Systems
Internal network zones can have proxy-based controls between them as well. These will allow for a limited path to an internal, sensitive service (one which would otherwise be accessible to too many clients).
You should test this behavior in your specific use case. There are older systems using protocols that may not support a proxy, while some operational technology depends on easily disrupted communication patterns. Both of these can make it difficult to implement an intermediary. The assumption that you can insert an application-aware intermediary into your communications stream and expect it to behave like a transparent network device is incorrect.
Proxy Inspection Decision Snapshot
| Traffic scenario | Likely inspection approach | Main consideration |
|---|---|---|
| Privileged administrator browsing | Strong proxy controls | Credential theft and command-and-control activity |
| General employee web traffic | Policy-based inspection | Performance and privacy balance |
| Certificate-pinned application | Exemption or alternative control | Application compatibility |
| Sensitive internal service | Restricted proxy path | Segmentation and identity |
| High-volume media traffic | Lighter inspection | Capacity and latency |
Treat these as starting points for a review. A high-volume stream still needs a risk assessment; volume alone is not a reason to bypass inspection.
Questions to Put on the Architecture Review Agenda
Before approving the deployment, security and network teams should answer five questions:
- Which traffic genuinely needs application layer mediation? Start with privileged users, sensitive data paths, high-risk destinations, or tightly regulated workloads.
- What encrypted traffic can be inspected lawfully and safely? Document exclusions for health, financial, employee, and certificate-pinned services.
- What happens when an inspection fails? Decide whether traffic fails open or closed, then test the security and business consequences of both.
- Can the platform sustain real traffic patterns? Measure latency, concurrent sessions, file sizes, cryptographic load, and peak demand. Datasheet throughput alone won’t settle the question.
- Will the logs help the SOC? Confirm that identity, policy action, application details, and timestamps reach the monitoring platform in a usable format.
Then run a pilot with production-like traffic. Include software updates, video calls, large downloads, API connections, remote workers, and the legacy applications people still depend on. A quiet test window won’t tell you how the system behaves when everyone signs in on Monday morning.
What a Sound Deployment Looks Like
A sound deployment will not include every piece of traffic in the deepest level of inspection. Traffic is classified by teams; greater controls are applied when there is risk of exposure; and documentation is done for those cases (exceptions) where inspection creates privacy, legal, or technical issues.
Teams also need to continue their work. They need to audit bypasses, update certificates, find out why things failed, adjust rules, and keep an eye on capacity. If they don’t do this, exceptions put into place to solve a temporary issue can become permanent.
When a proxy firewall is used to make a needed path of traffic more observable and controllable, the benefits from using the proxy firewall depend upon understanding what type of traffic the proxy can inspect, testing what happens if the proxy or its inspection fails, and making sure that teams are assigned to be responsible for maintaining the proxy after its initial deployment.