Responder & Rewrite Policies Explained

1. Problem Statement

In real-world systems, traffic is not always “forward as-is”.

You often need to:

• Redirect users (HTTP → HTTPS)

• Block unwanted or malicious requests

• Modify requests before they reach backend servers

• Handle backend limitations without changing application code

Without this capability:

• Security risks increase

• Backend dependency grows

• Simple fixes require code deployment

👉 This is where Responder and Rewrite policies come in.

---

2. Concept Explanation

What is a Responder Policy?

Responder Policy takes an immediate action on a request.

• It does NOT forward traffic

• It ends the request lifecycle at the load balancer

Examples:

• Redirect HTTP → HTTPS

• Block a request

• Send a custom response

👉 Think of it like a security guard at the gate

• “Stop”

• “Go somewhere else”

• “You are not allowed”

---

What is a Rewrite Policy?

Rewrite Policy modifies the request or response and then allows it to continue.

• Traffic still goes to backend

• Only data is adjusted

Examples:

• Add headers

• Modify URLs

• Insert client IP

👉 Think of it like a translator

• Message changes, but flow continues

---

Key Difference (Simple View)

Responder	Rewrite
Takes action immediately	Modifies and forwards
Ends request	Continues request
Used for redirect/block	Used for modification

---

3. Types / Variations

1. Redirect (HTTP → HTTPS)

• Force secure communication

• Most common use case

---

2. Block Request

• Block suspicious IPs

• Stop unwanted bots or traffic

---

3. Modify Headers

• Add headers like:

  • X-Forwarded-For

  • X-Client-IP

---

4. URL Rewrite (High Level)

• Change incoming request path

• Example:

  • /old → /new

---

4. How It Works Internally

Step-by-step flow:

1. Client sends request to Load Balancer

2. Load Balancer evaluates policies (based on priority)

3. Match found → action triggered:

   • Redirect → client sent new URL

   • Block → request dropped

   • Modify → request updated

4. Request either:

   • Stops at LB

   • OR continues to backend server

👉 Policies act like a decision engine inside the LB

---

5. Diagram

Diagram: Rewrite_Responder_Loadbalancer_Diagram.png

• Client → Load Balancer

• Policy Check (decision box)

• Outcomes:

  • Redirect (HTTPS)

  • Forward to Server

  • Block Request

---

6. Real-World Example

1. Force HTTPS

• Redirect all HTTP traffic to HTTPS

• Improves security instantly

---

2. Block Unwanted Traffic

• Block specific IP ranges

• Stop bot traffic early

---

3. Add Headers for Backend

Example:

• Add X-Forwarded-For

• Backend logs real client IP

---

7. Common Issues / Pitfalls

1. Wrong Policy Order

• Policies are evaluated top-down

• Incorrect priority breaks logic

---

2. Conflicting Rules

• Multiple matching policies cause unpredictable behavior

---

3. Debugging Complexity

• Hard to identify which policy triggered

• Requires logs and tracing

---

8. Try It Yourself

Try it yourself 👇

👉 Open Full Visualizer

---

9. Key Takeaways

• Responder = Action + Stop

• Rewrite = Modify + Continue

• Used for redirect, block, and modification

• Reduces backend dependency

• Improves security and flexibility

---

10. Conclusion

Responder and Rewrite policies give load balancers real-time control over traffic.

Instead of changing application code, you can:

• Redirect users

• Block threats

• Modify requests

👉 All at the edge.

---

11. Series Continuity

Previous: Content Switching
Next: Rate Limiting & Protection

---

12. Final Thought

Smart traffic control at the load balancer means:

👉 Faster fixes
👉 Better security
👉 Less dependency on backend

---

13. Practical: NetScaler Hands-on

13.1 Mini Lab

1. Create HTTP → HTTPS redirect

2. Apply responder policy to vServer

---

13.2 Variation / Experiment

• Add header using rewrite policy

• Block request for specific URL

---

13.3 Commands (5 examples with comments)

# 1. Redirect HTTP to HTTPS (Responder Policy)
# Forces all HTTP requests to secure HTTPS
add responder policy redirect_http_to_https "HTTP.REQ.IS_VALID" \
"redirect \"https://\" + HTTP.REQ.HOSTNAME + HTTP.REQ.URL.PATH"

# 2. Bind Responder Policy to vServer
# Priority decides execution order (lower = evaluated first)
bind responder policy redirect_http_to_https -vserver vs_http -priority 100

# 3. Add Header using Rewrite Action
# Inserts client IP so backend knows original requester
add rewrite action add_xff insert_http_header X-Forwarded-For CLIENT.IP.SRC

# 4. Create Rewrite Policy
# Always apply header modification (can be condition-based)
add rewrite policy add_xff_policy "true" add_xff

# 5. Bind Rewrite Policy to vServer
# Applied after responder policies (based on priority)
bind rewrite policy add_xff_policy -vserver vs_http -priority 110