FortiWeb

Initial Server Policy Configuration in FortiWeb: A Step-by-Step Guide for Exposing a System Behind FortiWeb as Reverse Proxy

This article outlines the initial FortiWeb 7.6 configuration for exposing an internal system behind FortiWeb in reverse proxy mode. It focuses on Virtual Server, Server Pool, Protected Host and Server Policy, and provides GUI steps, CLI samples, SSL considerations, logging, health checks, and an operational checklist.

2026/06/25 14 min read

پشتیبانی شبکه
Server
FortiWeb
Policy
Host
Certificate
backend
Pool

Initial Server Policy Configuration in FortiWeb: A Step-by-Step Guide for Exposing a System Behind FortiWeb as Reverse Proxy

خلاصه تخصصی مقاله

موضوعات اصلی: پشتیبانی شبکه، Server، FortiWeb، Policy، Host، Certificate

1. What is Server Policy in FortiWeb?

In FortiWeb, the Server Policy is the interface between the network, the backend, and the security layers. Simply put, it defines which Virtual Server FortiWeb should receive traffic from, which Server Pool to forward it to, and which security profiles and SSL/TLS settings to apply.

According to the CLI Reference version 7.6.6, FortiWeb applies only one Server Policy per connection. Therefore, the order, naming, Host Matching, Virtual Server, and Server Pool must be designed precisely; otherwise traffic may be forwarded to the wrong place or not inspected at all by FortiWeb.

Note In a Reverse Proxy scenario, the Server Policy is typically the most operationally important object in FortiWeb, because most key settings such as Virtual Server, Server Pool, Certificate, HTTP to HTTPS, HSTS, Web Protection Profile, HTTP/2, and logging are connected through this policy.

2. Main components of a Policy in FortiWeb 7.6

To ensure a correct Server Policy, several core objects must be prepared first. The recommended order is to define the Virtual Server and Server Pool first, and prepare Protected Host, HTTP Content Routing, Certificate, and Web Protection Profile as needed.

Object	Role in FortiWeb	Example
Virtual Server	Address and interface where FortiWeb receives user traffic.	203.0.113.10:443
Server Pool	List of one or more backend servers that receive requests.	10.10.10.21:443, 10.10.10.22:443
Protected Host	Domain name or Host Header allowed to be protected.	app.example.com
Certificate	SSL/TLS certificate FortiWeb uses for the client side.	wildcard-example-com
Web Protection Profile	Security settings such as Signatures, HTTP Constraints, URL Access, Parameter Validation, Bot Mitigation.	WPP-App-Initial-Monitor
Server Policy	Final object that ties all the above together.	SP-App-HTTPS

3. Example scenario for publishing a system

Consider a simple yet realistic scenario: an internal system hosted on two web servers, exposed to internet users via HTTPS.

Item	Sample Value
Service FQDN	app.example.com
Public IP or VIP on FortiWeb	203.0.113.10
First Real Server	10.10.10.21:443
Second Real Server	10.10.10.22:443
Operational Mode	Reverse Proxy
Client Side	HTTPS/443
Backend	HTTPS/443

Design consideration If Real Servers are directly reachable, it may bypass FortiWeb. Backend should be accessible only via FortiWeb or approved internal routes.

4. Prerequisites before creating Policy

Before you create a Server Policy in FortiWeb, ensure the following are defined. Missing details can lead to SSL errors, backend access issues, incorrect Host Headers, or ambiguous logs during testing.

Accurate service FQDN and DNS records
IP or VIP that users should reach
Interface receiving traffic on FortiWeb
Backend servers' IPs and ports
Backend HTTP or HTTPS usage
Client-side Certificate on FortiWeb
Need for SNI or a simple certificate suffices
HTTP to HTTPS Redirect requirement
Initial Web Protection Profile in Monitor or Block mode
Logging path on FortiWeb and FortiAnalyzer

5. Step 1: Create the Virtual Server

The Virtual Server defines on which interface and which IP FortiWeb receives traffic. In a Reverse Proxy setup, the Destination IP seen by the client is typically the Virtual Server IP.

Server Objects → Server → Virtual Server → Create New

