Fortinet white logo
Fortinet white logo

CLI Reference

waf x-forwarded-for

waf x-forwarded-for

Use this command to configure FortiWeb’s use of X-Forwarded-For: and X-Real-IP:.

For behavior of this feature and requirements, see the FortiWeb Administration Guide:

HTTPS://docs.fortinet.com/fortiweb/admin-guides

To use this command, your administrator account’s access control profile must have either w or rw permission to the wafgrp area. For details, see Permissions.

Syntax

config waf x-forwarded-for

edit "<x-forwarded-for_name>"

set block-based-on-original-ip {enable | disable}

set ip-location {left | right}

set original-ip-header "<HTTP-header-key_str>"

set tracing-original-ip {enable | disable}

set x-forwarded-proto {enable | disable}

set merge-headers {enable | disable}

set delete-headers {enable | disable}

set x-forwarded-for-support {enable | disable}

set ip-location-add {left | right}

set x-real-ip {enable | disable}

set skip-private-original-ip {enable | disable}

set add-source-port {enable | disable}

set x-forwarded-port {enable | disable}

config ip-list

edit <entry_index>

set ip "<load-balancer_ip>"

next

end

next

end

Variable Description Default

"<x-forwarded-for_name>"

Enter the name of the new or existing group. The maximum length is 63 characters.

To display the list of existing groups, enter:

edit ?

No default.

block-based-on-original-ip {enable | disable}

Enable to be able to block requests that violate your policies by using the original client’s IP derived from this HTTP X-header.

When disabled, only attack logs and reports will use the original client’s IP.

disable

ip-location {left | right}

Select whether to extract the original client’s IP from either the left or right end of the HTTP X-header line.

If there are multiple X-headers, "left" is the left location of the first x-header, and "right" is the right location of the last x-header.

Most proxies put the request’s origin at the left end, which is the default setting. Some proxies, however, place it on the right end.

right

original-ip-header "<HTTP-header-key_str>"

Enter the key of the X-header, such as X-Forwarded-For X-Real-IP, without the colon ( : ), that contains the original source IP address of the client. Also configure tracing-original-ip {enable | disable} and, for security reasons, ip "<load-balancer_ip>".

Maximum length is 256 characters.

No default.

tracing-original-ip {enable | disable}

If FortiWeb is deployed behind a device that applies NAT, enable this option to derive the original client’s source IP address from an HTTP X-header, instead of the SRC field in the IP layer. Also configure original-ip-header "<HTTP-header-key_str>" and, for security reasons, ip "<load-balancer_ip>".

This HTTP header is often X-Forwarded-For: when traveling through a web proxy, but can vary. For example, the Akamai service uses True-Client-IP:.

For deployment guidelines and mechanism details, see the FortiWeb Administration Guide:

HTTPS://docs.fortinet.com/fortiweb/admin-guides

Caution: To combat forgery, configure the IP addresses of load balancers and proxies that are trusted providers of this header. Also configure those proxies/load balancers to reject fraudulent headers, rather than passing them to FortiWeb.

disable

merge-headers {enable | disable}

Enable to merge all the previous X-Forward-For headers into one header to create an IP list.

Headers are merged based on their location in the request, which means the IPs of the first header will be at the beginning of the new list followed by the IPs of the next header.

The Delete Previous XFF Headers is executed before Merge Previous XFF Headers. If these two options are both enabled, Merge Previous XFF Headers actually takes no effect because all the previous XFF Headers have already been deleted.

disable

delete-headers {enable | disable}

Enable to delete all the previous X-Forward-For headers. If x-forwarded-for-support is enabled, the request will only have one header and one IP which is created by FortiWeb.

disable

x-forwarded-for-support {enable | disable}

Enable to include the X-Forwarded-For: HTTP header on requests forwarded to your web servers. Behavior varies by the header already provided by the HTTP client or web proxy, if any:

  • Header absent—Add the header, using the source IP address of the connection.
  • Header present—Verify that the source IP address of the connection is present in this header’s list of IP addresses. If it is not, append it.

This option can be useful for web servers that log or analyze clients’ IP addresses, and support the X-Forwarded-For: header. When this option is disabled, from the web server’s perspective, all connections appear to be coming from the FortiWeb appliance, which performs network address translation (NAT). But when enabled, the web server can instead analyze this header to determine the source and path of the original client connection.

This option applies only when FortiWeb is operating in Reverse Proxy mode or True Transparent Proxy.

disable

ip-location-add {left | right}

Left: Add IP address at the leftmost position of the first header.

Right: Add IP address at the rightmost position of the last header.

Available only when x-forwarded-for-support is enabled.

left

x-real-ip {enable | disable}

Enable to include the X-Real-IP: HTTP header on requests forwarded to your web servers. Behavior varies by the header already provided by the HTTP client or web proxy, if any. For details, see x-forwarded-for-support {enable | disable}).

Like X-Forwarded-For:, this header is also used by some proxies and web servers to trace the path, log, or analyze based upon the packet’s original source IP address.

This option applies only when FortiWeb is operating in Reverse Proxy or True Transparent Proxy mode.

disable

skip-private-original-ip {enable | disable}

Enable to skip the private original IP that indicates the service used in the client’s original request.

enable

x-forwarded-proto {enable | disable}

Enable to add an HTTP header that indicates the service used in the client’s original request.

Usually if your FortiWeb is receiving HTTPS requests from clients, and it is operating in Reverse Proxy mode, SSL/TLS is being offloaded. FortiWeb has terminated the SSL/TLS connection and the second segment of the request, where it forwards to the back-end servers, is clear text HTTP. In some cases, your back-end server may need to know that the original request was, in fact, encrypted HTTPS, not HTTP.

disable

<entry_index>

Enter the index number of the individual entry in the table.

The valid range is 1–9,223,372,036,854,775,807.

Each list can contain a maximum of 256 IP addresses.

No default.

ip "<load-balancer_ip>"

Type the IP address of a load balancer or proxy that is in front of the FortiWeb appliance (between the client and FortiWeb).

To apply anti-spoofing measures and improve security, FortiWeb trusts the contents of the HTTP header that you specify in original-ip-header "<HTTP-header-key_str>" only if the packet arrived from one of the IP addresses you specify here. It regards original-ip-header "<HTTP-header-key_str>" from other IP addresses as potentially spoofed.

For packets from other IP addresses, FortiWeb ignores the X-Forwarded-For: header and uses the source IP address in the IP header as the client source address. This IP address is displayed in the attack log message.

No default.

add-source-port {enable | disable}

Enable to add an X-Forwarded-For: header with the connection's source IP. If this field is enabled, the source port of the request will be added as well.

Available only when FortiWeb operates in Reverse Proxy, True Transparent Proxy, or WCCP mode.

disable

x-forwarded-port {enable | disable}

Enable to add an X-Forwarded-Port: header with the connection's destination port.

Available only when FortiWeb operates in Reverse Proxy, True Transparent Proxy, or WCCP mode.

disable

Example

The following example defines a X-Forwarded-For rule that adds X-Forwarded-For:, X-Real-IP:, and X-Forwarded-Proto: headers to traffic that FortiWeb forwards to a back-end server. It enables FortiWeb to use the HTTP X-Header to identify and block the original client's IP. To protect against XFF spoofing, it also specifies the trusted load-balancer 192.0.2.105 in the X-Forwarded-For IP list.

config waf x-forwarded-for

edit "load-balancer1"

set x-forwarded-for-support enable

set tracing-original-ip enable

set original-ip-header X-FORWARDED-FOR

set x-real-ip enable

set x-forwarded-proto enable

config ip-list

edit 1

set ip "192.0.2.105"

next

end

