F5 BIG-IP Advanced WAF Troubleshooting: What I Check First

When an application protected by F5 BIG-IP Advanced WAF / ASM starts failing, I try not to change the security policy immediately.

Before disabling signatures, creating exceptions, or switching the policy to Transparent mode, I first ask:

Where exactly is the request failing?

1. Validate LTM first

Before blaming the WAF, confirm that the application delivery path is healthy.

tmsh show ltm virtual <virtual_server> tmsh show ltm pool <pool_name>

Check:

• Virtual Server status
• Pool and pool members
• Health monitors
• Backend connectivity

If the pool is unavailable, the problem is probably not Advanced WAF.

Client | Virtual Server | Advanced WAF | Pool | Application

The objective is to determine whether the failure happens before, during, or after WAF inspection.

2. Confirm that Advanced WAF actually blocked the request

Check:

Security > Event Logs > Application > Requests

If the user receives a blocking page, capture the Support ID.

Correlate:

• Timestamp
• Client IP
• URL
• HTTP method
• Violation
• Attack signature
• Security policy
• Support ID

An application error does not automatically mean that Advanced WAF blocked the request.

Also remember that missing events do not necessarily mean traffic bypassed the WAF. Verify the configured logging profile.

3. Check the enforcement state

A detected violation is not necessarily a blocked request.

Verify:

• Transparent vs Blocking
• Learn
• Alarm
• Block
• Signature/entity staging

A policy in Blocking mode does not mean every detected violation will block traffic.

4. Identify the exact violation

Before disabling anything, understand exactly what triggered the policy.

Examples:

• Attack Signature Detected
• Illegal parameter
• Illegal URL
• HTTP protocol violation
• JSON/XML parsing violation
• Disallowed method
• CSRF
• DataGuard

Then identify the affected entity:

Signature ↓ URL ↓ Parameter / Header / Cookie / JSON element ↓ Matched value

This is critical for proper WAF tuning.

5. Tune the smallest possible scope

Suppose a legitimate parameter triggers a SQL injection signature.

Do not immediately disable that signature globally.

Instead determine:

Signature ↓ Affected URL ↓ Affected parameter ↓ Expected application behavior ↓ True positive or false positive? ↓ Granular exception, if justified

My rule is simple:

Change the smallest possible security scope.

6. If there is no WAF event, validate the traffic path

Check whether:

• The request reaches the expected Virtual Server
• The correct security policy is assigned
• The HTTP profile is present
• An LTM policy changes processing
• An iRule redirects or modifies traffic
• SSL terminates where expected
• Traffic reaches another VIP

Packet capture can quickly confirm the flow:

tcpdump -nni 0.0:nnn -s0 host <client_or_server_ip>

7. Correlate logs

Useful starting points:

tail -f /var/log/asm tail -f /var/log/ltm

Do not troubleshoot using one log line.

Correlate:

Timestamp + Client + Virtual Server + Support ID + WAF Event + LTM behavior + Backend response

8. Do not blame WAF for every HTTP error

For example:

404
Check URI, redirects and application routing.

500
Investigate the application/backend.

502 / 503 / 504
Check pool members, health monitors, TCP connectivity, server-side SSL and timeouts.

The fact that Advanced WAF is enabled does not mean it generated the error.

9. Remember TLS

TLS failures can look like WAF problems.

Check:

• Client SSL profile
• Server SSL profile
• Certificates
• SNI
• TLS versions
• Cipher negotiation
• Backend TLS handshake

If TLS fails before HTTP inspection, you are troubleshooting a different layer.

My Quick Workflow

Reproduce the issue ↓ Validate Virtual Server ↓ Validate Pool / Backend ↓ Confirm traffic path ↓ Find WAF event / Support ID ↓ Identify violation or signature ↓ Check enforcement and staging ↓ Identify affected entity ↓ True positive or false positive? ↓ Apply the smallest justified change ↓ Retest

The main principle is:

Do not troubleshoot a WAF by disabling security controls until the application starts working.

Correlate:

Traffic path + policy + enforcement + violation + entity + logs + application behavior

That is the difference between proper WAF tuning and simply weakening the policy.

What do you normally check during the first few minutes of an Advanced WAF incident?

Essa é a faixa de tamanho que eu usaria no F5 DevCentral: técnica, escaneável e sem parecer capítulo de manual.