Field	Sample Value
Name	VS-App-HTTPS
Interface	port1
IP Address	203.0.113.10
Status	Enable

Sample CLI

config server-policy vserver edit "VS-App-HTTPS"
config vip-list edit 1
set interface "port1"
set vip "203.0.113.10"
set status enable
next
end
next
end

Note The Virtual Server is not the backend. The Virtual Server is where FortiWeb receives user traffic; the backend is defined in the Server Pool.

6. Step 2: Define Server Pool and Real Server

Server Pool groups one or more backend servers that FortiWeb forwards requests to. In Reverse Proxy, FortiWeb can distribute between pool servers, e.g., by Round Robin or Least Connections.

Server Objects → Server → Server Pool → Create New

Field	Value
Name	POOL-App-HTTPS
Type	Reverse Proxy
Load Balancing	Round Robin / Least Connections
Server 1	10.10.10.21:443
Server 2	10.10.10.22:443
SSL to Backend	Enable

Sample CLI

config server-policy server-pool edit "POOL-App-HTTPS"
set type reverse-proxy
set protocol HTTP
set lb-algo round-robin
set server-balance enable
config pserver-list edit 1
set server-type physical
set ip 10.10.10.21
set port 443
set ssl enable
set status enable
next
edit 2
set server-type physical
set ip 10.10.10.22
set port 443
set ssl enable
set status enable
next
end
next
end

Health Check

If multiple backends exist, Health Check is essential. Without a proper Health Check, FortiWeb may route traffic to a backend that is down or returning incorrect HTTP responses.

Health Check path can be simple TCP/443; for sensitive systems, verify the real path such as a login page or health endpoint. Example: GET /health

7. Step 3: Define Protected Host Names

Protected Host defines which Host Header value FortiWeb should consider valid for this service. If the service is published for a specific FQDN, defining Protected Host helps to validate requests with unknown or incorrect Host headers at the WAF layer.

Server Objects → Protected Hosts → Create New

Field	Value
Name	HOST-App
Host	app.example.com

Sample CLI

config server-policy allow-hosts edit "HOST-App"
config allow-hosts-list edit 1
set host-type fqdn
set host "app.example.com"
next
end
next
end

Operational note Protected Host is different from Real Server. Protected Host relates to the HTTP Host Header used by the client; Real Server is typically the internal backend IP.

8. Step 4: Prepare Certificate and HTTPS

If users access the service via HTTPS, a certificate must exist on FortiWeb. This may be a certificate for the FQDN, a wildcard certificate, or an SNI configuration.

System → Certificates → Local → Import

For simple scenarios, select a certificate on the Server Policy. If multiple FQDNs share one IP, consider SNI.

Scenario	Recommendation
One domain on one IP	One Local Certificate on the Server Policy is enough.
Multiple domains on one IP	Use SNI Configuration or Certificate Group.
HTTPS from FortiWeb to Backend	Enable SSL in Real Server entries within the Server Pool.
HTTP to HTTPS	Enable HTTP-to-HTTPS on the Server Policy.

9. Step 5: Choose the initial Web Protection Profile

Web Protection Profile combines FortiWeb security settings. If you are unsure about application behavior, start with a conservative profile in Monitoring mode and enable logging; adjust actions later based on logs.

Policy → Web Protection Profile → Inline Protection Profile

Recommendations for initial config

Signatures: start in Alert/Monitor mode
HTTP Protocol Constraint: avoid overly strict values initially
Parameter Validation: enable only after parameters are known
Bot Mitigation: enable carefully on specific paths such as login
Upload/Download Paths: validate separately

Warning A common pitfall is enabling all security modules to Block on first release, which may cause false positives and service disruption. Start with visibility and full logging, then tighten the policy.

10. Step 6: Create the Server Policy

With Virtual Server, Server Pool, Protected Host, Certificate and Web Protection Profile prepared, create the Server Policy. This policy defines that inbound HTTPS traffic from the Virtual Server is forwarded to the internal Server Pool with the Web Protection Profile applied along the way.

Policy → Server Policy → Server Policy → Create New

