The idea behind "Web Hybrid" is that you can manage your web security policy from your Web Gateway on-premise, and it will sync to the Web Gateway Cloud Service. This ensures a consistent web security policy where ever your users are (inside or outside the corporate boundaries). Users on-premise will be protected by your Web Gateway, users outside the network will be protected by the Web Gateway Cloud Service.
Using Web Hybrid allows you to enforce the same security policy on the web usage of both kinds of users; this includes:
You can check the status of the Web Gateway Cloud Service at https://trust.mcafee.com
Here is a quick video which will walk you through configuring your Web Gateway on-premise to sync your policy with the Web Gateway Cloud Service.
To sync your Web Gateway on-premise policy to the Web Gateway Cloud Service, you need an ePO Cloud account (see: Web Gateway Cloud Service: Introduction for more info).
In the Web Gateway UI we need to enable the policy synchronization as a first step to create your hybrid policy.Navigate to Configuration > Web Hybrid and configure the following:
Now click "Save changes" and verify that the communication with the Cloud Service is working by going to Troubleshooting > Cloud Synchronization > Synchronize
A successful synchronization should end with a similar message as shown below.
You can now pick and choose which parts of your policy should be synchronized with the cloud. A good starting point might be a global block list or a URL filtering rule set (but virtually any rule set should work with the restrictions below in mind)
To enable a rule set for use in the cloud, simply select the checkbox "Enable in Cloud" and "Save changes". With the next synchronization, this rule set will get enabled in the cloud service.
You can also enable multiple rule sets at the same time by selecting the desired rule sets and then right clicking on them and selecting "Cloud".
Whether a particular rule set is enabled in the cloud or not is indicated by the little blue cloud symbol on the rule set.
Once everything is syncing between Web Gateway on-premise and the Web Gateway Cloud Service, you'll want to verify and test your configuration. To do this, we need to redirect our web traffic to the Web Gateway Cloud Service. This can be done using MCP, or changing the browser settings. MCP is the most common deployment method, if you use IP Range or SAML, we'll need to change the browser settings.
Web Gateway Cloud Service: Deploying and managing McAfee Client Proxy with ePO Cloud
After your policy has been synced, you should be able to verify your setup by pointing your browser to the Web Gateway Cloud Service instead of your local on premise MWG.
Your account setup email should have provided you with the proxy address needed.
As an example, you can change your proxy settings in Internet Explorer under Tools > Internet Options > Connections > LAN Settings
If the setup is working correctly, you should see that you're on-premise policy (and block pages) are applied while going through the Cloud Service for filtering.
The synchronization of your policy from your on premise appliance to the cloud only takes a few seconds. For efficiency purposes, the active policy in the cloud that is deployed to the proxies is being cached for a few minutes though. Do not be alarmed if a change you made takes a few minutes before it actually starts to work through the Cloud Service proxy. Unless there was an error message during the synchronization, you can be sure that your policy will get applied and will become active within a few minutes.
Some properties that might be used in your on premise policy might not make sense to be used in the cloud proxy. As an example, the property proxy.ip has a hardcoded value of 0.0.0.0 when a request is processed through the cloud.
If you need to verify whether a property has a real or a hardcoded value in the cloud, the easiest and quickest way is to add it to a block page and then examine that block page while going through the cloud proxy.
Example rule: if URL.Host equals property-check.mwginternal.com then block (property-check block page)
Several properties and events will not work in a cloud setup and might therefore cause warnings in your local UI when you try to save your changes. Some examples are authentication properties, log file writing or sending email/snmp/syslog messages. If these properties or events are in use in your policy that you enable to sync to the cloud, you will see a UI warning popup when you save changes. Red warnings need to be addressed before you can proceed to save your changes!
As mentioned earlier, authentication for the cloud based requests still happens as part of the Web Gateway Cloud Service and not as part of your MWG rules being synced.
It is very important that your rules and rule sets are configured to work for users that are authenticated on-premise (for example with NTLM/AD) as well as in the cloud (for example with a static username like we are using in these instructions).
Consider that the actual username and even more importantly the group names can look different between the cloud and the on-premise environment.
Adding usernames and group names to a test block page is a quick and easy way for you to see what exactly is available to you.
For policy building purposes it may be important to be able to identify whether a particular request is being filtered in the cloud or on-premise. As an example, you can add text to your block pages to show where the request was blocked.
There is an official property called "InTheCloud" which will return "true" only if a request was filtered through the Web Gateway Cloud Service proxy.
Using a User-defined Property to set custom text and then embedding that text into the block pages would allow to show which proxy was being used.
This kind of detection can also be helpful in situations where you would want to set a default user-group for cloud users.
2017-02-23 - Updated to reflect ePO Cloud and Web Gateway Cloud Service
2014-07-15 - Added Demo Video
2014-05-27 - Original publishing date
Hi,
wpsproxy.mcafeesaas.com -> is this the only option?
How about localized proxies used in US or EMEA.
In the past i got an information using some "spezial" hybrid webproxies. It there a new list with available proxy servers available?
Cheers
Hi Jon,
great, just one question. WebHybrid is now available for any customer. So any SaaS proxy can be used for a WebHybrid (MCP Proxy configuration) solution?
Cheers
So far as I'm aware, yes!
Hi all,
are there any new Web Hybrid Proxies available. Is there an updated List available?
Cheers
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA