Thanks for putting these up. Interesting considerations! Please keep them comming.
And again - thanks for starting the thread!
I have a decentralized deployment. I would like to see the ability to Central Management to have a common policy, but have unique settings within the policy.
For example, each gateway has a local ICAP server. Currently if I used CM, all proxies would use the same ICAP server. I'd like to be able to give each gateway it's own.
I would also like better reporting within the gateway interface itself.
Being able to tell the unique IPs going through, and information on failed authentication attempts.
I think the general idea behind the policy is that it is shared and identical through the complete cluster. Exceptions will be hard to manage. But there are properties which allow you to identify on which node you are working, such as the UUID or IP of the proxy currently handling the request.
The idea is to say something like
"If Proxy.IP is 192.168.0.1 then use ICAP server 192.168.0.100"
"If Proxy.IP is 10.10.10.1 then use ICAP server 10.10.10.100"
This will allow you to have "unique" settings on a per location basis.
Are you saying that my desired effect is possible with the current solution?
that's what Andre implied
If you need to have different setting per location, the you can still use the usual model.
You have to craft different sections in the rule tree then depending on site, here is an example using System.Hostname. This requires proper DNS of course. Alternatively you can use Proxy.IP.
You just blew my mind.
So I only need to create the unique ICAP Client settings and then break out the Call ReqMod Server rule so that it checks the gateway ip and then tells it to use the appropriate ICAP Client setting.
That is pretty slick!
Thanks Michael for explaining what I wanted to say ;-)
Some properties you may want to utilize are
Proxy.IP - contains the IP address the client connected to (should be unique per location)
System.Hostname - the hostname you configured the system to have on Configuration -> Network
System.UUID - this is an ID which is really unique per appliance (hardware or vmware)
As Michael explained you can use Rule Sets to differ - this allows to have per-location or per-hardware related rules.
This is not really the easiest way to set up, but I think we have decided to do it this way since the original "exception of settings" does not really fit into the rule based approach any longer.
Plese let us know in case you encounter problems.
In regards to your other queries I think we do not have this right out of the box, but there is some information which may be interesting for you.
To see what happens around Authentication, please look at Dashboard -> Charts and Tables -> Authentication Statistics. You can see how many requests have been done and how long processing took. You can also see if the backend connection is alive. In case something strange goes on you may notice an error or strange graphs here. Unfortunately this won´t help you understanding why a single auth request failed - this is still manual work :-(
In regards to unique client IPs you are right, we do not really count them. What you can do is look at Dashboard -> Charts and Tables -> Traffic Volume. On the bottom you can see the TOP Source IPs by traffic and requests. With the dropdown box you can see the "top 1000" - which will at least show you the top 1000 IP addresses. In case less than 1000 nodes are on your network you will also see all unique IPs :-) In case there are more than 1000 yes, you will only see the top list - for a detailled view of ALL IPs Web Reporter may give you the answer.
Just create as many ICAP settings you need and use them in the context you require.
This took me about 5minutes to configure, deploy, and test successfully.
Now I am VERY happy managing the gateways from a single console!!!