Field	Suggested Value
Name	SP-App-HTTPS
Deployment Mode	Server Pool
Virtual Server	VS-App-HTTPS
Server Pool	POOL-App-HTTPS
Protected Host Names	HOST-App
Service	HTTPS
Certificate	wildcard-example-com
Web Protection Profile	WPP-App-Initial-Monitor
Status	Enable

Sample CLI

config server-policy policy edit "SP-App-HTTPS"
set status enable
set protocol HTTP
set deployment-mode server-pool
set vserver "VS-App-HTTPS"
set server-pool "POOL-App-HTTPS"
set allow-hosts "HOST-App"
set service "HTTPS"
set HTTPS-service "HTTPS"
set ssl enable
set certificate "wildcard-example-com"
set HTTP-to-HTTPS enable
set hsts-header enable
set hsts-max-age
set web-protection-profile "WPP-App-Initial-Monitor"
set monitor-mode enable
set client-real-ip disable
set syncookie enable
next
end

Note Object names may differ in your environment. Verify exact object names with show/edit queries before running CLI.

When to enable Client Real IP?

In Reverse Proxy mode, the backend typically sees FortiWeb's IP. If you need the backend to see the actual client IP, enable Client Real IP, but ensure correct return routing and gateway configuration. Often using headers like X-Forwarded-For is sufficient and less risky.

11. Test, logging and initial troubleshooting

After Server Policy creation, simply loading the homepage is not enough. Validate SSL, Host Header, login path, uploads, APIs, redirects and logs.

Basic client-side tests

curl -vk https://app.example.com/
curl -vk -H "Host: app.example.com" https://203.0.113.10/
curl -I http://app.example.com/
curl -I https://app.example.com/

Logs to check

Traffic Log for requests
Attack Log for Signature matches or Policy violations
Initial actions: Alert vs Deny
Host Header visibility
Backend latency or server response time
SSL handshake errors

Log & Report → Log Access → Traffic

Log & Report → Log Access → Attack

12. Common mistakes in initial FortiWeb configuration

Common Mistake	Potential Impact	Solution
Confusing Virtual Server with Backend Server	Traffic may not match a policy or go to the wrong destination	Define Virtual Server for the user-facing IP and Server Pool for the backend
Not defining Protected Host	Requests from unknown hosts may pass into the policy	Create Protected Host for each primary FQDN
Starting with Block on day one	False positives and service disruption	Start with Monitor/Alert, tighten gradually
No proper Health Check	Traffic may go to a faulty or down backend	Define real health checks per service
Direct access to Backend	Bypass FortiWeb	Restrict direct access on Firewall or routing
Wrong certificate selection	SSL errors or browser warnings	Use correct certificate, key and chain for the FQDN

13. Best Practice recommended by XNET

For each critical system, create separate Server Policy and avoid reusing generic policies
Standardize naming: prefix objects with VS, POOL, HOST, WPP and SP
In early release, start with lower-risk actions in Web Protection Profile and tighten after logs
Define Protected Host for each FQDN to validate Host Headers
If backend uses HTTPS, review SSL on backend and Certificate verification separately
For sensitive services, health checks should verify real service path, not just TCP
Limit user direct access to backend via firewall or routing
Before service handover, verify Traffic and Attack logs and send logs to FortiAnalyzer

14. Final checklist before service handover

Item	Target State
DNS	FQDN resolves to the correct IP or VIP on FortiWeb
Virtual Server	Interface, IP and Status configured correctly
Server Pool	All backends defined with IP, port, SSL and Health Check
Protected Host	Authorized FQDNs defined
Certificate	Certificate, Private Key and Chain complete
Server Policy	Virtual Server, Server Pool, Protected Host, Certificate and Web Protection Profile linked to Policy
HTTP to HTTPS	Redirect enabled and tested if required
Logging	Traffic and Attack logs visible in FortiWeb and FortiAnalyzer
Security Profile	Initially enabled in a controlled mode, then switched to Block after log review
Bypass Prevention	Direct access to Backend from outside or unauthorized networks blocked

برای ارزیابی پایداری، امنیت و نگهداری این زیرساخت، راهنمای پشتیبانی شبکه را نیز مطالعه کنید.