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

Web Gateway: - Get Creative with your Rules

What is, and why should I care? is a domain that was registered by McAfee (and will continue to be for the foreseeable future) for you to make use of when creating internal requests. McAfee holds this domain, and has a wildcard DNS entry, so any subdomain will resolve.

The host is: *

The underlying IP is:


This is useful because it will give you a definitive 'dummy URL' to use for any request referencing the Web Gateway itself. For example, to easily collect troubleshooting info you could use '' and return a block page that contained useful information (client IP, authenticated username/groups, user-agent, etc).


The fact that this is a wildcard DNS is especially useful in transparent deployments (WCCP, Transparent Router/Bridge, etc). In these situations, the clients are not aware of the proxy, and will do a DNS request for the URL in question. Since * will always return the IP of, we can be sure that internal requests will always work as expected for both direct proxy and transparent deployments.



How should I use it?

As this is intended to be used as an internal-only domain, all actions referring to should always result in a 'Block' action of some sort -- as there is no point in sending any traffic to the actual domain. As a general rule of thumb, for our internal server rules we'd want to use Criteria along the lines of:

URL.Host matches * OR

URL.Destination.IP equals


If you happen to forget to set a block action -- the web server will return a simple message of:


Use Case Examples

These are examples intended to give some high level ideas of what can do for you.


Troubleshooting Information

Perhaps the most common use I've seen for internal requests is the ability to pull up a page that will display all of the information we have on a test client. This can be very useful to troubleshooting authentication issues, policy mapping issues, and sometimes it's just an easy way to get your end-user to pull up their IP address.


I've set up the following rule (using the subdomain of '')



After creating this rule, I customized a new error template to include the information I was looking for:



For example, to aide in troubleshooting an end-user's workstation that is going through the Web Gateway - I can ask the end user to visit  By doing so, they'll see the info displayed on the error template and can read back to me any of the values the Web Gateway populated, as pictured  below.

Authentication Server

If you are using the Time/IP or Cookie auth server - and would like to clean things up a bit, you can make use of a mwginternal domain to give you something a bit more obvious to look for within requests. Under the 'IP Authentication Server' information, you can replace the stock value, shown here:

http://$<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.system.proxy.ip"/>$:$<propertyInstance useMostRecentConfiguration="false" propertyId="com.scur.engine.system.proxy.port"/>$


with the much more user-friendly value shown here:

URL Checker

One useful thing that you can utilize the mwginternal domain for is doing quick URL checks against your local MWG. This can be especially useful if you are making wide use of extended lists to recategorize sites.


I've crafted the following rule that allows you to simply enter a website as a 'path' to a mwginternal subdomain.


The customized blockpage I created takes the 'URL.Path' value and uses it to perform a check against 'URL.CategoriesForURL' and 'URL.ReputationForURL'. The check results are displayed on the blockpage (see below).


To use the checker, you can simply visit on a machine navigating through your MWG, and get some info on how your Web Gateway categorizes the site.

web site.png



Other Ideas

The sky is the limit. Some have configured internal 'site review' requests, so that if a user is blocked, they can send an e-mail to their local admin requesting access. Other people have created diagnostic rules to enable rule engine tracing. Any time you need to be referencing the Web Gateway itself, or simply need a 'dummy' URL to trigger something, is available and should be the domain of choice.

Labels (1)

How about getting a wildcard cert for * and adding https to the server?


Hi, I am interested in the URL checker, but somehow the category shows as emtpy in the block page. Can you confirm that the blockpage should use the "URL.CategoriesForURL' property with a property value of 'URL.Path' ?


I was able to get the block page to show category numbers and reputation scores, but not category names. I had to use String.SubString instead of URL.Path, as the path contains the preceding slash "/", which affects the category lookup. So using substring starting at position 1, and url.path as the string, it can read the path correctly.

Still trying to figure out how get category names out of it the numbers. Will update if I figure it out.


i have a complete implementation of a URL checker built into a complete policy posted at:

This is a complete backup, so restore it on an empty VMware appliance to test it because restoring a policy wipes out the entire configurguration you have. Don't load it into a production MWG.

I suggest using version 7.4.1.

When you restore it, and are proxying through it, you can go to and get the following:



where I can download templates from preconfig?

update: thx, need "use save extract files from .backup"


If I understand correctly, PreConfig. is a fully pre-populated config with all the bell and Whistle I may need to start our first MWG 7.x system?


Preconfig is an instrument to showcase all knobs and whistles of the product whereas the actual configuration needs to be built on your requirements.

Preconfig contains elements that can be helpful but can be too much for your needs at the same point of time.

However, it is a useful instrument to learn from and demonstrate the capabilities of the product.


If I restore it over a lab VM, I should be able to export usefull rules for the prod system?


In theory, yes.

The CheckURL pages specifically are all highly dependent on the block pages included with the PreConfig,

The Test Policy and impersonate features are dependent on some other rules in the policy in order to bypass authentication and let a forged username and groups evaluate in the rule set.


Link for preconfig file is not working for me. Is there any other option how to download it?

Version history
Revision #:
3 of 3
Last update:
‎04-03-2018 09:10 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