set block-based-on-original-ip enable

next

end

waf x-forwarded-for

waf x-forwarded-for

Use this command to configure FortiWeb’s use of X-Forwarded-For: and X-Real-IP:.

For behavior of this feature and requirements, see the FortiWeb Administration Guide:

HTTPS://docs.fortinet.com/fortiweb/admin-guides

To use this command, your administrator account’s access control profile must have either w or rw permission to the wafgrp area. For details, see Permissions.

Syntax

config waf x-forwarded-for

edit "<x-forwarded-for_name>"

set block-based-on-original-ip {enable | disable}

set ip-location {left | right}

set original-ip-header "<HTTP-header-key_str>"

set tracing-original-ip {enable | disable}

set x-forwarded-proto {enable | disable}

set merge-headers {enable | disable}

set delete-headers {enable | disable}

set x-forwarded-for-support {enable | disable}

set ip-location-add {left | right}

set x-real-ip {enable | disable}

set skip-private-original-ip {enable | disable}

set add-source-port {enable | disable}

set x-forwarded-port {enable | disable}

config ip-list

edit <entry_index>

set ip "<load-balancer_ip>"

next

end

next

end

Variable Description Default

"<x-forwarded-for_name>"

Enter the name of the new or existing group. The maximum length is 63 characters.

To display the list of existing groups, enter:

edit ?

No default.

block-based-on-original-ip {enable | disable}

Enable to be able to block requests that violate your policies by using the original client’s IP derived from this HTTP X-header.

When disabled, only attack logs and reports will use the original client’s IP.

disable

ip-location {left | right}

Select whether to extract the original client’s IP from either the left or right end of the HTTP X-header line.

If there are multiple X-headers, "left" is the left location of the first x-header, and "right" is the right location of the last x-header.

Most proxies put the request’s origin at the left end, which is the default setting. Some proxies, however, place it on the right end.

right

original-ip-header "<HTTP-header-key_str>"

Enter the key of the X-header, such as X-Forwarded-For X-Real-IP, without the colon ( : ), that contains the original source IP address of the client. Also configure tracing-original-ip {enable | disable} and, for security reasons, ip "<load-balancer_ip>".

Maximum length is 256 characters.

No default.

tracing-original-ip {enable | disable}

If FortiWeb is deployed behind a device that applies NAT, enable this option to derive the original client’s source IP address from an HTTP X-header, instead of the SRC field in the IP layer. Also configure original-ip-header "<HTTP-header-key_str>" and, for security reasons, ip "<load-balancer_ip>".

This HTTP header is often X-Forwarded-For: when traveling through a web proxy, but can vary. For example, the Akamai service uses True-Client-IP:.

For deployment guidelines and mechanism details, see the FortiWeb Administration Guide:

HTTPS://docs.fortinet.com/fortiweb/admin-guides

Caution: To combat forgery, configure the IP addresses of load balancers and proxies that are trusted providers of this header. Also configure those proxies/load balancers to reject fraudulent headers, rather than passing them to FortiWeb.

disable

merge-headers {enable | disable}

Enable to merge all the previous X-Forward-For headers into one header to create an IP list.

Headers are merged based on their location in the request, which means the IPs of the first header will be at the beginning of the new list followed by the IPs of the next header.

The Delete Previous XFF Headers is executed before Merge Previous XFF Headers. If these two options are both enabled, Merge Previous XFF Headers actually takes no effect because all the previous XFF Headers have already been deleted.

disable

delete-headers {enable | disable}

Enable to delete all the previous X-Forward-For headers. If x-forwarded-for-support is enabled, the request will only have one header and one IP which is created by FortiWeb.

disable

x-forwarded-for-support {enable | disable}

Enable to include the X-Forwarded-For: HTTP header on requests forwarded to your web servers. Behavior varies by the header already provided by the HTTP client or web proxy, if any:

  • Header absent—Add the header, using the source IP address of the connection.
  • Header present—Verify that the source IP address of the connection is present in this header’s list of IP addresses. If it is not, append it.

