Hi all. I`m using trial license and want to test Proxy HA configuration. But this option now is grey and I can not choose it. What could cause this? how can I test it? Is this limitations of trial license?
Hi I`ve already got answer that my issue caused by fact that I used aws ami appliance and cloud version does not support Proxy HA mode. Another question, does MWG support external loadbalnacer, maybe some some documentation or article how to properly configure it?
If to put aws alb before mwg appliances there is no possibility to balance workload between them. Also there is an issue with login to UI portal. instance try to access themself on port 4711 and got error since balancer work on 443 and redirect requests to 4712 port but not 4711. In this case, I need to add an additional rule to the security group for 4711.also issue with adding a certificate to trusted store appears every login
you can put an external load balancer in front of MWG yes. Most customers do this, as an external load balancing solution is much more flexible and offers a lot of more features compared to the built-in HA.
I am not aware of any specific documentation, as there is not much to do. The load should be balanced equally across all nodes with client stickiness, so that one client sticks with the same MWG for some time.
Make sure MWG sees the correct client IP address by using X-Forwarded-For headers, Proxy Protocol or rewriting of the source IP address (which should be covered by the load balancers documentation).
Access to the UI should go to the MWG directly, not through a load balancer.
so if we are going to use icap protocol, I need to open this port on the lb security group and redirect all client requests for file scanning to the lb and port of icap and then lb will redirect to appropriate instance behind the lb. in case I need access to UI I should go directly to IP or dns of instance not lb.?
In this case do I need to prepare cluster in Central Management?
yeah. Basically you would have the load balancer listen on a separate IP on port 1344. It will accept and forward the connection to one of the MWGs in the backend also on port 1344. ICAP clients will only talk to the IP address of the load balancer.
Stickiness should not be a topic for ICAP, it is only important for the HTTP proxy. The ICAP Client will add an X-Client-IP header into the ICAP communication, so the real clients IP address will be available within the Web Gateway.
For the UI yes, you will NOT make another open service on the load balancer which forwards to the MWGs. You need to access the MWGs on their specific IP address on port 4711/4712 for management purposes. You will need to at least sign in once to every machine to setup the cluster CA (to allow central management). Afterwarts you can pick one machine you would like to use for management.
Important to know:
The central management is not explicitly necessary. You can have a load balancer point do different MWGs and each MWG can run a different policy. But that does not make too much sense as you may see different scanning results depending on what MWG you were forwarded to...
So when using a load balancer and multiple MWGs it makes sense to have the same policy. You can have the same policy by using central management or take care manually that the rules and lists are always the same 🙂
One more note: If you are hosting in AWS please make sure that you are either in a private network and only send traffic to the AWS nodes via a VPN tunnel OR be aware that when running on a public IP address you might open the MWGs ICAP or UI services to the outside world. ICAP by nature does not have authentication, so everyone who is able to connect will be able to send requests. The UI itself is not designed to sit in the internet and be open and available 24 hours a day for any kind of different attacks. I would recommend to make sure the connectivity is as much restricted as possible.
Might be obvious, but this would not be the first MWG open to the world, even not the first one brought to the public internet with default credentials... last time it took around a week until someone logged in who was not expected 🙂