Can I exempt certain IPs or requests from WAF inspection entirely (Whitelist Condition)?

Short answer

Yes. When Whitelist Condition in the Whitelist & Blacklist window is turned on and a condition is selected, the requests that match the condition do not enter WAF at all: signature scanning, structural checks, the blacklist check and learning are not performed, and no record is written to Event Logs; the request is counted in the Whitelisted category on the Dashboard. For certain IPs, a Source IP condition is first created on the Conditions screen (Load Balancer → Conditions); a request-based exemption can also be made with Path, Host or HTTP Header conditions. Only HTTP conditions on the request side can be selected, and the setting cannot be saved with the condition field left empty. Since exempt traffic leaves no WAF record, the condition is kept narrow; for sources that should be inspected but not blocked, Teacher is used.

Problem: A Trusted Source Is Inspected by WAF

A scanning tool on the internal network, a trusted integration or a specific path should pass without entering WAF inspection. It is necessary that the exemption cover only the targeted traffic and that it be known that exempt requests leave no WAF record.

Solution: Two Methods

The two methods write the same setting; one of them is selected.

Your situation	Suitable method
I will define the exemption from the interface	Method 1: Whitelist condition
I will define it with a script or the command line	Method 2: WEB-CLI
The source should be inspected but not blocked	Teacher: How do I make sure a certain user group (e.g. internal network, test team) is never blocked?

Method 1: Whitelist Condition Recommended

• How it works For a request that matches the condition, WAF does not run at all; the request is forwarded directly to the Backend Service.
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → Whitelist & Blacklist card → pencil icon
• Requirement An HTTP condition evaluated on the request side (if there is none, it is created first; creating a condition requires modify permission in the Load Balancer area) · modify permission in the WAF area
• Scope Across the vService; common to all host groups. It is applied before the blacklist check

Step-by-Step Configuration

1

Adım 1 Open the condition form (if needed)

If the condition to be used does not exist, Add is clicked on the Load Balancer → Conditions screen (how to add).

2

Adım 2 Define the condition (if needed)

For an IP exemption, Criteria = Source IP and Source IP Type = Manual are selected and the IP or CIDR is written (e.g. 203.0.113.0/24). For a request-based exemption, a Path or HTTP Header condition is used. If there is a proxy in front of TR7 and Trusted Proxy is defined on the vService, the condition sees the resolved client IP (Which components use the IP resolved by Trusted Proxy (log, condition, WAF, Bot & DDoS Protection)?).

3

Adım 3 Save the condition (if needed)

Add is clicked; the condition is added to the list.

4

Adım 4 Open the Whitelist & blacklist window

In the Left Monitor Panel → WAF-Protected vServices → vService → WAF Management tab, the pencil icon at the top right of the Whitelist & blacklist card in the Inspection & Blocking section is clicked.

5

Adım 5 Turn on Whitelist condition

The Whitelist Condition switch is turned on; an unlabeled condition field appears below it (when empty, it reads Never).

6

Adım 6 Select the condition

In the condition field, the condition from step 3 is selected; multiple conditions can be combined with and / or, and a new condition can be created in place. The list contains only HTTP conditions on the request side. If the field is left empty, the Empty condition error appears and the setting cannot be saved.

7

Adım 7 Save

Edit is clicked; the change is applied without a separate deployment step. In a cluster setup, it is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent to the peer device manually.

Verification

1Whitelist & blacklist cardTR7 side

The Whitelist & blacklist card on the WAF Management tab is examined.

ExpectedRequests matching this condition skips WAF inspection: + condition

2DashboardTR7 side

A request is sent from the exempt source and the WAF Inspection Distribution panel on the vService Dashboard is examined.

ExpectedThe Whitelisted category increases; no record is created in Event Logs

Method 2: WEB-CLI

• How it works The switch and the condition are written with WEB-CLI; the condition is given by its ID.
• Where it is opened WEB-CLI → lb condition list · waf options update
• Requirement WEB-CLI access; a defined request condition; view permission in the Load Balancer area to see the condition ID with lb condition list (an account that has only WAF permission does not see the condition table)
• Scope Across the vService

Step-by-Step Configuration

1

Adım 1 Get the condition ID

The condition is given by its ID, not by its name; the ID is in the id column of the list (it starts with lbConditions-):

lb condition list

2

Adım 2 Write the exemption

In place of <condition-id>, the ID from step 1 is written; the --wafCondition field is accepted only together with --wafConditionEnabled true:

waf options update poolId <vService> --syncWithDefaultFwRules false --wafConditionEnabled true --wafCondition <condition-id>

Verification

1Setting recordTR7 side

The WAF settings of the vService are displayed.

Command: waf options show poolId <vService>

ExpectedwafConditionEnabled true and the condition in the wafCondition line

Requests from the exempt source are counted in the Whitelisted category as in Method 1.

Common Mistakes

• Writing a broad condition. Traffic that matches the condition stays entirely outside WAF inspection and recording; even if it contains an attack, it is not blocked and does not appear in Event Logs. The condition covers only the necessary source or path.
• Not verifying that the exemption has been removed. After the exemption is removed by turning off the switch, the Conditional whitelist is off line is seen on the card, and it is checked that the requests matching the condition have left the Whitelisted category on the Dashboard.
• Thinking that Frontend blacklist exclusions is a whitelist. That list only cancels the blacklist match; the request continues to go through WAF inspection (Does "Add to Whitelist (vService)" in Event Logs exempt an IP from WAF inspection, or does it only add a blacklist exclusion?).
• Solving a false positive with the whitelist. The wrongly blocked request is taught from Event Logs and written to the related rule; this way, the inspection continues (How do I allow a request that was blocked by mistake?).
• Writing a condition based on the connection IP behind a proxy. If Trusted proxy is not defined, all traffic appears to come from the proxy address, and the condition matches either no request or all requests.

How it is done in the documentation

• Whitelist & Blacklist · Whitelist Condition
• Whitelist & Blacklist · The Whitelist & Blacklist Card on WAF Management
• Source IP · Manual
• WEB-CLI waf options · The WAF Scope

Related questions

• Is the traffic I whitelist logged at all; where does it appear on the dashboard?
• How do I make sure a certain user group (e.g. internal network, test team) is never blocked?
• With "Do not WAF static contents" on, under which condition is a request considered static?