I'll admit to looking back at notes from > 10-years ago, so take it for whatever that's worth, but I recall that latency was a sensitive issue for VRRP. So our recommendations were to NOT use VRRP over a WAN, or a long-distant LAN (ie.. a DR scenario), or in virtual due to resource conflicts for virtual switching and the latency that can cause.
Sharing that, I'd suggest talking to the local sales team or Imperva Consulting. If my choices were to use VRRP in virtual, move to Cloud WAF, or switch from the inline bridge to Reverse Proxy with Load-Balancing, or some other architecture, I would not pursue using VRRP not using dark-fiber to connect the two appliances.
Original Message:
Sent: 01-12-2024 03:03
From: Michel Nzenwa
Subject: VRRP For RP and IMPVHA Off boarding
Hello John,
Thank you very much for your assistance.
I just want to clarify, the gateways are deployed on the primary and DR of the environment, the gateways are connected through an extended lan. Can we still achieve VRRP with this type of deployment.
For the CWAF assistance many thanks.
------------------------------
Michel Nzenwa
Engineer
Platview Technologies Ltd
Lagos
Original Message:
Sent: 01-11-2024 18:31
From: John Thompson
Subject: VRRP For RP and IMPVHA Off boarding
Hi Michel,
I'm going to tackle your last question first. I hope that's okay.
- Imperva's Cloud WAF can be implemented seamlessly with a DNS change for the Site you want to provide Cloud mitigation for. See below for additional resources. Also, don't hesitate to reach out to your Imperva sales team or use our Under Attack hotline (https://www.imperva.com/under-ddos-attack/) if that's what's going on.
- CWAF Intro: https://docs.imperva.com/bundle/cloud-application-security/page/introducing/cloud-waf.htm
- How to onboard a site to CWAF: https://docs.imperva.com/bundle/cloud-application-security/page/onboarding/cloud-application-security.htm
- see Steps 1 through 6. Steps 3 & 4 provide the seamless redirection of traffic to go through Imperva CWAF. Step 5 is just as important, though. Do not skip Step 5. *see Imperva IP allowlisting article to prevent anyone from reaching your site being protected without going through Imperva CWAF first: https://docs.imperva.com/bundle/z-kb-articles-km/page/c85245b7.html
I hope that helps you get protected right away. Following the steps above, Step 4 will update through DNS to start routing traffic to Imperva CWAF first with no loss in traffic or uptime, etc. You may continue to operate 2 WAFs, both CWAF and On-Premises WAF, and you can even see all of your events in the Attack Analytics portion of CWAF if so configured. If you choose to standardize on CWAF and remove your on-premise WAF because it is physically inline as a bridge with your traffic, you'll want to do so during a maintenance cycle as traffic is renegotiated/redirected internally.
Or, if you have a load-balancer upstream in your environment, which the web traffic is already passing through, you can simply work with your load-balancer/networking team to seamlessly bypass the existing WAF in inline bridge mode.
Back to your earlier question about VRRP in a virtual environment though, remembering that I just mentioned leveraging a load-balancer in your environment. In a virtual environment, I would not choose a VRRP solution, if I had a choice and/or if I had to manage it.
In my experience, VRRP in VMware is not the easiest/simplest of configurations to implement. I would recommend leveraging a load-balancer upstream of the on-premises WAF. Those WAF appliances would then be configured in Reverse Proxy mode. In a virtual environment, a reverse proxy is much simpler to implement. Because Reverse Proxy mode terminates traffic and then initiates a new connection to the web/origin server, you can simply and easily achieve the same or better state of fault-tolerance and redundancy and even high-availability via leveraging a load-balancer across multiple virtual (or physical) on-premises WAF appliances. That same traffic termination behavior supports additional security ciphers (TLS/SSL), and additional configurations to allow you to manipulate traffic.
I see most customers choosing to implement load-balancing of traffic on both sides of a Reverse Proxy WAF, and it's our best practice/standard for cloud service providers.
Having said all of that, we have additional application security solutions and deployment options. If you'd like to look into anything further, I recommend you prepare a network or traffic flow diagram and meet with your Imperva sales team to help architect the best solution for you.
Best Regards, and thanks for being a dedicated Imperva Partner!
------------------------------
John Thompson
Director, Channel Presales
San Diego CA
Original Message:
Sent: 01-10-2024 16:03
From: Michel Nzenwa
Subject: VRRP For RP and IMPVHA Off boarding
Hello all,
Certainly! Here's a rephrased version of your request:
I need assistance in comprehending the setup process for VRRP with virtual appliances on VMware. I've attempted to refer to the documentation, but it hasn't provided the clarity I need.
Additionally, in a scenario where multiple applications are being onboarded in RP (Reverse Proxy) mode and the aliases have different IPs compared to the web application, is it necessary to route both on the WAF and the firewall? If so, what would be the procedure for this?
If you have a gateway currently operating on IMPVHA bridge and you wish to transition to CWAF without experiencing any downtime, how can this migration be seamlessly executed?
Your help is much appreciated. Thank you
#On-PremisesWAF(formerlySecuresphere)
------------------------------
Michel Nzenwa
Engineer
Lagos
------------------------------