That sounds possible.
All that is required is the two gateways. Everyone hits WebGateway1, performs authentication, then you have rules for the executive group to use WebGateway2 as a next hop proxy.
There is no need to configure multiple interfaces for this configuration, one on each is fine.
I feel like I am missing some caveat to the problem, but this sounds very straightforward.
The two gateways are in cluster for centralized management. In order to do what you explained above do I need to kill cluster centralized management?
Now as per your description every body will hit gateway1, it means the source proxy in users browser will be IP of gateway 1, isn't it? and then by policy they will be using Web gateway2 as next hop, can you give example how to provide next hop in rule to jump to second gateway.
The response for request will also reach to users through gateway 1 for all users even for executives?
This will not mean that the cluster has to be decentralized, however, it will create a need for logical separation of the rules.
There will need to be separation of the rules intended for proxyA (mwg1), and for proxyB (mwg2).
Effectivley, proxyA, will need to perform the authentication with the user, then decide if they need to send that user to proxyB. In the process, proxyA must relay authentication information to proxyB so it can use it for filtering the recieved request. proxyB must also be configured to read the relayed information.
This authentication process is why a separation of rules is required.
What is have described above is reflected in the attached ruleset and above screenshot.
The ruleset attached has no policy associated with it, it only takes care of writing auth headers, and reading auth headers. It also takes into account that only the executives group will be allowed to access proxyB. As such it blocks any user that is not apart of that group.
Adjustments will need to be made to accomodate this.
Let me know if I am overcomplicating the issue or you need clarification.
I am unable to import your given rule set since we are running 188.8.131.52.0 and you provided ruleset created in newer version, that is the error I got.
What proxy executives need to specify in their browsers, if their request is to be taken care off by gateway 2, but they need to hit gateway 1, so they will use proxy address in their browsers as gateway1 ?
I tried myself to do this forwarding once group of user is checked, the group created in Windows AD. Please find attached screen shot: The rule is if user is found in Group MWG 2, trigger event to next hop proxy, But I get bad response when I did this.
When I tried above this user source proxy IP in browser was 10.1.99.10 which is gateway 2 and this user exists in mwg2 so by the rule he should go to gateway 1 which is 10.1.99.9 (given in next hop proxy), does this makes sense ?
Please note both gateways are operating in centralized management.
Waiting for your response
Here is a ruleset for version 184.108.40.206.
The attached ruleset will work in a cluster. It assumes that all users hit proxyA, and "executive" users will not be filtered by proxyA and be forwarded to ProxyB for filtering.
The first set of rules (proxy a), will need to be placed AFTER authentication occurs. You will also need to adjust the next hop proxy settings. Proxy A's rules work by adding headers for proxy B to pickup.
The second set of rules (proxy B), will need to be placed BEFORE authentication. You will need to adjust the ruleset criteria for "Read X-Auth Headers", add the IP for Proxy A to the list of trusted downstream proxies, and also update the "Authorized groups" rule list to include any authorized users to hit proxy B.
This definitly could impact users, so be cautious with its scope, you may want to add a client IP criteria to the top level of this.
This ruleset also has implications if you need to send users from one proxy to another, but relay authentication information for whatever reason. In that case just disable the "Authorized Groups" rule for proxy B.
I created a new version of this, it works a bit different.
See screenshots below. It works by having defined a sending and recieving proxy, you are then allowed to defined, what users/groups/urls you want to send to the receiving next hop proxy (NHP).
The recieving proxy recieves the requests from the sending proxy and will retain authentication information originally performed at the sending downstream proxy.
You define what users/groups you wish to send to the Next Hop proxy here:
NHP-Chaining.zip 472.1 K