TTechclick ⚡ XP 0% All lessons
F5 · BIG-IP ASM · Architecture & DeploymentInteractive · L1 / L2 / L3

F5 ASM Architecture & Deployment — Where the WAF Sits & How to Stand It Up

Sneha at Infosys is told "put the WAF in front of the payments app". She racks the BIG-IP, builds a security policy… and nothing gets inspected. The policy is fine — it was just never attached to a virtual server. That one gap is the whole lesson. F5 BIG-IP Advanced WAF (formerly ASM) is a full proxy: it terminates the client connection, reassembles the entire HTTP request, inspects it, then opens its own connection to the app pool. This lesson shows you exactly where ASM sits in that data path, how to provision and attach it, and how to choose a Transparent vs Blocking go-live — the way the 303 exam tests it.

📅 2026-06-02 · ⏱ 12 min · 3 live demos · 4 infographics · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

Learn F5 BIG-IP Advanced WAF (formerly ASM) architecture & deployment the AI-era way — the full-proxy data path, where ASM sits on a virtual server, provisioning the module, attaching a policy, and Transparent vs Blocking deployment. 303 exam aligned. 12 min.

🎯 By the end you will be able to

Read as:

Pick where you want to start

1

Full Proxy & Data Path

Why a WAF must terminate the connection, reassemble the HTTP request, then re-open to the pool.

 2

Where ASM Sits

The ASM module on a virtual server, the security policy attach point, TLS termination.

 3

Provision & Attach

Provision ASM (Nominal), build a policy, attach it to the virtual server, apply.

 4

Transparent vs Blocking

The go-live decision: observe & tune in Transparent first, then switch to Blocking.

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. You built a perfect security policy but no traffic is being inspected. What's the first thing to check?

Answered in Path 3 — Provision & Attach. (Spoiler: a policy with no virtual server inspects nothing.)

2. Why can't a packet-by-packet (pass-through) device do real WAF inspection?

Answered in Path 1 — Full Proxy & Data Path. A WAF must reassemble the whole request first.

3. A new policy is attached in Transparent mode. A real attack hits it. Result?

Answered in Path 4 — Transparent vs Blocking. Transparent observes; Blocking drops.

Most engineers think…

"I built the security policy, so the WAF is protecting the app now."

Wrong — and this is the single most common day-one mistake. A security policy that isn't attached to a virtual server inspects nothing. ASM only sees a request because the BIG-IP is a full proxy: the client connects to a virtual server, the WAF terminates that connection, reassembles the whole HTTP request, inspects it, and only then opens its own connection to the app pool. No virtual server in the path = no inspection. This lesson builds the right mental model: full proxy → virtual server → attached policy → enforcement mode.

① Full proxy — why a WAF must hold the whole request

Think of airport security. You can't screen a passenger by glancing at them as they sprint past — you stop them, take the whole bag apart, look at everything, then let them walk to the gate. A WAF works the same way. A full proxy means the BIG-IP terminates the client's TCP and TLS connection, buffers and reassembles the entire HTTP request, hands it to ASM for inspection, and only then opens a separate connection to the back-end pool.

Why does this matter? A packet-by-packet (pass-through) device sees fragments — it never has the complete, decrypted, reassembled HTTP body in one place. ASM needs the whole request: the URI, every header, every parameter, the payload. Only a full proxy delivers that. The price is that the BIG-IP is now an explicit reverse proxy — clients connect to the virtual server, not to your web server.

The TLS session also terminates on the virtual server (via its client SSL profile), so ASM inspects cleartext HTTP. If the app is HTTPS end-to-end, the BIG-IP re-encrypts to the pool using a server SSL profile. No decryption = ASM is blind, no matter how good the policy.

