Showing results for 
Show  only  | Search instead for 
Did you mean: 

Web Gateway: Understanding Reverse Proxy


The idea behind a reverse proxy with McAfee Web Gateway is to make internal resources available to the public internet without compromising security. The added benefits are load balancing, caching, SSL encryption for servers that otherwise wouldn't be encrypted, and malware scanning and threat protection. My goal with this document is to provide a simple framework that can be expanded on to get a reverse proxy using McAfee Web Gateway up and running.


Here's a diagram showing the basic concept of a reverse proxy:





How do I get traffic to my reverse proxy?

The first choice that has to be made is how to get traffic to your proxy. In that regard, there are a few options:

  • You can modify the DNS record for the server to point to the Web Gateway. This is the preferred method.
  • A firewall can be used to Port Forward traffic destined for the server over to the Web Gateway for proxying.
  • The Web Gateway can be deployed in Transparent Bridge to intercept and proxy the traffic originally destined for the server(s).  Click here for more info on Transparent Bridge deployments,


Proxy Port Configuration

Two ports typically need to be enabled and listening in order to intercept web traffic - ports 80 and 443. Port 80 needs to be enabled to listen for normal HTTP traffic and port 443 is for HTTPS traffic. It is important that an asterisk be entered for 'Ports treated as SSL' for the port 443 configuration as we want all traffic that comes in on port 443 to be treated as SSL encrypted traffic.



Server Certificate(s)

A server certificate needs to be created that will be used to encrypt all traffic between the proxy and the end user. This certificate can be created right on the Web Gateway under Policy > Settings > Engines > SSL Client Context without CA. You could also import the certificate obtained from a certificate issuer or another source in the same location. Obtaining one from a trusted Certificate Authority would have the advantage that your end user browsers would automatically accept and trust this certificate.


