- Video Walkthrough
- ePO Cloud Account
- Configuring Policy Synchronization
- Enabling Rules for use in the Cloud
- Verify your configuration
- Tips and Tricks
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:
- Your block pages will look the same on premise as well as in the cloud
- You can select the rule sets that you want to synchronize to the Web Gateway Cloud Service
- The policy is synchronized in configured intervals to ensure that rule sets remain the same on both products, including changes that you have incorporated on Web Gateway
- You can also perform synchronization manually, regardless of the configured interval
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.
ePO Cloud Account
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).
Configuring Policy Synchronization
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:
- Check the box for "Synchronize policy to SaaS"
- Select the appliance that should do the synchronization from the drop down (only one appliance can do the synchronization in a cluster)
- Unless instructed otherwise in your account setup email, leave the SaaS address field at its default: https://msg.mcafeesaas.com
- Enter your administrator account, password and customer ID from your account setup email
- Select the synchronization interval desired (15 minutes seems to be a common value here)
Now click "Save changes" and verify that the communication with the Cloud Service is working by going to Troubleshooting > SaaS Synchronization > Synchronize
A successful synchronization should end with a similar message as shown below.
Enabling Rules for use in the Cloud
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.
Verify your configuration
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.
Using IP Range authentication
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 your 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 SaaS 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.
Hardcoded default values in some properties
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!
Authentication related rules
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.
Tips and Tricks
Identify a request executed in the cloud
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