👉 So far: a WAF must be a full proxy so it can reassemble + decrypt the whole HTTP request before inspecting. Next, exactly where the ASM module attaches.
Figure 1 — Full proxy: two connections, one inspection point
An isometric trust-zone diagram. An untrusted client on the internet opens a TLS connection to a BIG-IP Advanced WAF virtual server, where the connection and TLS session terminate. The WAF reassembles the full HTTP request and the ASM module inspects it against the attached security policy. A clean request is then forwarded over a separate, re-encrypted connection to the trusted application server pool; a malicious request is blocked when the policy enforcement mode is Blocking, and a violation with a support ID is logged. In Transparent mode the same violation is only logged and the request is still forwarded. Client → virtual server (TLS terminates) → ASM inspects → separate connection to pool Untrusted / attacker Trusted / inspected Inspection / decision Key insight Client (internet) 203.0.113.7 — untrusted TLS conn #1 BIG-IP Advanced WAF virtual server 10.10.20.5:443 (full proxy) ① TLS terminates here ② reassemble full HTTP ③ ASM policy inspects Blocking → drop violation Transparent → log only conn #2 → re-encrypt App pool trusted · 172.16.8.0/24 only clean traffic arrives Blocking match → drop Blocked + logged violation + support ID There are TWO connections, not one — the WAF speaks for the server. Client connects to the virtual server; the BIG-IP opens its own connection to the pool. That's the full proxy. No virtual server in the path = ASM inspects nothing, however good the policy is. GUI module: Security ▸ Application Security (still labelled "ASM" on many screens inside Advanced WAF).
The whole reason a WAF works: it's a full proxy. The client never touches your server — it touches the virtual server, where TLS terminates and ASM inspects the reassembled request before a separate connection reaches the pool.

Sneha at Infosys faces this

Sneha put the BIG-IP "in front of" the app by giving it an IP on the same subnet and pointing DNS at it — but kept the old server reachable directly too. Pentest traffic still hits the app un-inspected. Management asks why the WAF "isn't seeing anything".

Likely cause

ASM is a reverse proxy. If clients can still reach the web server's real IP directly, that traffic bypasses the virtual server entirely — so ASM never sees it. The WAF only inspects what flows through its virtual server.

Diagnosis

Confirm where clients actually connect.

Local Traffic ▸ Virtual Servers → confirm the published address; then check DNS + firewall so the server's real IP is NOT directly reachable
Fix

Make the virtual server the only path: publish DNS to the virtual-server address and block direct access to the pool member. Now every request is forced through the full proxy.

Verify

Re-run the test. The request now appears in Security ▸ Event Logs ▸ Application ▸ Requests with a support ID — proof it traversed ASM.

▶ Watch one request traverse the full proxy

Rahul at TCS opens the app. Press Play to follow the request through the full-proxy data path, then Break it to see what happens when the policy isn't attached to the virtual server.

① CONNECT203.0.113.7 opens TLS to the virtual server 10.10.20.5:443
▼
② TERMINATETLS terminates on the virtual server; the BIG-IP reassembles the full HTTP request
▼
③ INSPECTThe attached ASM policy inspects the reassembled request — clean, so it passes
▼
④ FORWARDBIG-IP opens a separate connection and re-encrypts to pool 172.16.8.0/24
Press Play to step through the full-proxy path. Then press Break it.
Quick check · Q1 of 10

Why must BIG-IP Advanced WAF be a full proxy rather than a packet-by-packet pass-through device?

Correct: b. ASM needs the complete, decrypted, reassembled HTTP request in one place — URI, every header, every parameter, the payload. Only a full proxy delivers that. A pass-through device sees fragments and never has the whole request, so it can't reliably inspect the application layer.

Pause & Predict

A full proxy terminates the client's connection. For an HTTPS app, what BIG-IP object decrypts the traffic so ASM can read the cleartext HTTP? Type your guess.

Answer: The client SSL profile on the virtual server. The TLS session terminates there, so the BIG-IP decrypts and ASM sees cleartext HTTP. If the app is HTTPS to the back-end too, a server SSL profile re-encrypts to the pool. No decryption profile = ASM is blind. That's the next path — where ASM actually sits.

② Where the ASM module sits — on a virtual server

So the WAF is a full proxy. But which object actually carries the inspection? The virtual server. A virtual server is the listener — an IP and port (e.g. 10.10.20.5:443) — that clients connect to. Everything that decides what happens to traffic hangs off it: the HTTP profile, the client SSL profile, the pool… and the security policy.

The attach chain

ASM doesn't inspect "the box" — it inspects whatever flows through a virtual server that has a policy associated. The chain is:

