Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform
How does the WAF work together with the Load Balancer?
Short answer
The WAF is not a separate device or a separate proxy placed in between. WAF - WAAP (TR7 WAAP), one of the four products of TR7, runs on the HTTP vService of the Load Balancer - ADC product and is turned on with the WAF box in the Details list of the vService form or from the WAF-Protected vService List screen. The request is first received on the vService; if it is HTTPS, TLS is decrypted here, and if there is a CDN in front, the real client IP is determined with the Trusted Proxies profile; then the WAF scans the request in its original form. If the WAF does not block it, the request goes to the Backend Service by going through the vService's Actions list, target selection, and the algorithm and persistence steps; if it blocks it, the blocking response (Blocking Page) returns without the request reaching any Backend Service. In the response order, the response of L7 DDoS & Threat Protection and that of an action that ends the request come before the WAF's blocking page. Requests that match the Whitelist Condition, static content skipped with Do Not WAF Static Contents and requests that start with the AGS Root Path are not scanned in the WAF. The two products share objects: the WAF's Whitelist Condition, WAF Log Suppression Condition and Conditional Blocking Pages fields use Load Balancer conditions (Conditions), and the blocking pages use Content Pages profiles. Load Balancer conditions can also read the WAF's result (WAF Attack Signature, WAF Attack Signature Group, If is a WAF block). The WAF inspects only the request direction; changes on the response side are made with Load Balancer actions.
How Does It Work?
In an HTTP vService with WAF on, the request is processed in the following order. The table shows the place of the WAF; all the stages are on the Which stages does a request go through inside TR7 before it reaches the backend? page.
| # | Stage | What it means for the WAF |
|---|---|---|
| 1 | Reception and TLS | The request is received on the IP:port on which the vService listens. Since TLS is decrypted on TR7 in HTTPS, the WAF sees the unencrypted content (Can the WAF see the content of HTTPS traffic; what is required for that?). |
| 2 | Real client IP | If a Trusted Proxies profile is assigned to the vService, the client address in a request coming from a trusted network is resolved from the header. The WAF's blacklist, learning and log records use this address (If there is a CDN / proxy in front of TR7, how does the WAF see the real client IP?). |
| 3 | Measurement, bot score and AGS session | If L7 DDoS & Threat Protection is on in the vService, the counters are updated and Bot Protection calculates the bot score; if AGS is on, the client's AGS session is validated, and the bot score is calculated for the AGS policies even if L7 DDoS & Threat Protection is off. These stages do not change the request and do not respond; enforcement and the AGS redirect come after the WAF scan (What is the order when WAF and AGS are used together?). |
| 4 | WAF scan | The request is scanned in its original form, before the changes of the Load Balancer actions, and a decision is made. Requests that match the Whitelist Condition, static content requests (GET requests with a static extension that carry no query and no body) while Do Not WAF Static Contents is on (default) and requests that start with the AGS Root Path are not scanned; these requests are counted as Whitelisted in Live Stats. |
| 5 | L7 DDoS & Threat Protection enforcement | If it is on in the vService, enforcements such as blocking, CAPTCHA or quarantine respond here; this response goes to the client also for a request that the WAF would block. |
| 6 | Actions | The vService's Actions list runs from top to bottom. An action that ends the request (e.g. Block, Show content, Location redirection) returns its own response instead of the WAF's blocking page. |
| 7 | WAF blocking response | A request that the WAF blocks gets the response of the matching Conditional Blocking Pages row if there is one, otherwise the response of the default blocking page; it does not go to the Backend Service. |
| 8 | Target and Backend Service selection | A request that is not blocked goes to its target through AGS, Conditional Backend Services or Default Backend Services, and to a Backend Service according to the LB Algorithm and persistence. |
| 9 | Response path | The response of the Backend Service is not scanned in the WAF; the response-side actions (On response) and compression are applied. |
Objects Shared in TR7
In the opposite direction, Load Balancer rules read the WAF's result as a condition:
| Condition | When it matches | Use |
|---|---|---|
| WAF Attack Signature | When one of the selected signatures is included in the attack record that the WAF produced for that request | A different action for specific signatures (Can I take a different action on the Load Balancer side based on the attack the WAF detected (WAF Attack Signature / Signature Group condition)?) |
| WAF Attack Signature Group | When a signature in the selected categories is included in the attack record | An action according to the attack category |
| If is a WAF block (ready-made condition) | When the WAF blocks the request | An action that depends on the WAF block; its negated form is Unless is a WAF block |
These conditions are meaningful only on an HTTP vService and while WAF is on. The WAF's result can also be used in actions with Smart Variables (e.g. %WAFSCORE, %ISWAFBLOCKED).
Where Is It Monitored?
- WAF side: The upper part of the flow diagram in the vService's WAF Dashboard shows the entry layer of the vService (type, listener addresses, TLS), and the lower part shows the WAF inspections.
- Load Balancer side: The WAF card in the Security Modules section of the Load Balancer Management screen shows the dominant mode of the host groups.
- Per request: If Debug is on in the vService, the Security Action cell of the Debug Mode Logs record writes whether the request was ended by the WAF or by L7 DDoS & Threat Protection.
Common Misconceptions
- "The WAF is a separate layer in front of the Load Balancer." The WAF runs inside the same vService; it does not add an extra network hop to the traffic and does not require a separate IP address.
- "The WAF is a part of the Load Balancer." WAF - WAAP is one of the four separately licensed products of TR7 (Load Balancer - ADC, WAF - WAAP, AGS - AAM, GTM); it shares the HTTP vService that receives the traffic with Load Balancer - ADC (Products & Licensing · Products).
- "The WAF sees the request as changed by the actions." The WAF scans the request before the actions, in its original form; a header added with an action does not change the request that the WAF sees.
- "When the WAF blocks, the client always sees the WAF's blocking page." If there is an L7 DDoS & Threat Protection enforcement or an action that ends the request, their response goes to the client; the WAF's attack record is still created.
- "The WAF also scans responses." The WAF inspects only the request direction; adding or deleting headers or changing content in the response is done with On response actions.
- "The WAF can also be turned on in an L7 TCP vService." The WAF runs only on an HTTP vService (Which vService types does TR7 WAF work with; can I use it on an L7 TCP or Network vService?).
How it is done in the documentation
