AVI WAF Design Guide

Part 1 of 2: This post covers the design and architectural decisions behind an AVI Intelligent WAF (WAF) deployment. Part 2 walks through the step-by-step configuration in the AVI GUI.

What is the AVI Intelligent WAF?

A Web Application Firewall protects web-facing services from application-layer attacks. Traditional WAFs tend to provide administrators with rules to deploy, but very little visibility into how those rules behave once deployed to production traffic. AVI WAF is built around closing that visibility gap: every rule that matches a transaction is observable in real time, and the platform actively learns the structure and behaviour of the protected application.

WAF is a feature of the NSX Advanced Load Balancer Enterprise license. A WAF policy is a specific set of rules that protects an application; the policy is then bound to a virtual service. WAF policies can only be associated with virtual services that use an HTTP-based application profile. If you try to attach a policy to a TCP/L4 VIP, the field simply will not appear.

WAF feature stack at a glance

Avi WAF provides a full application security stack covering the OWASP Top 10 (HTTP validation, injection, data leakage, automated attack blocking, application-specific rules) plus positive security, application learning, allow-listing, IP geolocation, HTTP RFC compliance, file-upload scanning, DAST import, scripting hooks, JSON/XML API protection, multiple CRS versions, per-application rate-limiting, brute-force protection, basic DDoS protection, HTTP security policies, and L3-L7 ACLs.

Operating modes: Detection, Enforcement and Mode Delegation

A WAF policy can run in one of three modes:

• Detection-matching requests are allowed but are flagged with an event log message. This is where every new policy should start.
• Enforcement matching requests are blocked by the Service Engine according to the rule action.
• Mode Delegation: Individual rules override the policy mode. Allow Mode Delegation is always checked when Enforcement is selected, and we recommend leaving it on in Detection too.

Mode delegation is the lever you actually use to get a policy into a healthy production state. It lets you push new rules or CRS updates in Detection while the rest of the policy stays in Enforcement, run partial-detection deployments, or temporarily roll a problematic ruleset back to Detection while you investigate a false positive, all without having to flip the whole policy.

Paranoia levels

Specific CRS rules are enabled or disabled based on the paranoia level. There are four levels: 1 – Low, 2 – Medium, 3 – High, 4 – Extreme. The right level for an application is a function of two things: how risky the application is, and how much engineering time you have available to tune false positives.

Consideration	Paranoia mode
High application risk level	High paranoia mode
Low application risk level	Low paranoia mode
Resources available for tuning	Higher paranoia mode
Limited resources available for tuning	Lower paranoia mode

For deeper context on what each level changes, the OWASP ModSecurity CRS Paranoia Mode documentation is the authoritative reference.

Application Learning: building positive security automatically

Handwriting positive security rules for a real application is tedious and error-prone. Application Learning is the WAF feature that does the work for you: when learning is enabled on a WAF policy, the Service Engine continuously analyses incoming traffic, parsing the URI, body parameters and HTTP request as it goes. Collected statistics are flushed to the Controller every learning interval, and the Controller uses them to automatically populate a learning group with candidate Positive Security rules that describe normal application behaviour.

WAF also supports adaptive application learning, where the SE itself adjusts the sampling percentage and learning interval based on the SE and Controller resources currently available. That is the option you reach for when you want to enable learning on a busy VIP without spending an afternoon hand-tuning intervals.

Sizing and performance: design for the cost of inspection

Because WAF has to intercept and analyse traffic, either to learn it or to enforce against it, it is more expensive than plain L7 load balancing. The visible symptoms of an undersized WAF deployment are service degradation on the VIP and elevated SE/Controller utilisation. The remediation options, in order of operational cost, are:

1. Add vCPU, memory, or disk to the SEs and/or Controllers that carry the WAF policy.
2. Reduce the number of VIPs hosted on a given SE and spawn an additional SE Group.
3. Lower the learning sampling percentage once the bulk of the application has been observed.

Note that the resource ceiling for an environment is set by the AVI license itself; you cannot scale infinitely on the same entitlement, and very high SE utilisation can cascade into Controller load.

A pattern worth considering in production: 
Create a dedicated SE Group for WAF-protected VIPs while application learning is at 100% sampling, and the VIP is not yet considered production. Any service degradation is contained to that SE Group; once the learning phase ends or once the VIP starts handling production traffic, you migrate the VIP to a different SE Group and continue with a lower sampling percentage. That gives you the best of both worlds: fast learning on isolated infrastructure, and a clean handover when the policy is ready for live use.

Pulse: opt-in services and signature delivery

Several WAF features, such as automatic CRS signature updates, application rule updates, and IP reputation feeds, depend on Pulse. Pulse is the cloud service that the Controller registers against (now via the My VMware portal), and it requires outbound Internet connectivity to portal.avipulse.vmware.com and customerconnect.vmware.com on TCP/443. Designs that run in air-gapped or strictly controlled environments need a compensating process: signatures can still be downloaded manually from the vendor portal and uploaded to the Controller, but auto-updates and IP reputation will not be available.

Three Pulse design points worth flagging early:

• The Controller cluster name should be changed from the default cluster-0 So each registered cluster is identifiable in the portal.
• Where outbound HTTP(S) goes via a proxy, configure split proxy on the Controller cluster from the CLI before attempting registration in the GUI.
• Pulse opt-in toggles include “Auto Download WAF Signatures”, “WAF Signatures Notifications” and “Application Rules”. Pick the combination that matches your change control posture.

Roles and operating model

Tuning a WAF policy is not a fire-and-forget activity. It is an iterative process that requires human review of learning data and event logs. AVI ships a built-in WAF-admin role that grants exactly the permissions needed to tweak WAF policies without the broader privileges of a full administrator; this is a sensible role to assign to application owners, especially in customer-facing or multi-tenant deployments. If WAF-admin is too narrow or too broad, custom roles can be created with the relevant WAF permissions added in.

WAF Profiles vs WAF Policies

A common point of confusion: a WAF Profile contains the basic settings that drive the WAF engine itself (HTTP parsing limits, file types, request body limits, and so on), while a WAF Policy contains the rules allowlist, positive security, signatures, application rules, and a reference to one profile. Profiles are reusable across policies, which means most environments end up with a small number of well-tuned profiles (for example, one for Java apps, one for PHP apps and one for APIs) and a larger number of policies that consume them.

Putting it together: A recommended rollout sequence

For a new application protected by WAF, the design pattern that consistently produces the smoothest path to enforcement is:

1. Register the Controller against Pulse and decide on auto-update vs notification-only signatures.
2. Build a WAF Profile sized for the application stack (Java, PHP, API, etc.).
3. Create a WAF Policy in Detection mode with Mode Delegation enabled, and attach it to a paranoia level appropriate for the application’s risk.
4. Enable Application Learning, ideally on a dedicated SE Group, at 100% sampling with adaptive learning on.
5. Let the policy run long enough to populate a meaningful learning group, review the auto-generated Positive Security rules, and create allowlist exceptions for known-good traffic such as scanners, internal IP ranges or specific upload paths.
6. Switch the policy to Enforcement, keep Mode Delegation enabled, and use per-rule Detection overrides to roll out new rules safely.
7. Migrate the VIP to its target SE Group and reduce learning sampling for steady-state operation.

That is the design framework. In Part 2, we walk through the actual GUI configuration. Pulse registration, WAF Profile, WAF Policy, Allowlist, Positive Security, Signatures and applying the policy to a virtual service with screenshots from a working AVI 20.1 deployment