Break the chain anywhere — no policy on the virtual server, no SSL profile on an HTTPS app, or clients reaching the server directly — and ASM is silently doing nothing.

Pro tip — the policy lives on the virtual server, not "on the box"

One BIG-IP can host many virtual servers, each with its own security policy (or none). A policy you built but never associated with a virtual server protects nothing. Always confirm the association on Local Traffic ▸ Virtual Servers ▸ (your VS) ▸ Security ▸ Policies before you call a deployment done.

👉 So far: ASM rides on a virtual server; the security policy must be associated there (HTTP + SSL profiles too). Next, the object map in one picture.
Figure 2 — The attach chain: how an ASM policy actually gets into the data path
A hub-and-spoke diagram centred on a BIG-IP virtual server. Spokes show the objects that attach to it: an HTTP profile so the BIG-IP parses HTTP, a client SSL profile so the TLS session terminates and ASM sees cleartext, the ASM security policy associated via a Local Traffic Policy, and a back-end pool. A red callout warns that if the security policy is not associated with the virtual server, no traffic is inspected. The amber centre marks the virtual server as the single inspection and decision point. Everything hangs off the virtual server — including the ASM policy Missing link / breaks it Trusted object Inspection point Key insight Virtual Server 10.10.20.5:443 — the listener inspection & decision point HTTP profile so BIG-IP parses HTTP Client SSL profile TLS terminates → cleartext ASM Security Policy via Local Traffic Policy ★ this is what enables ASM Pool (app servers) 172.16.8.0/24 — trusted gets clean traffic only No policy on the virtual server = ZERO inspection. The policy can be perfect — if it's not associated here, it does nothing. HTTPS app, no client SSL profile? ASM never sees cleartext — it's blind.
The mental model that ends most "WAF isn't working" tickets: ASM rides on a virtual server. Miss the policy association — or the SSL profile on an HTTPS app — and inspection silently never starts.

Priya at Flipkart faces this

Priya built a clean security policy for the HTTPS checkout app and associated it with the virtual server. Inspection still reports nothing — no violations, no logs, even on test attacks.

Likely cause

The virtual server has no client SSL profile, so TLS never terminates on the BIG-IP. ASM only ever sees encrypted bytes — it can't inspect cleartext HTTP it can't read.

DiagnosisLocal Traffic ▸ Virtual Servers ▸ checkout_vs → confirm an HTTP profile + a Client SSL profile are set
Fix