Note that you can import multiple certificates, one for each server that clients would be accessing (i.e and In most cases where multiple hostnames would be proxied through the web gateway, it would be beneficial to use a wildcard certificate instead (i.e. *.company.local).

Also consider that clients might be accessing resources directly via their IP address and that might result in certificate name mismatches. This is a very unlikely scenario though.


You will need the certificate, private key and password if you wish to import the certificates. The certificates are created/imported under Policy > Settings > Engines > SSL Client Context without CA. Here you can see that I have a certificate for both the hostname and the IP.


Note: It is important to enable the option "SSL-Scanner functionality applies only to client connection"!  Enabling this setting allows the Web Gateway to immediately perform the ssl handshake with the client.



Reverse Proxy Rules (Framework)

Reverse Proxy rules require a few standard components that we will introduce here as a framework. A rule set to get you started is attached at the end of this article. Keep in mind that especially for reverse proxy deployments, rules and functionality will vary widely depending or your individual needs. The standard components explained below are meant to give you a starting point and guidance but not a complete reverse proxy setup.


Top Level Criteria

You'll want to add criteria on to the top level of the Reverse Proxy rule set so that it only applies to requests that come in to the reverse proxy ports. You'll want to do the same for your Forward Proxy rule set if your Web Gateway is serving both functions. For this example, I have created a list called 'Reverse Proxy Ports' and put the ports 80 and 443 in that list. The list is used as criteria for both the forward and reverse proxy rule set.  Note the difference in operators used below ('is in' vs 'is not in').



Redirection to HTTPS

One goal in this example is to always have the client talk to the Web Gateway securely using an SSL tunnel so that the traffic cannot be intercepted. We can do this by creating a rule that redirects all HTTP requests on port 80 to the original requested URL but this time using https:// rather than http://.



Client Context with Server Certificate and Content Inspection

This rule set will allow the Web Gateway to terminate the SSL Connection and issue the web server's certificate to the client. This is where we're going to use the certificates that were imported as a pre-requisite.


This rule set has two parts:


    1. Set Client Context: The rule is using the criteria 'Command.Name equals "CONNECT"' so that it only applies to the initial connection negotiation. We're restricting it to the CONNECT because the action is going to be 'Stop Cycle'. 'Stop Cycle' is used to allow the CONNECT to occur and establish Content Inspection so that we can see inside the tunnel. The Web Gateway will be the "web server" from the clients perspective.
    2. Enable Content Inspection: We need to have this rule to basically remind the proxy to continue the Content Inspection for all SSL traffic past the CONNECT phase.



Common Rules and Filters

This section is where you can define the same types of Common Rules and Filters as you would normally with a forward proxy configuration such as Progress Indication, Caching, Malware Scanning, etc. These settings are all optional and customizable to your preferences.



Prevent Open Proxy

It is very important to restrict access to your reverse proxy to prevent any internet user from using it as an open forward proxy. We can do this with a simple rule that checks to see if the request is for a resource that needs to be reverse proxied and if not then block that request. In this example I used the property URL.Host.BelongsToDomain.



Redirect to Internal Server

All of the rules up until this point are directly tied to the frontend configuration (client-->Web Gateway) of the reverse proxy. This section focuses on the backend configuration (Web Gateway-->internal server) of the reverse proxy.



You have many options in regards to how the traffic flow is handled. The entire communication can be HTTP or it can be HTTPS. It can also be HTTPS on the frontend while HTTP only on the backend, or vice-versa. You can configure this any way that you choose.


We're going to use the Web Gateway to take a requested URL and re-write it to reflect the internal server. We'll also re-write the host header at the same time in case the internal server is used to host more than one domain or site.  We can't re-direct the client to an internal resource that is not publicly accessible so we need to have a way for the proxy to retrieve it on behalf of the client.  Therefore, we're using the "Next Hop Proxy" event to fulfill the request with the box for 'Proxy style requests' unchecked. This allows the reverse proxy to retrieve resources from a destination that was not the original destination sent over by the client and send it back to the client as if it was.  Using the next hop proxy method also adds the benefit of load balancing and failover for the web servers if you add more than one next hop proxy definition.



HTTPS Example

This is an example where the proxy needs to connect to the internal server securely using SSL/HTTPS. Here, we are adding two events on to the rule - the first re-writes the URL Host to the internal host and the 2nd enables the next hop proxy event to fulfill the request. Note: be sure to uncheck the box for 'Proxy style requests'.



HTTP Example

This is an example of what the next hop proxy looks like when the server does not support SSL connections and the Web Gateway needs to talk to it using HTTP. Here we are switching the protocol to HTTP, re-writing the host to the internal address and fetching the content using the 'Next Hop Proxy' Event. Note: be sure to uncheck the box for 'Proxy style requests'.





I have found that most troubleshooting can be done using Rule Engine Tracing. Please see this document for more information: . Some examples of things you may have to troubleshoot are why you are receiving content from the wrong server, the SSL Handshake failing, or getting blocked by the Prevent Open Proxy rule.


  • "Page Cannot Be Displayed" (IE) or " (Error code: ssl_error_rx_record_too_long)" (FF) - Client Context is most likely not set correctly or Content Inspection is not being performed.
  • Web Gateway Block Page  - check to ensure that you have excluded any sites to be reverse proxied from the Prevent Open Proxy rule




We have now laid the foundation for a simple & secure reverse proxy rule set that should provide a framework to get you started with your own reverse proxy to suit your needs.


Here I have attached the rule set that you may use to import and get started: Reverse Proxy Starter Ruleset

Labels (1)

You should put a section in there that describes how you can use Geolocation to restrict Client.IP addresses from countries you don't want to receive traffic from.

in essence, you can set events to lookup the Client.IP like this:

Set User-Defined.SaveURL = URL

Set URL = "http://" + IP.ToString(Client.IP) + "/"

Set User-Defined.Client.Geolocation = URL.Geolocation<Default>

Set URL = User-Defined.SaveURL



i implemented the rule as described above. It´s not working for me.




Trace the rules and see what values you are reveiving for the Geolocation.

If ther is a device in front of the MWG, like a load balancer and the connection is NATted with the load-balancer's IP address, then this will not work. Client.IP would be the load balancer's address always and it would not lookup if it's a private IP range.



for testing i changed my setup in this way

Rule in my Ruleset: Just storing the Client.IP as URL.


Set User-Defined.SaveURL = URL

Set User-Defined.Client.Geolocation = "http://" + IP.ToString (Client.IP) + "/"

Set URL = User-Defined.SaveURL

Ruleset for Logging: I´m writing the User-Defined property Client.Geolocation into a log file.

Log File Entry:

[18/Mar/2014:16:36:38 +0100] "" 401 "GET https://MyServerAddress/ HTTP/1.1" "Business, Software/Hardware" "Minimal Risk" "" 2575 375 "Mozilla/5.0 (iPhone; CPU iPhone OS 7_0_4 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11B554a Safari/9537.53" "" "81" ""Geolocation:

As you can see the original client.ip was written into the Client.Geolocation user-defined property.

Afterwards i changed the rule a little bit:


Set User-Defined.SaveURL = URL

Set URL = "http://" + IP.ToString (Client.IP) + "/"

Set User-Defined.Client.Geolocation = URL.GeolocationForURL (URL)<CloudOnly>

Set URL = User-Defined.SaveURL

The Log now shows the Geolocation:

[18/Mar/2014:17:53:06 +0100] "thorsten" 200 "GET https://myATDBox/php/checkStatus.php?command=installation&_dc=1395161586665 HTTP/1.1" "Business, Software/Hardware" "Minimal Risk" "" 396 703 "Mozilla/5.0 (iPhone; CPU iPhone OS 7_0_4 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11B554a Safari/9537.53" "" "0" ""Geolocation: AT

Now only the blocking rule for some countries is missing. But i think i will make it. 🙂


Yes, that would be the way to do it.

They must have slipped in the URL.GeolocationForURL() in a recent version because i never saw that one before.

Good Find!

However, since they now did that, you do not have to save the URL and restore it anymore. You can just

Set myURL = "http://" + IP.ToString (Client.IP) + "/"

Set User-Defined.Client.Geolocation = URL.GeolocationForURL (myURL)<CloudOnly>


I just want to add the country Name to the LOG File. But i think i have a litte mistake. I donwnloaded a Geolocation ruleset from the community where any country based on this link is listed.

But the ruleset to find the country name in this list based an the country code is not working.

Do you have any hint for me?



i build the reverse proxy like described. My problem is that when i connect to an internal ssl website the MalwareAntiVirus section doesn`t seem to work. When i try to upload an eicar test virus the reverse proxy does not intervene.

Any ideas?




I'm trying to use this ruleset but is not working by default because the proxy redirects me to the internal IP. After catching the HTTP 301 and 302 responses and forging the packets, I managed to get to the OWA login page.

Now comes the problem, because after entering the credentials and pressing the login button, there is a HTTP 400 Bad Request page with the link /owa/auth/owaauth.dll (I use Exchange 2007).

When accessing OWA directly from the internal LAN this page is never displayed, basically after login the browser is re-directed to the Inbox in OWA.

I use FQDN for OWA and also imported in MWG the certificate from Exchange server but I still have this issue.

Any idea?


Can one single applaince be foward proxy and reverse proxy at the same time ?



based on out product experience i would suggest to use different proxies, because normally the HTTP header handling is different between forward and reverse proxy.


Version history
Revision #:
2 of 2
Last update:
‎03-20-2018 11:11 AM
Updated by:

Community Help Hub

    New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

  • Find Forum FAQs
  • Learn How to Earn Badges
  • Ask for Help
Go to Community Help

Join the Community

    Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

  • Get helpful solutions from McAfee experts.
  • Stay connected to product conversations that matter to you.
  • Participate in product groups led by McAfee employees.
Join the Community
Join the Community