This option can be useful for web servers that log or analyze clients’ IP addresses, and support the X-Forwarded-For: header. When this option is disabled, from the web server’s perspective, all connections appear to be coming from the FortiWeb appliance, which performs network address translation (NAT). But when enabled, the web server can instead analyze this header to determine the source and path of the original client connection.

This option applies only when FortiWeb is operating in Reverse Proxy mode or True Transparent Proxy.

disable

ip-location-add {left | right}

Left: Add IP address at the leftmost position of the first header.

Right: Add IP address at the rightmost position of the last header.

Available only when x-forwarded-for-support is enabled.

left

x-real-ip {enable | disable}

Enable to include the X-Real-IP: HTTP header on requests forwarded to your web servers. Behavior varies by the header already provided by the HTTP client or web proxy, if any. For details, see x-forwarded-for-support {enable | disable}).

Like X-Forwarded-For:, this header is also used by some proxies and web servers to trace the path, log, or analyze based upon the packet’s original source IP address.

This option applies only when FortiWeb is operating in Reverse Proxy or True Transparent Proxy mode.

disable

skip-private-original-ip {enable | disable}

Enable to skip the private original IP that indicates the service used in the client’s original request.

enable

x-forwarded-proto {enable | disable}

Enable to add an HTTP header that indicates the service used in the client’s original request.

Usually if your FortiWeb is receiving HTTPS requests from clients, and it is operating in Reverse Proxy mode, SSL/TLS is being offloaded. FortiWeb has terminated the SSL/TLS connection and the second segment of the request, where it forwards to the back-end servers, is clear text HTTP. In some cases, your back-end server may need to know that the original request was, in fact, encrypted HTTPS, not HTTP.

disable

<entry_index>

Enter the index number of the individual entry in the table.

The valid range is 1–9,223,372,036,854,775,807.

Each list can contain a maximum of 256 IP addresses.

No default.

ip "<load-balancer_ip>"

Type the IP address of a load balancer or proxy that is in front of the FortiWeb appliance (between the client and FortiWeb).

To apply anti-spoofing measures and improve security, FortiWeb trusts the contents of the HTTP header that you specify in original-ip-header "<HTTP-header-key_str>" only if the packet arrived from one of the IP addresses you specify here. It regards original-ip-header "<HTTP-header-key_str>" from other IP addresses as potentially spoofed.

For packets from other IP addresses, FortiWeb ignores the X-Forwarded-For: header and uses the source IP address in the IP header as the client source address. This IP address is displayed in the attack log message.

No default.

add-source-port {enable | disable}

Enable to add an X-Forwarded-For: header with the connection's source IP. If this field is enabled, the source port of the request will be added as well.

Available only when FortiWeb operates in Reverse Proxy, True Transparent Proxy, or WCCP mode.

disable

x-forwarded-port {enable | disable}

Enable to add an X-Forwarded-Port: header with the connection's destination port.

Available only when FortiWeb operates in Reverse Proxy, True Transparent Proxy, or WCCP mode.

disable

Example

The following example defines a X-Forwarded-For rule that adds X-Forwarded-For:, X-Real-IP:, and X-Forwarded-Proto: headers to traffic that FortiWeb forwards to a back-end server. It enables FortiWeb to use the HTTP X-Header to identify and block the original client's IP. To protect against XFF spoofing, it also specifies the trusted load-balancer 192.0.2.105 in the X-Forwarded-For IP list.

config waf x-forwarded-for

edit "load-balancer1"

set x-forwarded-for-support enable

set tracing-original-ip enable

set original-ip-header X-FORWARDED-FOR

set x-real-ip enable

set x-forwarded-proto enable

config ip-list

edit 1

set ip "192.0.2.105"

next

end

set block-based-on-original-ip enable

next

end