Add a Client SSL profile (with the app's cert/key) so TLS terminates on the virtual server, plus a Server SSL profile if the back-end is HTTPS too. Now ASM sees cleartext.

Verify

Re-run a test attack. It now appears in Security ▸ Event Logs ▸ Application ▸ Requests — proof ASM is decrypting and inspecting.

F5 ASM — Building a Security Policy F5 ASM — Attack Signatures F5 Simulator Lab
Quick check · Q2 of 10

On which BIG-IP object do you attach an ASM security policy so it actually inspects traffic?

Correct: c. The security policy must be associated with a virtual server — that association is what enables ASM in the data path. A policy with no virtual-server association exists but inspects nothing.

Pause & Predict

Before any of this — before you can even see the Application Security menu to build a policy — one box-level step must be done. What is it? Type your guess.

Answer: You must provision the ASM module (System ▸ Resource Provisioning), typically at Nominal. Until ASM is provisioned, the Security ▸ Application Security menu isn't even available — there's no policy to build. That's the first step of Path 3.

③ Provision & attach — standing ASM up

Time to actually deploy. There's a strict order, and skipping the first step is why so many "the menu isn't there" tickets exist.

Step 1 — Provision the ASM module

The ASM software is on the box, but it isn't active until you give it resources. Provisioning lives at System ▸ Resource Provisioning. Set the Application Security (ASM) module to Nominal. On a combined LTM+ASM box, provision each module you run at Nominal so resources are shared — Dedicated gives one module everything and starves the rest. After you submit, the box re-provisions (a brief services restart) and the Security ▸ Application Security menu appears.

Step 2 — Build a security policy

With ASM provisioned, create a policy under Security ▸ Application Security ▸ Security Policies. Modern versions use the policy wizard: pick a template (Rapid Deployment is the common starting point), name the policy, and choose the enforcement mode (Transparent to start — Path 4). The policy is a configuration object at this point — it inspects nothing yet, because it isn't on a virtual server.

Step 3 — Attach the policy to the virtual server, then Apply

This is the step everyone forgets. Open Local Traffic ▸ Virtual Servers ▸ (your VS) ▸ Security ▸ Policies, set Application Security Policy to Enabled, and pick your policy. That writes a Local Traffic Policy that enables ASM on this virtual server. Confirm the virtual server also has an HTTP profile and (for HTTPS) a Client SSL profile. Then Apply Policy — every ASM change stays in the editor until you apply.

Only now does inspection actually start. A policy with no virtual-server association is dead weight — and it's the most common reason a freshly built WAF "isn't seeing anything".

👉 So far: provision ASM (Nominal) → build a policy → attach it to the virtual server → Apply. Skip the attach step and nothing is inspected. Next, the deploy order in one picture.
Figure 3 — The deploy order: provision → build → attach → apply (skip step 3 and nothing inspects)
A left-to-right deployment sequence. Step one provisions the Application Security module at Nominal under System, Resource Provisioning. Step two builds a security policy with the policy wizard. Step three attaches the policy to a virtual server on the Security, Policies tab, which writes a Local Traffic Policy that enables ASM. Step four applies the policy. A branch shows that if step three is skipped, the policy exists but inspects nothing. A footer notes that the virtual server also needs an HTTP profile and, for HTTPS, a client SSL profile. Four steps, in order — inspection starts only after step 3 (attach) 1 · Provision ASM System ▸ Resource Provisioning ASM = Nominal 2 · Build policy policy wizard / template object only — inspects nothing yet 3 · Attach to VS ★ VS ▸ Security ▸ Policies = Enabled writes a Local Traffic Policy ★ inspection turns ON here 4 · Apply Policy commits the change → live Skip step 3 (no VS association) → policy exists, inspects NOTHING the #1 "WAF isn't working" ticket A policy is not "deployed" until it's attached to a virtual server AND applied. Built but not attached = the most common day-one mistake. Always confirm the VS association. The virtual server also needs an HTTP profile + (for HTTPS) a Client SSL profile — or ASM is blind. Provision once per box · build + attach per app · Apply commits every ASM change.
Provision → build → attach → apply. The arrow that turns inspection on is step 3 — attaching the policy to the virtual server. Skip it (the red dashed branch) and the WAF silently sees nothing.

▶ Watch ASM go from "racked" to "inspecting" — then watch someone skip the attach

Karthik at Wipro stands up ASM for a new app. Play the correct deploy order, then Break it to see what happens when he forgets to attach the policy to the virtual server.

① PROVISIONSystem ▸ Resource Provisioning → set ASM = Nominal; the Application Security menu appears
▼
② BUILDSecurity ▸ Application Security → create a policy (wizard / template) — an object, inspecting nothing yet
▼
③ ATTACHVirtual Server ▸ Security ▸ Policies → enable the policy → a Local Traffic Policy turns ASM on
▼
④ APPLYApply Policy → inspection is now live; the first real request shows in the Event Log
Press Play for the correct deploy order. Then press Break it.

The four objects you touch to deploy ASM — tap each card

The front names the object; the back gives you the "so what" — why it matters and where it lives.

🧩
ASM module
tap to flip

Provisioned at System ▸ Resource Provisioning (Nominal). So what: until it's provisioned the Application Security menu doesn't exist — there's no policy to build. Nominal shares box resources with LTM; Dedicated starves the others.

📄
Security policy
tap to flip

The rule set ASM enforces, built with the policy wizard. So what: on its own it's just a configuration object. It inspects nothing until it's associated with a virtual server.

🎯
Virtual server
tap to flip

The IP:port listener clients connect to (e.g. 10.10.20.5:443). So what: this is the inspection point — the policy attaches here via Security ▸ Policies. It also needs an HTTP profile and, for HTTPS, a Client SSL profile.

✅
Apply Policy
tap to flip

Commits staged ASM changes so they go live. So what: every ASM edit sits in the editor until you Apply. Forget it and your attach (and every later tweak) never takes effect.

Quick check · Q3 of 10

You created a security policy but no traffic is being inspected at all. The policy itself looks correct. Most likely cause?

Correct: a. A policy with no virtual-server association inspects nothing. Associate it on the virtual server's Security ▸ Policies tab (which writes a Local Traffic Policy enabling ASM) and Apply. This is the most common day-one deployment miss.

Pause & Predict

An enforced signature is matching. The policy is in Blocking mode. But this signature has only its Alarm flag ticked — not Block. Will the request be dropped or just logged? Type your guess.

Answer: Just logged, then allowed through. Alarm = write a violation entry (and a support ID); Block = drop the request. Both flags are independent — for an actual block you need Block ticked, the signature enforced, AND the policy in Blocking mode. That's Path 4.

④ Transparent vs Blocking — the go-live decision

You've provisioned, built, and attached. The last choice decides whether your brand-new WAF is a quiet observer or an active gate: the policy's enforcement mode. Get this wrong on day one and you either protect nothing or block real customers.

Transparent — observe and tune

Transparent mode means ASM inspects every request and logs violations — but never drops anything. This is how you go live safely: watch real traffic, see which violations are real attacks vs your own app's quirks (false positives), and tune them out. No legitimate user is ever blocked while you learn.

Blocking — enforce for real

Blocking mode means ASM drops requests that trigger a violation set to Block, and serves the user a blocking response page with a support ID. You only flip to Blocking once Transparent-mode tuning has cleared the false positives. The flip is the actual moment the WAF starts protecting the app.

So the safe go-live sequence is: deploy in Transparent → observe & tune for a window → switch to Blocking. Going straight to Blocking on an untuned policy is the classic self-inflicted outage — the WAF blocks a legitimate workflow the first hour it's live.

Pro tip — Transparent is not "off"

Transparent still inspects and logs everything — you get full visibility, you just don't drop. Treat it as your tuning runway, not as "the WAF is disabled". The Event Log in Transparent mode is exactly what tells you whether a Block-mode flip will be clean or cause an outage.

tmsh — confirm ASM is provisioned and the policy is attached + Transparent
root@(bigip01)(cfg-sync Standalone)(Active)(/Common)(tmos)# list sys provision asm
# then confirm the policy + its enforcement mode:
list asm policy /Common/app_pol enforcement-mode
list ltm virtual /Common/app_vs security-policy
Expected output
sys provision asm { level nominal }
asm policy /Common/app_pol { enforcement-mode transparent }
ltm virtual /Common/app_vs { security-policy /Common/app_pol }
# ASM provisioned (nominal), policy attached to app_vs, currently Transparent (logs only).
tmsh — after tuning, flip the policy to Blocking and apply
root@(bigip01)(tmos)# modify asm policy /Common/app_pol enforcement-mode blocking
root@(bigip01)(tmos)# modify asm policy /Common/app_pol apply
Expected output
asm policy /Common/app_pol { enforcement-mode blocking }
Policy /Common/app_pol applied. Active.
# Now violations set to Block actually drop the request and return a support ID.
https://10.10.20.4/tmui  ·  BIG-IP® Advanced WAF — Configuration utility
Local Traffic ▸
Virtual Servers
Pools
Profiles
Security ▸
Application Security
System ▸
Resource Provisioning
Local Traffic ▸ Virtual Servers : app_vs ▸ Security ▸ Policies
Destination 10.10.20.5:443   — changes apply when you click Update
① Application Security PolicyEnabled ▾
② Policy/Common/app_pol ▾  Transparent
③ HTTP Profile (required)http  ☑
④ SSL Profile (Client) — HTTPSclientssl-app  ☑
Default Poolpool_app_172.16.8
① set to Enabled to turn ASM on for this VS   ② pick your policy + note Transparent vs Blocking   ③ HTTP profile so HTTP is parsed   ④ Client SSL profile so TLS terminates and ASM sees cleartext
🖥️ Recreated for clarity — your BIG-IP console matches this. This is the screen that actually turns ASM on: set Application Security Policy to Enabled ①, pick the policy ② (here still Transparent), and confirm the HTTP ③ and Client SSL ④ profiles. Path: Local Traffic ▸ Virtual Servers ▸ (VS) ▸ Security ▸ Policies.
The trap — going straight to Blocking on an untuned policy

Don't flip a brand-new policy to Blocking on day one to "protect instantly". An untuned policy is full of false positives — legitimate parts of your own app that look suspicious. In Blocking mode, those drop real users the first hour the WAF is live: checkout breaks, the support queue explodes, and someone disables the WAF entirely. Deploy in Transparent, watch the Event Log, tune out the false positives, then switch to Blocking. The runway is the whole point.

👉 So far: Transparent = inspect + log only; Blocking = drop. Deploy Transparent → tune → Blocking. Next, see that go-live decision live.

▶ Watch the go-live decision — Transparent observes, Blocking drops

A real attack hits a tuned policy. Play the Blocking-mode drop, then Break it to see what the same request does while the policy is still in Transparent mode.

① MATCHAn attack request hits the attached policy and triggers a violation
▼
② MODE?Policy enforcement mode is Blocking — a drop is possible
▼
③ VIOLATIONThe triggered violation is set to Block → the request will be dropped
▼
④ ACTIONBlocked — request dropped, blocking page + support ID returned, violation logged
Press Play for the Blocking-mode drop. Then press Break it.

Aditya at HCL faces this

Aditya attached the policy and confirmed real attacks are showing up in the Event Log — but every one is "Alarmed", never "Blocked". The app is taking live attacks. He's sure the policy is correct.

Likely cause

The policy is still in Transparent enforcement mode. Transparent inspects and logs every violation but never drops — exactly why he sees "Alarmed/Allowed" on real attacks.

DiagnosisSecurity ▸ Application Security ▸ Policy ▸ General → check Enforcement Mode
Fix

Once the Event Log shows no false positives on legitimate traffic, set Enforcement Mode = Blocking and Apply Policy. Now violations set to Block actually drop.

Verify

Re-run the attack. The Event Log now shows the request Blocked with a support ID — not just an alarm entry.

Verify it worked — the Event Log ends the argument

Never claim the WAF is "live" from the config screen. Send a safe synthetic attack (e.g. ' OR 1=1-- from your test box), then open Security ▸ Event Logs ▸ Application ▸ Requests, filter on the support ID, and read the result. "Blocked" = policy attached + Blocking mode + violation set to Block. "Alarmed/Allowed" = the policy is attached but still Transparent (or the violation is Alarm-only) — not a box problem.

tmsh — confirm the policy is attached and what mode it's running
root@(bigip01)(tmos)# show asm policy /Common/app_pol
# then read a test request in the Event Log by support ID
Expected output
asm policy /Common/app_pol
  Virtual Servers: /Common/app_vs        Enforcement Mode: blocking
2026-06-02 14:22  src 203.0.113.7  vs 10.10.20.5:443
  Violation: Attack signature detected   Result: BLOCKED
  Support ID: 18007244126553882151
# If Virtual Servers is empty → policy not attached. If Mode = transparent → only Alarmed, never Blocked.
Quick check · Q4 of 10

A new policy is attached to the virtual server in Transparent enforcement mode. A real SQL-injection attack hits it. What does Advanced WAF do?

Correct: c. Transparent mode inspects and logs violations but never blocks — the request is allowed through. You set the enforcement mode to Blocking (and the violation to Block) for the request to actually be dropped. Transparent is the safe tuning runway, not "off".
Figure 4 — Straight-to-Blocking vs Transparent-first: the same go-live, two very different days
A before-and-after panel and a deploy-order cheat-sheet. On the left, straight to Blocking: an untuned policy drops legitimate users on day zero because its false positives are never reviewed, breaking checkout and causing a P1 outage. On the right, Transparent first: the same policy only logs violations during a tuning window, the engineer clears the false positives, then switches to Blocking with no customer impact. Below, a five-tile cheat-sheet lists the deploy order: full proxy, provision ASM at Nominal, attach the policy to a virtual server, choose Transparent or Blocking, and apply, with a golden rule that a policy not attached to a virtual server inspects nothing. A new WAF can protect you — or take you down. The go-live mode decides which. ✗ Straight to Blocking — "protect instantly" Day 0: untuned policy drops on every violation false positives block REAL customers no tuning window · checkout breaks · P1 outage Result: WAF gets switched off by 11am ✓ Transparent first — observe & tune Tuning window: same policy only LOGS violations you spot the false positives → tune them out real attacks logged · no customer blocked Result: switch to Blocking safely, ship ① Full proxy terminate + reassemble TLS ends on the VS reverse proxy ② Provision Resource Provisioning ASM = Nominal menu appears ③ Attach to VS Security ▸ Policies no VS → no inspect + HTTP + Client SSL ④ Mode Transparent → log tune, then Blocking Blocking → drop ⑤ Apply commits the change nothing's live until you Apply GOLDEN RULE A policy not attached to a virtual server inspects NOTHING. Deploy Transparent, tune, then Blocking. Apply commits. Attach: Local Traffic ▸ Virtual Servers ▸ (VS) ▸ Security ▸ Policies | log of truth: Security ▸ Event Logs ▸ Application ▸ Requests 303 anchor: full proxy, ASM provisioning, security-policy association, Transparent vs Blocking deployment.
The before/after that justifies the whole deployment discipline: straight-to-Blocking on an untuned policy is an outage; Transparent-first is a clean go-live. Screenshot the bottom tiles — that's the deploy order.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from F5 techdocs + DevCentral, scoped to BIG-IP Advanced WAF (formerly ASM) architecture & deployment. For a live prod issue, paste your Event-Log export into chat.techclick.in.

📝 Wrap-up assessment — six more

You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.

Q5 · Remember

What must be true before you can configure any ASM security policy on a BIG-IP?

Correct: b. Until ASM is provisioned (System ▸ Resource Provisioning, usually Nominal), the Security ▸ Application Security menu isn't even available — there's no policy to build. Provisioning is always step one.
Q6 · Apply

Sneha at Infosys is deploying ASM in front of a revenue-critical app for the first time. Which go-live approach has the least risk of a false-positive outage?

Correct: a. Transparent first lets you watch real traffic and clear false positives with zero customer impact; you flip to Blocking once it's tuned. Going straight to Blocking on an untuned policy (b) is the classic day-one self-inflicted outage.
Q7 · Analyze

In the BIG-IP full-proxy data path, where does the client's TLS session terminate so ASM can inspect cleartext HTTP?

Correct: c. TLS terminates on the virtual server (client SSL profile), so the BIG-IP decrypts and ASM sees cleartext HTTP. For an HTTPS back-end a server SSL profile re-encrypts to the pool. The session is not end-to-end to the pool member.
Q8 · Analyze

After attaching the policy to the virtual server and clicking Apply, inspection still doesn't start on your HTTPS app. Most likely missing step?

Correct: b. ASM needs the virtual server to terminate and parse the traffic. No Client SSL profile on an HTTPS app = encrypted bytes only = ASM is blind; no HTTP profile = HTTP isn't parsed. Check the virtual server's SSL and HTTP profiles.
Q9 · Evaluate

A team can't change the application's default gateway, so they propose deploying ASM as a one-armed (single-interface, SNAT) reverse proxy instead of routed inline. Sound design?

Correct: d. ASM rides on a virtual server regardless of inline-routed or one-armed topology. One-armed (with SNAT so return traffic comes back through the BIG-IP) is a normal choice when you can't change the app's default gateway. Pick based on the network, not a WAF limitation.
Q10 · Evaluate

A junior engineer wants to provision ASM at Dedicated "to make it faster" on a box that also runs LTM. For a combined LTM+ASM box, sound design?

Correct: c. Dedicated allocates everything to one module, leaving none for the others — LTM would be starved. On a combined LTM+ASM box you provision each module you run at Nominal so resources are shared. Dedicated is only for a single-purpose device.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again".

🧠 In your own words

Type one line: you built a security policy but nothing is being inspected — what's the most likely cause, and how does a request actually reach ASM? Then compare to the expert version.

Expert version: The policy almost certainly isn't attached to a virtual server — a policy with no virtual-server association inspects nothing. A request reaches ASM because the BIG-IP is a full proxy: the client connects to the virtual server, TLS terminates there (client SSL profile), the BIG-IP reassembles the full HTTP request, the attached ASM policy inspects it, and then a separate connection re-encrypts to the pool. Attach the policy on the virtual server's Security ▸ Policies tab, confirm the HTTP + Client SSL profiles, and Apply. If you mentioned "attach to the virtual server, full proxy, TLS terminates there", you've got it.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📖 Glossary

Full proxy
The BIG-IP terminates the client TCP/TLS connection and reassembles the whole HTTP request, then opens a separate connection to the pool. Two independent connections, not one pass-through — this is what lets ASM inspect the complete application layer.
Reverse proxy
Clients connect to the BIG-IP virtual server (the published address), not directly to the back-end server. ASM speaks for the server.
Virtual server
The BIG-IP listener — an IP:port (e.g. 10.10.20.5:443). Profiles, the pool, and the ASM security policy all attach here. It is the inspection point.
Security policy
The rule set ASM enforces on requests/responses. It must be ASSOCIATED with a virtual server (via a Local Traffic Policy / Security ▸ Policies) to inspect anything.
Local Traffic Policy
An LTM policy that enables ASM and applies a security policy on a virtual server — the plumbing that links a virtual server to an ASM policy on modern versions.
Provisioning
Allocating CPU/memory to a module so it runs (System ▸ Resource Provisioning). Levels: None / Minimum / Nominal / Dedicated. Until ASM is provisioned, the Application Security menu doesn't exist.
Nominal vs Dedicated
Nominal shares box resources across the modules you run (e.g. LTM + ASM). Dedicated gives one module everything and starves the others — only for a single-purpose box.
Client SSL profile
The profile on the virtual server that terminates the client's TLS so the BIG-IP decrypts and ASM sees cleartext HTTP. (A server SSL profile re-encrypts to an HTTPS back-end.)
Enforcement mode (Transparent vs Blocking)
Transparent = ASM detects and logs violations but never drops. Blocking = ASM drops requests that trigger a violation set to Block. Deploy Transparent, tune, then switch to Blocking.
Apply Policy
Commits staged ASM changes so they go live. Every ASM edit (attach, mode change) stays in the editor until you Apply.

📚 Sources

  1. F5 techdocs — BIG-IP Advanced WAF / ASM: Implementations & About security policies (ASM provisioning, building a policy, associating a security policy with a virtual server; Rapid Deployment template). techdocs.f5.com
  2. F5 techdocs — BIG-IP Local Traffic Management: Basics & Virtual server & profile concepts (virtual server = listener; HTTP profile, client/server SSL profiles, pool; full-proxy architecture and SSL termination on the virtual server). techdocs.f5.com
  3. F5 article K12313127 / K14947 — Overview of BIG-IP module resource provisioning (System ▸ Resource Provisioning; None/Minimum/Nominal/Dedicated; provision each module at Nominal on a multi-module box). my.f5.com
  4. F5 techdocs — Enforcement modes for security policies (Transparent = detect/log only; Blocking = drop; deploy Transparent first then switch to Blocking after tuning). techdocs.f5.com
  5. F5 DevCentral — The BIG-IP is a full proxy & ASM deployment walk-throughs (why a WAF must terminate + reassemble; reverse-proxy topologies, routed inline vs one-armed with SNAT). community.f5.com
  6. r/networking & r/f5networks practitioner threads — "ASM policy built but nothing inspected = not attached to a virtual server" and "deploy in Transparent, tune, then Blocking". reddit.com
  7. F5 Certification — 303 — BIG-IP ASM Specialist Exam Blueprint (full-proxy architecture, ASM provisioning, policy creation & virtual-server association, deployment modes; cert anchor: 90 min, 80 questions, pass 245/350). education.f5.com / f5.com

What's next?

You can now place ASM correctly in the data path: full proxy, on a virtual server, provisioned and attached, and deployed Transparent-then-Blocking. Next, go inside the policy itself — building a security policy: templates, the policy wizard, learning, and the building blocks ASM uses to protect an app. After that, attack signatures give you the negative-security engine.

Next · F5 ASM Building a Security Policy → Practice for the 303 on exam.techclick.in →