Filter
Top Products
Fortinet 266 FortiWeb 5.0 Patch 6 Administration Guide
alias. When configuring FortiWeb, each web server was defined using its DNS alias, rather than
its IP address:
• www1.example.com — Hosts www.example.com, plus all other host names’ content, in
case th
e other web servers fail or have scheduled down time
• www2.example.com — Hosts www.example.de
• www3.example.com — Hosts www.example.cn & www.example.co.jp
While public DNS servers all resolve
thes
e aliases to the same IP address — FortiWeb’s virtual
server — your private DNS server resolves these DNS names to separate IPs on your private
network: the back-end web servers.
• www1.example.com — Resolves to 192.168.0.1
• www2.
example.com — Resolves to 192.168.0.2
• www3.example.com — Resolves to 192.168.0.3
In this case, you would configure HTTP content routing so FortiWeb routes requests from clients
base
d up
on the original Host: field in the HTTP header to the appropriate DNS alias. The
destination back-end web server would be determined at request time using server health
check statuses, as well private network DNS to resolve the DNS alias into its current private
network IP address:
• http://www.example.com/ — Routes to www1.example.com
• ht
tp://www.example.de/ — Routes to www2.example.com, unless that web server is down,
in which case those requests will be routed to www1.example.com
• http://www.example.cn/ & http://www.example.co.jp/ — Routes to www3.example.com,
unless that web server is down, in which case those requests would be routed to
www1.example.com
If necessary to maintain HTTP session continuity f
or
web applications, you would also configure
Host: name and hyperlink rewriting so that subsequent requests from the client would be
forwarded to the same back-end web server.
See also
• Routin
g based upon URL or “Host:” name
• Rewriting & redirecting
• Defining your web server by its DNS domain name
• Grouping your web servers into server farms
• Configuring server up/down checks
Defining your proxies, clients, & X-headers
In some topologies, you must configure FortiWeb’s use of X-headers such as
X-Forwarded-For:, X-Real-IP:, or True-Client-IP:, including when:
• FortiWeb has been deployed behind a proxy/load balancer which applies NAT.
Conn
ection-wise, this causes all requests appear to come from the IP address of the proxy
or load balancer, not the original client. FortiWeb requires the true client’s source IP so
that when blocking attacks, it does not block the proxy/load balancer’s IP, affecting
innocent requests. FortiWeb also requires some way to derive the original client’s IP so that