Fortigate Load Balancing 2m2v2v

[email protected]

Where can be: l

clear erase the current filter

l

dst the destination address range to filter by

l

dst-port the destination port range to filter by

l

list display the current filter

l

name the vip name to filter by

l

negate negate the specified filter parameter

l

src the source address range to filter by

l

src-port the source port range to filter by

l

vd index of virtual domain. -1 matches all

The default filter is empty so no filtering is done.

Logging Diagnostics The logging diagnostics provide information about two separate features: diagnose firewall vip virtual-server log {console | filter}

Where l

l l

console {disable | enable} enables or disables displaying the event log messages generated by virtual server traffic on the console to simplify debugging. filter sets a filter for the virtual server debug log The filter option controls what entries the virtual server daemon will log to the console if diagnose debug application vs level is non-zero. The filtering can be done on source, destination, virtual-server name, virtual domain, and so on: diagnose firewall vip virtual-server log filter

Where can be l

clear erase the current filter

l

dst the destination address range to filter by

l

dst-port the destination port range to filter by

l

list display the current filter

l

name the virtual-server name to filter by

l

negate negate the specified filter parameter

l

src the source address range to filter by

l

src-port the source port range to filter by

l

vd index of virtual domain. -1 matches all

The default filter is empty so no filtering is done.

Real server diagnostics Enter the following command to list all the real servers: diag firewall vip virtual-server real-server list

Server Load Balancing for FortiOS 5.6 Fortinet Technologies Inc.

29

Load balancing diagnose commands

Configuring load balancing

In the following example there is only one virtual server called slb and it has two real-servers: diag firewall vip virtual-server server vd root/0 vs slb/2 addr 172.16.67.191:80 status 1/1 conn: max 10 active 0 attempts 0 success 0 drop 0 fail 0 http: available 0 total 0 vd root/0 vs slb/2 addr 172.16.67.192:80 status 1/1 conn: max 10 active 1 attempts 4 success 4 drop 0 fail 0 http: available 1 total 1

The status indicates the istrative and operational status of the real-server. l l

l l

max indicates that the real-server will only allow 10 concurrent connections. active is the number of current connections to the server attempts is the total number of connections attempted success is the total number of connections that were successful. drop is the total number of connections that were dropped because the active count hit max. fail is the total number of connections that failed to complete due to some internal problem (for example, lack of memory).

If the virtual server has HTTP multiplexing enabled then the HTTP section indicates how many established connections to the real-sever are available to service a HTTP request and also the total number of connections.

30


HTTP and HTTPS load balancing, multiplexing, and persistence

HTTP and HTTPS multiplexing

HTTP and HTTPS load balancing, multiplexing, and persistence In a firewall load balancing virtual server configuration, you can select HTTP to load balance only HTTP sessions. The virtual server will load balance HTTP sessions received at the virtual server interface with destination IP address that matches the configured virtual server IP and destination port number that matches the configured virtual server port. The default virtual server port for HTTP load balancing is 80, but you can change this to any port number. Similarly for HTTPS load balancing, set the virtual server type to HTTPS and then select the interface, virtual server IP, and virtual server port that matches the HTTPS traffic to be load balanced. Usually HTTPS traffic uses port 443. You can also configure load balancing to offload SSL processing for HTTPS and SSL traffic. See SSL/TLS load balancing on page 36.

HTTP and HTTPS multiplexing For both HTTP and HTTPS load balancing you can multiplex HTTP requests and responses over a single T connection. HTTP multiplexing is a performance saving feature of HTTP/1.1 compliant web servers that provides the ability to pipeline many unrelated HTTP or HTTPS requests on the same connection. This allows a single HTTPD process on the server to interleave and serve multiple requests. The result is fewer idle sessions on the web server so server resources are used more efficiently. HTTP multiplexing can take multiple separate inbound sessions and multiplex them over the same internal session. This may reduce the load on the backend server and increase the overall performance. HTTP multiplexing may improve performance in some cases. For example, if s web browsers are only compatible with HTTP 1.0. HTTP multiplexing can also improve performance between a web server and the FortiGate unit if the FortiGate unit is performing SSL acceleration. However, in most cases HTTP multiplexing should only be used if enabling it leads to a measurable improvement in performance. To enable HTTP multiplexing from the web-based manager, select multiplex HTTP requests/responses over a single T connection. To enable HTTP multiplexing from the CLI enable the http-multiplex option.

Preserving the client IP address Select preserve client IP from the GUI or enable the http-ip-header option from the CLI to preserve the IP address of the client in the X-Forwarded-For HTTP header. This can be useful in an HTTP multiplexing configuration if you want to be able to see the original client IP address in log messages on the destination web server. If this option is not selected, the X-Forwarded-For HTTP header contains the IP address of the FortiGate unit.

Preserving the client IP address in a different HTTP header If you select preserve client IP from the web-based manager or enable the http-ip-header option from the CLI you can also preserve the client IP in a different HTTP header. This can be useful if you want to use a custom header name instead of X-Forwarded-For.


31

HTTP and HTTPS persistence


You can add the custom header name from the CLI. When http-ip-header is enabled you can add a custom header name to the http-ip-header-name option. If you don’t add a name the X-Forwarded-For header is used.

HTTP and HTTPS persistence Configure load balancing persistence for HTTP or HTTPS to make sure that a is connected to the same server every time they make a request that is part of the same session. HTTP cookie persistence uses injected cookies to enable persistence. When you configure persistence, the FortiGate unit load balances a new session to a real server according to the Load Balance Method. If the session has an HTTP cookie or an SSL session ID, the FortiGate unit sends all subsequent sessions with the same HTTP cookie or SSL session ID to the same real server. The following example shows how to enable cookie persistence and set the cookie domain to .example.org. config firewall vip edit HTTP_Load_Balance set type server-load-balance set server-type http set extport 8080 set extintf port2 set extip 192.168.20.20 set persistence http-cookie set http-cookie-domain .example.org config realservers edit 1 set ip 10.10.10.1 set port 80 next edit 2 set ip 10.10.10.2 set port 80 next edit 3 set ip 10.10.10.3 set port 80 end

How HTTP cookie persistence options work The following options are available for the config firewall vip command when type is set to serverload-balance, server-type is set to http or https and persistence is set to http-cookie: http-cookie-domain-from-host http-cookie-domain http-cookie-path http-cookie-generation http-cookie-age http-cookie-share https-cookie-share

When HTTP cookie persistence is enabled the FortiGate unit inserts a header of the following form into each HTTP response unless the corresponding HTTP request already contains a FGTServer cookie: Set-Cookie: FGTServer=E7D01637C4B08E89A6714213A9D85D9C7E4D8158; Version=1; Max-Age=3600

32



HTTP and HTTPS persistence

The value of the FGTServer cookie encodes the server that traffic should be directed to. The value is encoded so as to not leak information about the internal network. Enable http-cookie-domain-from-host to extract the cookie domain from the host: header in the HTTP request. For example, to restrict the cookie to.server.com, enter: The generated cookies could have the following form if the Host: header contains exhost.com: Set-Cookie: FGTServer=E7D01637C4B08E89A6714213A9D85D9C7E4D8158; Version=1; Domain=.exhost.com; Max-Age=3600

For more information, see “HTTP host-based load balancing”. Use http-cookie-domain to restrict the domain that the cookie should apply to. For example, to restrict the cookie to.server.com, enter: set http-cookie-domain .server.com

Now all generated cookies will have the following form: Set-Cookie: FGTServer=E7D01637C4B08E89A6714213A9D85D9C7E4D8158; Version=1; Domain=.server.com; Max-Age=3600

Use http-cookie-path to limit the cookies to a particular path. For example, to limit cookies to the path /sales, enter: set http-cookie-path /sales

Now all generated cookies will have the following form: Set-Cookie: FGTServer=E7D01637C4B08E89A6714213A9D85D9C7E4D8158; Version=1; Domain=.server.com; Path=/sales; Max-Age=3600

Use http-cookie-age to change how long the browser caches the cookie. You can enter an age in minutes or set the age to 0 to make the browser keep the cookie indefinitely: set http-cookie-age 0

Now all generated cookies will have the following form: Set-Cookie: FGTServer=E7D01637C4B08E89A6714213A9D85D9C7E4D8158; Version=1; Domain=.server.com; Path=/sales

Use http-cookie-generation to invalidate all cookies that have already been generated. The exact value of the generation is not important, only that it is different from any generation that has already been used for cookies in this domain. The simplest approach is to increment the generation by one each time invalidation is required. Since the default is 0, enter the following to invalidate all existing cookies: set http-cookie-generation 1

Use http-cookie-share {disable | same-ip} to control the sharing of cookies across virtual servers in the same virtual domain. The default setting same-ip means that any FGTServer cookie generated by one virtual server can be used by another virtual server in the same virtual domain. For example, if you have an application that starts on HTTP and then changes to HTTPS and you want to make sure that the same server is used for the HTTP and HTTPS traffic then you can create two virtual servers, one for port 80 (for HTTP) and one for port 443 (for HTTPS). As long as you add the same real servers to both of these virtual servers (and as long as both virtual servers have the same number of real servers with the same IP addresses), then cookies generated by accessing the HTTP server are reused when the application changes to the HTTPS server. If for any reason you do not want this sharing to occur then select disable to make sure that a cookie generated for a virtual server cannot be used by other virtual servers. Use https-cookie-secure to enable or disable using secure cookies. Secure cookies are disabled by default because secure cookies can interfere with cookie sharing across HTTP and HTTPS virtual servers. If enabled, then the Secure tag is added to the cookie inserted by the FortiGate unit:


33

HTTP host-based load balancing


Set-Cookie: FGTServer=E7D01637C4B08E89A6714213A9D85D9C7E4D8158; Version=1; Max-Age=3600; Secure

HTTP host-based load balancing When configuring HTTP or HTTPS load balancing you can select HTTP host load balancing to load balance HTTP host connections across multiple real servers using the host’s HTTP header to guide the connection to the correct real server. HTTP 1.1 includes the concept of a virtual server which allows a HTTP or HTTPS server with a single external IP address to serve requests for multiple DNS domains by using the mandatory Host: header in a HTTP request to indicate which DNS domain the request is destined for. FortiOS can load-balance HTTP and HTTPS connections among multiple real servers using the Host: header to guide the connection to the correct real server. The host load balancing method allows a real server to specify a http-host attribute which is the domain name of the traffic for that real server. Each real server can only specify a single domain name. The same domain name can appear in more than one real server but only the first one that is up will be used, any others are purely for redundancy. If the Host: header contains a domain that does not match any http-host entry then the connection will be dropped. A real server with no http-host can be matched by any Host: domain. For example, consider a FortiGate unit that is load-balancing traffic to three real servers. Traffic for www.example1.com should go to 192.168.2.1, traffic for www.example2.com should go to 192.168.2.2 and traffic to any other domain should go to 192.168.2.3. To enable this configuration you would add a virtual server and set the load balance method to HTTP host. Then you would add three real servers and set the HTTP host of the real server with IP address 192.168.2.1 to www.example1.com, the HTTP host of the real server with IP address 192.168.2.2 to www.example2.com and you would not specify an HTTP host for the third real server. The configuration of a virtual IP to achieve this result would be: config firewall vip edit "http-host-ldb" set type server-load-balance set extip 172.16.67.195 set extintf "lan" set server-type http set ldb-method http-host set extport 80 config realservers edit 1 set http-host "www.example1.com" set ip 192.168.2.1 set port 80 next edit 2 set http-host "www.example2.com" set ip 192.168.2.2 set port 80 next edit 3 set ip 192.168.2.3 set port 80 next end end

34



HTTP host-based load balancing

Host load balancing and HTTP cookie persistence In an HTTP host-based load balancing configuration with HTTP cookie persistence enabled you can optionally configure cookie persistence to use the domain set in the host header as the cookie domain. You can do this by enabling the http-cookie-domain-from-host option, for example: config firewall vip edit "http-host-ldb" set type server-load-balance set extip 172.16.67.195 set extintf "lan" set server-type http set ldb-method http-host set extport 80 set persistence http-cookie set http-cookie-domain-from-host enable config realservers edit 1 set http-host "www.example1.com" set ip 192.168.2.1 set port 80 next edit 2 set http-host "www.example2.com" set ip 192.168.2.2 set port 80 next edit 3 set ip 192.168.2.3 set port 80 next end end


35

SSL/TLS offloading

SSL/TLS load balancing

SSL/TLS load balancing In a firewall load balancing virtual server configuration, you can select SSL to load balance only SSL and TLS sessions. The virtual server will load balance SSL and TLS sessions received at the virtual server interface with destination IP address that matches the configured virtual server IP and destination port number that matches the configured virtual server port. Change this port to match the destination port of the sessions to be load balanced. For SSL load balancing you can also set persistence to SSL session ID. Persistence is achieved by the FortiGate unit sending all sessions with the same SSL session ID to the same real server. When you configure persistence, the FortiGate unit load balances a new session to a real server according to the Load Balance Method. If the session has an SSL session ID, the FortiGate unit sends all subsequent sessions with the same SSL session ID to the same real server.

SSL/TLS offloading Use SSL offloading to accelerate clients’ SSL or HTTPS connections to real servers by using the FortiGate unit to perform SSL/TLS operations (offloading them from the real servers using the FortiGate unit’s SSL acceleration hardware). FortiGate units can offload most versions of SSL/TLS, including SSL 3.0, TLS 1.0 and TLS 1.2. SSL/TLS offloading is available on FortiGate units that SSL acceleration. To configure SSL offloading from the web-based manager go to Policy & Objects > Virtual Servers. Add a virtual server and set the type to HTTPS or SSL and select the SSL offloading type (Client <-> FortiGate or Client <-> FortiGate <-> Server). Select Client <-> FortiGate to apply hardware accelerated SSL/TLS processing only to the part of the connection between the client and the FortiGate unit. This mode is called half mode SSL offloading. The segment between the FortiGate unit and the server will use clear text communications. This results in best performance, but cannot be used in failover configurations where the failover path does not have an SSL accelerator. Select Client <-> FortiGate <->Server to apply hardware accelerated SSL processing to both parts of the connection: the segment between client and the FortiGate unit, and the segment between the FortiGate unit and the server. This mode is called full mode SSL offloading. The segment between the FortiGate unit and the server will use encrypted communications, but the handshakes will be abbreviated. This is not as efficient as half mode SSL offloading, but still improves performance. As well full-mode SSL offloading can be used in failover configurations where the failover path does not have an SSL accelerator. If the server is already configured to use SSL, this also enables SSL acceleration without requiring changes to the server’s configuration.

36



SSL/TLS offloading

SSL Offloading modes (Half Mode and Full Mode)

Configuring SSL offloading also requires selecting a certificate to use for the SSL offloading sessions. SSL offloading s key sizes up to 4096. FortiGate models with 9 processors 3072 and 4096 DH bit sizes in hardware. All FortiGate models up to and including those with 8 processors only offloading DH bit sizes up to 2048 so any sizes larger than that are done in software and thus are relatively resource intensive The following CLI command shows an example half mode HTTPS SSL offloading configuration. In the example the ssl-mode option sets the SSL offload mode to half (which is the default mode). config firewall vip edit Vserver-ssl-offload set type server-load-balance set server-type https set ldb-method round-robin set extip 172.20.120.30 set extintf wan1 set extport 443


37

Separate virtual-server client and server TLS version and cipher configuration


set persistence ssl-session-id set ssl-mode half set ssl-certificate my-cert set monitor t-mon-1 config realservers edit 1 set ip 10.31.101.30 set port 443 next edit 2 set ip 10.31.101.40 set port 443 end end

Separate virtual-server client and server TLS version and cipher configuration In previous versions of FortiOS you can configure minimum and maximum SSL/TLS versions that a virtual server will accept. Those versions primarily applied to the client to FortiGate connection; but, they are also applied to the FortiGate to server connection. In some cases you may want the to use different versions of SSL or TLS on the client to FortiGate connection than on the FortiGate to server connection. For example, you may want to use the FortiGate to protect a legacy SSL 3.0 or TLS 1.0 server while making sure that client to FortiGate connections must always use the higher level of protection offered by TLS 1.1 or greater. Similarly in previous versions of FortiOS you could control the cypher suites that can be used by the FortiGate to negotiate with the client and with the server. But you could only configure the same configuration for both client and server connections. Also, in some cases you might want to protect a server that only has weak ciphers (for example, DES or RC4) while making sure that all connections between the FortiGate and the client use a strong cipher for better protection. The following new options are available when configuring server load balancing for HTTPS sessions configured with the following command: config firewall vip edit server-name set type server-load-balance set server-type https set ssl-mode full ...

Setting the SSL/TLS versions to use for server and client connections The ssl-server-min-version, ssl-server-max-version, ssl-min-version and ssl-maxversion configuration options allow the minimum and maximum SSL/TLS versions for the client to FortiGate connection to be independent of the FortiGate to server configuration. By default these options are both set to client and the configured ssl-min-version and ssl-max-version settings are applied to both the client and the server connection. You can change the ssl-server-min-version and ssl-server-max-version to apply different options to the server connection. The ssl-min-version and ssl-max-version settings are still applied to

38



Setting the SSL/TLS cipher choices for server and client connections

the client connection. If you set the ssl-server-min-version and ssl-server-max-version to an explicit version then both must be set to an explicit version. The ssl-server-min-version and ssl-server-max-version options allow you to specify the minimum and maximum SSL/TLS versions the FortiGate will offer to the server (in the record header of the ClientHello) when performing full mode SSL offloading and thus the minimum and maximum SSL/TLS versions the FortiGate accepts from the server (in a ServerHello). If the server responds with a version in its ServerHello that is lower than ssl-server-min-version or higher than the ssl-server-max-version then the FortiGate terminates the connection. Command syntax is: config firewall vip edit server-name set type server-load-balance set server-type https set ssl-mode full set ssl-min-version {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2} set ssl-max-version {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2} set ssl-server-min-version {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2 | client} set ssl-server-max-version {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2 | client}

Setting the SSL/TLS cipher choices for server and client connections The ssl-algorithm and ssl-server-algorithm configuration options allow the cipher choice for the FortiGate to server connection to be independent of the client to FortiGate connection. By default, sslserver-algorithm is set to client and the configured ssl-algorithm setting is applied to both the client and the server connection. You can change the ssl-server-algorithm to apply different options to the server connection. The sslalgorithm setting is still applied to the client connection. The following ssl-server-algorithm options are available: l

high, offer AES or 3DES cypher suites in the ServerHello

l

medium, use AES, 3DES, or RC4 cypher suites in the ServerHello

l

low, use AES, 3DES, RC4, or DES cypher suites in the ServerHello

l

l

custom, specifiy custom cypher suites using the config ssl-server-cipher-suites and offer these custom cypher suites in the ServerHello. client, offer the cypher suites in the ServerHello that are offered in the ClientHello.

Command syntax is: config firewall vip edit server-name set type server-load-balance set server-type https set ssl-mode full set ssl-algorithm {high | medium | low | custom} set ssl-server-algorithm {high | medium | low | custom | client}

If you set ssl-server-algorithm to custom, the syntax is: config firewall vip edit server-name set type server-load-balance


39

Protection from TLS protocol downgrade attacks


set server-type https set ssl-mode full set ssl-server-algorithm custom config ssl-server-cipher-suites edit 10 set cipher set versions {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2} next edit 20 set cipher set versions {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2} end

Protection from TLS protocol downgrade attacks The ssl-client-fallback option, when enabled (the default configuration), performs downgrade attack prevention (RFC 7507). Command syntax is: config firewall vip edit server-name set type server-load-balance set server-type https set ssl-client-fallback {disable | enable}

Setting 3072- and 4096-bit Diffie-Hellman values The ssl-dh-bits option allows you to specify the number of bits of the prime number used in the DiffieHellman exchange for RSA encryption of the SSL connection. Larger prime numbers are associated with greater cryptographic strength. You can set DH values from 768 to 4096 bits. Command syntax is: config firewall vip edit server-name set type server-load-balance set server-type https set ssl-dh-bits {768 | 1024 | 1536 | 2048 | 3072 | 4096}

Setting the DH bits to 2048 only provides the equivalent of a symmetric cipher in the range of 112 - 128 bits. This means that if AES 256 is used then the weakest point is the DH of 2048 and a value of at least 3072 should be use if the goal is to have 256 bits of security. FortiGate models with 9 processors 3072 and 4096 DH bit sizes in hardware. All FortiGate models up to and including those with 8 processors only offloading DH bit sizes up to 2048 so any sizes larger than that are done in software and thus are relatively resource intensive.

40



Additional SSL load balancing and SSL offloading options

Additional SSL load balancing and SSL offloading options The following SSL load balancing and SSL offloading options are only available from the CLI: ssl-client-session-state-max <sessionstates_int>

Enter the maximum number of SSL session states to keep for the segment of the SSL connection between the client and the FortiGate unit. ssl-client-session-state-timeout

Enter the number of minutes to keep the SSL session states for the segment of the SSL connection between the client and the FortiGate unit. ssl-client-session-state-type {both | client | disable | time}

Select which method the FortiGate unit should use when deciding to expire SSL sessions for the segment of the SSL connection between the client and the FortiGate unit. l

both: Select to expire SSL session states when either ssl-client-session-state-max or ssl-clientsession-state-timeout is exceeded, regardless of which occurs first.

l

count: Select to expire SSL session states when ssl-client-session-state-max is exceeded.

l

disable: Select to keep no SSL session states.

l

time: Select to expire SSL session states when ssl-client-session-state-timeout is exceeded. ssl-http-location-conversion {enable | disable}

Select to replace http with https in the reply’s Location HTTP header field. For example, in the reply, Location: http://example.com/ would be converted to Location: https://example.com/ ssl-http-match-host {enable | disable}

Select to apply Location conversion to the reply’s HTTP header only if the host name portion of Location matches the request’s Host field, or, if the Host field does not exist, the host name portion of the request’s URI. If disabled, conversion occurs regardless of whether the host names in the request and the reply match. For example, if host matching is enabled, and a request contains Host: example.com and the reply contains Location: http://example.cc/, the Location field does not match the host of the original request and the reply’s Location field remains unchanged. If the reply contains Location: http://example.com/, however, then the FortiGate unit detects the matching host name and converts the reply field to Location: https://example.com/. This option appears only if ssl-http-location-conversion is enable. ssl-send-empty-frags {enable | disable}

Select to precede the record with empty fragments to protect from attacks on CBC IV. You might disable this option if SSL acceleration will be used with an old or buggy SSL implementation which cannot properly handle empty fragments. ssl-server-session-state-max <sessionstates_int>

Enter the maximum number of SSL session states to keep for the segment of the SSL connection between the server and the FortiGate unit. ssl-server-session-state-timeout

Enter the number of minutes to keep the SSL session states for the segment of the SSL connection between the server and the FortiGate unit. This option appears only if ssl-mode is full. ssl-server-session-state-type {both | count | disable | time}


41

SSL offloading for Internet Explorer 6


Select which method the FortiGate unit should use when deciding to expire SSL sessions for the segment of the SSL connection between the server and the FortiGate unit. This option appears only if ssl-mode is full. l

both: Select to expire SSL session states when either ssl-server-session-state-max or ssl-serversession-state-timeout is exceeded, regardless of which occurs first.

l

count: Select to expire SSL session states when ssl-server-session-state-max is exceeded.

l

disable: Select to keep no SSL session states.

l

time: Select to expire SSL session states when ssl-server-session-state-timeout is exceeded.

SSL offloading for Internet Explorer 6 In some cases the Internet Explorer 6 web browser may be able to access real servers. To resolve this issue, disable the ssl-send-empty-frags option: config firewall vip edit vip_name set ssl-send-empty-frags disable end

You can disable this option if SSL acceleration will be used with an old or buggy SSL implementation that cannot properly handle empty fragments.

Selecting the cipher suites available for SSL load balancing You can use the following command to view the complete list of cipher suites available for SSL offloading: config firewall vip edit set type server-load-balance set server-type https set ssl-algorithm custom config ssl-cipher-suites edit 0 set cipher ?

In most configurations the matching cipher suite is automatically selected but you can limit the set of cipher suites that are available for a given SSL offloading configuration. For example, use the following command to limit an SSL load balancing configuration to use the three cipher suites that ChaCha20 and Poly1305: config firewall vip edit set type server-load-balance set server-type https set ssl-algorithm custom config ssl-cipher-suites edit 1 set cipher TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256 next edit 2 set cipher TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256 next edit 3 set cipher TLS-DHE-RSA-WITH-CHACHA20-POLY1305-SHA256

42



Disabling SSL/TLS re-negotiation

end end

Disabling SSL/TLS re-negotiation The vulnerability CVE-2009-3555 affects all SSL/TLS servers that re-negotiation. FortiOS when configured for SSL/TLS offloading is operating as a SSL/TLS server. The IETF is working on a TLS protocol change that will fix the problem identified by CVE-2009-3555 while still ing re-negotiation. Until that protocol change is available, you can use the ssl-client-renegotiation option to disable for SSL/TLS re-negotiation. The default value of this option is allow, which allows an SSL client to renegotiate. You can change the setting to deny to abort any attempts by an SSL client to renegotiate. If you select deny as soon as a ClientHello message indicating a re-negotiation is received from the client FortiOS terminates the T connection. Since SSL offloading does not requesting client certificates the only circumstance in which a renegotiation is required is when more than 2^32 bytes of data are exchanged over a single handshake. If you are sure that this volume of traffic will not occur then you can disable re-negotiation and avoid any possibility of the attack described in CVE-2009-3555. The re-negotiation behavior can be tested using OpenSSL. The OpenSSL s_client application has the feature that the can request that it do renegotiation by typing “R”. For example, the following shows a successful renegotiation against a FortiGate unit configured with a VIP for 192.168.2.100:443: $ openssl s_client -connect 192.168.2.100:443 CONNECTED(00000003) depth=1 /C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=/ [email protected] error:num=19:self signed certificate in certificate chain return:0 --Certificate chain 0 s:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Fortigate/CN=FW80CM3909604325/emailAdd [email protected] i:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=/ [email protected] 1 s:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=/ [email protected] i:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=/ [email protected] --Server certificate -----BEGIN CERTIFICATE-------certificate not shown-------END CERTIFICATE----subject=/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Fortigate/CN=FW80CM3909604325/em [email protected] issuer=/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=/ [email protected] --No client certificate CA names sent


43



--SSL handshake has read 2370 bytes and written 316 bytes --New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 02781E1E368DCCE97A95396FAA82E8F740F5BBA96CF022F6FEC3597B0CC88095 Session-ID-ctx: Master-Key: A6BBBD8477A2422D56E57C1792A4EA9C86F37D731E67D0A66E5CDB2B5C76650780C0E7F01CFF851EC44661 86F4C48397 Key-Arg : None Start Time: 1264453027 Timeout : 300 (sec) return code: 19 (self signed certificate in certificate chain) --GET /main.c HTTP/1.0 R RENEGOTIATING depth=1 /C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=/ [email protected] error:num=19:self signed certificate in certificate chain return:0 HTTP/1.0 200 ok Content-type: text/plain /* * Copyright (C) 2004-2007 Fortinet */ #include <stdio.h> #include "vsd_ui.h" int main(int argc, char **argv) { return vsd_ui_main(argc, argv); } closed $

The following is the same test, but this time with the VIP configuration changed to ssl-clientrenegotation deny: $ openssl s_client -connect 192.168.2.100:443 CONNECTED(00000003) depth=1 /C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=/ [email protected] error:num=19:self signed certificate in certificate chain return:0 --Certificate chain

44




0 s:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Fortigate/CN=FW80CM3909604325/emailAdd [email protected] i:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=/ [email protected] 1 s:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=/ [email protected] i:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=/ [email protected] --Server certificate -----BEGIN CERTIFICATE-------certificate not shown-------END CERTIFICATE----subject=/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Fortigate/CN=FW80CM3909604325/em [email protected] issuer=/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=/ [email protected] --No client certificate CA names sent --SSL handshake has read 2370 bytes and written 316 bytes --New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 8253331D266DDE38E4D8A04AFCA9CBDED5B1134932CE1718EED6469C1FBC7474 Session-ID-ctx: Master-Key: ED05A3EF168AF2D06A486362FE91F1D6CAA55CEFC38A3C36FB8BD74236BF2657D4701B6C1456CEB5BB5EFA A7619EF12D Key-Arg : None Start Time: 1264452957 Timeout : 300 (sec) return code: 19 (self signed certificate in certificate chain) --GET /main.c HTTP/1.0 R RENEGOTIATING 19916:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530:

Use the following command to check the SSL stats to see that the renegotiations blocked counter is now 1: diagnose firewall vip virtual-server stats ssl ssl client connections total 0 active 0 max 0 handshakes total 4 active 0 max 0 completed 4 abbreviated 0 session states total 4 active 4 max 4


45



cipher-suite failures 0 embryonics total 0 active 0 max 0 terminated 0 renegotiations blocked 1 server connections total 0 active 0 max 0 handshakes total 3 active 0 max 0 completed 2 abbreviated 1 session states total 1 active 1 max 1 cipher-suite failures 0 internal error 0 bad handshake length 0 bad change cipher spec length 0 pubkey too big 0 persistence find 0 found 0 clash 0 addr 0 error 0

If the virtual server debug log is examined (diagnose debug appl vs -1) then at the point the re-negotiation is blocked there is a log: vs ssl 12 handshake recv ClientHello vs ssl 12 handshake recv 1 (0100005403014b5e056c7f573a563bebe0258c3254bbaff7046a461164f34f94f4f3d019c418000026 00390038003500160013000a00330032002f00050004001500120009001400110008000600030201000 00400230000) vs ssl 12 client renegotiation attempted rejected, abort vs ssl 12 closing 0 up vs src 12 close 0 in vs src 12 error closing vs dst 14 error closing vs dst 14 closed vs ssl 14 close vs sock 14 free vs src 12 closed vs ssl 12 close vs sock 12 free

46


IP, T, and UDP load balancing


IP, T, and UDP load balancing You can load balance all IP, T or UDP sessions accepted by the security policy that includes a load balancing virtual server with the type set to IP, T, or UDP. Traffic with destination IP and port that matches the virtual server IP and port is load balanced. For these protocol-level load balancing virtual servers you can select a load balance method and add real servers and health checking. However, you can’t configure persistence, HTTP multiplexing and SSL offloading.


47

Web-based manager configuration

Example HTTP load balancing to three real web servers

Example HTTP load balancing to three real web servers In this example, a virtual web server with IP address 192.168.37.4 on the Internet, is mapped to three real web servers connected to the FortiGate unit dmz1 interface. The real servers have IP addresses 10.10.123.42, 10.10.123.43, and 10.10.123.44. The virtual server uses the First Alive load balancing method. The configuration also includes an HTTP health check monitor that includes a URL used by the FortiGate unit for get requests to monitor the health of the real servers. Connections to the virtual web server at IP address 192.168.37.4 from the Internet are translated and load balanced to the real servers by the FortiGate unit. First alive load balancing directs all sessions to the first real server. The computers on the Internet are unaware of this translation and load balancing and see a single virtual server at IP address 192.168.37.4 rather than the three real servers behind the FortiGate unit.

Virtual server configuration example

.[4

2-4

4]

IP er 2 rv .4 se 01 P 1.1 TT .3 H 10

IP er 3 rv .4 se 01 P 1.1 TT .3 H 10

IP er 4 rv .4 se 01 P 1.1 TT .3 H 10

So u De rce I stin P 1 atio 0.1 n I 0.1 P 1 0.2 0.1 0.1 0

3 1 HT

TP l virt oad b ua ala l se nc rve ing r

R

ea

l

S

er

ve

rs

2

3 .1

Z1 M 2 D 10. 0.

10

2

P rI ve er .4 l S 37 ua 8. irt 6 V 2.1 19

FortiGate unit

1

So u De rce I stin P 1 atio 72. n I 199 P 1 .19 92 0.2 .16 5 8.3 7.4

17 2. IP nt 5 lie .2 C 90 1 9.

19

Web-based manager configuration Use the following procedures to configure this load balancing setup from the web-based manager.

48




To add an HTTP health check monitor In this example, the HTTP health check monitor includes the URL “/index.html” and the Matched Phrase “Fortinet products”. 1. Go to Policy & Objects > Health Check. 2. Select Create New. 3. Add an HTTP health check monitor that sends get requests to http:// /index.html and searches the returned web page for the phrase “Fortinet products”. Name

HTTP_health_chk_1

Type

HTTP

Port

80

URL

/index.html

Matched Content

Fortinet products

Interval

10 seconds

Timeout

2 seconds

Retry

3

4. Select OK.

To add the HTTP virtual server 1. Go to Policy & Objects > Virtual Servers. 2. Select Create New. 3. Add an HTTP virtual server that allows s on the Internet to connect to the real servers on the internal network. In this example, the FortiGate wan1 interface is connected to the Internet. Name

Load_Bal_VS1

Type

HTTP

Outoging Interface

wan1

Virtual Server IP

192.168.37.4 The public IP address of the web server. The virtual server IP address is usually a static IP address obtained from your ISP for your web server. This address must be a unique IP address that is not used by another host and cannot be the same as the IP address of the external interface the virtual IP will be using. However, the external IP address must be routed to the selected interface. The virtual IP address and the external IP address can be on different subnets. When you add the virtual IP, the external interface responds to ARP requests for the external IP address.

Virtual Server Port


80

49



Load Balance Method

First Alive

Persistence

HTTP cookie

Health Check

HTTP_health_chk_1

HTTP Multiplexing

Turn on. The FortiGate unit multiplexes multiple client into a few connections between the FortiGate unit and each real HTTP server. This can improve performance by reducing server overhead associated with establishing multiple connections.

Preserve Client IP

Turn on. The FortiGate unit preserves the IP address of the client in the XForwarded-For HTTP header.

4. Select OK.

To add the real servers and associate them with the virtual server 1. Go to Policy & Objects > Real Servers. 2. Select Create New. 3. Configure three real servers that include the virtual server Load_Bal_VS1. Each real server must include the IP address of a real server on the internal network. Configuration for the first real server. Virtual Server

Load_Bal_VS1

IP Address

10.10.10.42

Port

80

Weight

Cannot be configured because the virtual server does not include weighted load balancing.

Max Connections

0 Setting Max Connections to 0 means the FortiGate unit does not limit the number of connections to the real server. Since the virtual server uses First Alive load balancing you may want to limit the number of connections to each real server to limit the traffic received by each server. In this example, the Max Connections is initially set to 0 but can be adjusted later if the real servers are getting too much traffic.

Configuration for the second real server.

50

Virtual Server

Load_Bal_VS1

IP Address

10.10.10.43

Port

80




Weight


Max Connections


Configuration for the third real server. Virtual Server

Load_Bal_VS1

IP Address

10.10.10.44

Port

80

Weight


Max Connections


To add the virtual server to a security policy Add a wan1 to dmz1 security policy that uses the virtual server so that when s on the Internet attempt to connect to the web server’s IP address, packets through the FortiGate unit from the wan1 interface to the dmz1 interface. The virtual IP translates the destination address of these packets from the virtual server IP address to the real server IP addresses. 1. Go to Policy & Objects > IPv4 Policy. 2. Select Create New. 3. Configure the security policy: Name

Add a name for the policy.

Incoming Interface

wan1

Outgoing Interface

dmz1

Source

all (or a more specific address)

Destination

Load_Bal_VS1


51

CLI configuration


Schedule

always

Service

HTTP

Action

ACCEPT

NAT

Select this option and select Use Destination Interface Address.

Log Allowed Traffic

Select to log virtual server traffic

4. Select other security policy options as required. 5. Select OK.

CLI configuration Use the following procedure to configure this load balancing setup from the CLI.

To configure HTTP load balancing 1. Use the following command to add an HTTP health check monitor that sends get requests to http:// /index.html and searches the returned web page for the phrase “Fortinet products”. config firewall ldb-monitor edit HTTP_health_chk_1 set type http set port 80 set http-get /index.html set http-match “Fortinet products” set interval 10 set timeout 2 set retry 3 end

2. Use the following command to add an HTTP virtual server that allows s on the Internet to connect to the real servers on the internal network. In this example, the FortiGate wan1 interface is connected to the Internet. config firewall vip edit Load-Bal_VS1 set type server-load-balance set server-type http set ldb-method first-alive set http-multiplex enable set http-ip-header enable set extip 192.168.37.4 set extintf wan1 set extport 80 set persistence http-cookie set monitor HTTP_health_chk_1 config realservers edit 1 set ip 10.10.10.42 set port 80 next edit 2 set ip 10.10.10.43

52



CLI configuration

set port 80 next edit 3 set ip 10.10.10.44 set port 80 end end

3. Use the following command to add a security policy that includes the load balance virtual server as the destination address. config firewall policy edit 0 set name <policy-name> set srcintf wan1 set srcaddr all set dstintf dmz1 set dstaddr Load-Bal_VS1 set action accept set schedule always set service ALL set nat enable end

Configure other security policy settings as required.


53

CLI configuration

Example Basic IP load balancing configuration

Example Basic IP load balancing configuration This example shows how to add a server load balancing virtual IP that load balances all traffic among 3 real servers. In the example the Internet is connected to port2 and the virtual IP address of the virtual server is 192.168.20.20. The load balancing method is weighted. The IP addresses of the real servers are 10.10.10.1, 10.10.10.2, and 10.10.10.3. The weights for the real servers are 1, 2, and 3. The default weight is 1 and does not have to be changed for the first real server. config firewall vip edit All_Load_Balance set type server-load-balance set server-type ip set extintf port2 set extip 192.168.20.20 set ldb-method weighted config realservers edit 1 set ip 10.10.10.1 next edit 2 set ip 10.10.10.2 set weight 2 next edit 3 set ip 10.10.10.3 set weight 3 end end

54


Example Adding a server load balance port forwarding virtual IP

CLI configuration

Example Adding a server load balance port forwarding virtual IP In this example, a virtual web server with IP address 192.168.37.4 on the Internet, is mapped to three real web servers connected to the FortiGate unit dmz1 interface. The real servers have IP addresses 10.10.123.42, 10.10.123.43, and 10.10.123.44. The virtual server uses the First Alive load balancing method. Each real server accepts HTTP connections on a different port number. The first real server accepts connections on port 8080, the second on port 8081, and the third on 8082. The configuration also includes an HTTP health check monitor that includes a URL used by the FortiGate unit for get requests to monitor the health of the real servers. Connections to the virtual web server at IP address 192.168.37.4 from the Internet are translated and load balanced to the real servers by the FortiGate unit. First alive load balancing directs all sessions to the first real server. The computers on the Internet are unaware of this translation and load balancing and see a single virtual server at IP address 192.168.37.4 rather than the three real servers behind the FortiGate unit.

Server load balance virtual IP port forwarding R

So De urce Po stina IP 10 rt R tion .10 an IP .10 ge . 80 10.10 2 80 -80 .10.[ 82 424

ea

ea

ea

IP er 4 rv .4 se 01 P .1 TT .31 l H 10

IP er 3 rv .4 se 01 P .1 TT .31 l H 10

IP er 4 rv .4 se 01 P .1 TT .31 l H 10

R

R

4]

3 1 HT

TP l virt oad b ua ala l se nc rve ing r

D

M

Z

N

et w

or

k

2

3 10

Z1 M 2 D 10. 0. .1

2

1

P rI ve er .4 l S 37 ua 8. irt 6 V 2.1 19

So De urce Po stina IP 17 rt 8 tion 2.1 0 IP 99.1 19 90 2.1 .2 68 5 .37 .4

17 2. IP nt 5 lie .2 C 90 1 9.

19

To complete this configuration, all of the steps would be the same as in Example Adding a server load balance port forwarding virtual IP on page 55 except for configuring the real servers.


55

CLI configuration

Example Adding a server load balance port forwarding virtual IP

To add the real servers and associate them with the virtual server Use the following steps to configure the FortiGate unit to port forward HTTP packets to the three real servers on ports 8080, 8081, and 8082. 1. Go to Policy & Objects > Real Servers. 2. Select Create New. 3. Configure three real servers that include the virtual server Load_Bal_VS1. Each real server must include the IP address of a real server on the internal network and have a different port number. Configuration for the first real server. Virtual Server

Load_Bal_VS1

IP Address

10.10.10.42

Port

8080

Weight


Max Connections

0

Configuration for the second real server. Virtual Server

Load_Bal_VS1

IP

10.10.10.43

Port

8081

Weight


Max Connections

0

Configuration for the third real server.

56

Virtual Server

Load_Bal_VS1

IP

10.10.10.44

Port

8082

Weight


Max Connections

0


Example Weighted load balancing configuration

GUI configuration

Example Weighted load balancing configuration This example shows how to using firewall load balancing to load balances all traffic among 3 real servers. In the example the Internet is connected to port2 and the virtual IP address of the virtual server is 192.168.20.20. The load balancing method is weighted. The IP addresses of the real servers are 10.10.10.1, 10.10.10.2, and 10.10.10.3. The weights for the real servers are 1, 2, and 3. This configuration does not include a health check monitor.

GUI configuration Use the following procedures to configure this load balancing setup from the FortiGate GUI.

To add the HTTP virtual server 1. Go to Policy & Objects > Virtual Servers. 2. Select Create New. 3. Add an IP virtual server that allows s on the Internet to connect to the real servers on the internal network. In this example, the FortiGate port2 interface is connected to the Internet. Name

HTTP_weghted_LB

Type

IP

Interface

port2

Virtual Server IP

192.168.20.20

Load Balance Method

Weighted

All other virtual server settings are not required or cannot be changed. 4. Select OK.

To add the real servers and associate them with the virtual server 1. Go to Policy & Objects > Real Servers. 2. Select Create New. 3. Configure three real servers that include the virtual server All_Load _Balance. Because the Load Balancing Method is Weighted, each real server includes a weight. Servers with a greater weight receive a greater proportion of forwarded connections, Configuration for the first real server. Virtual Server

HTTP_weghted_LB

IP Address

10.10.10.1


57

GUI configuration


Port

Cannot be configured because the virtual server is an IP server.

Weight

1

Max Connections


Configuration for the second real server. Virtual Server

HTTP_weghted_LB

IP Address

10.10.10.2

Port


Weight

2

Max Connections


Configuration for the third real server. Virtual Server

HTTP_weghted_LB

IP Address

10.10.10.3

Port


Weight

3

Max Connections


58



CLI configuration

To add the virtual server to a security policy Add a port2 to port1 security policy that uses the virtual server so that when s on the Internet attempt to connect to the web server’s IP address, packets through the FortiGate unit from the wan1 interface to the dmz1 interface. The virtual IP translates the destination address of these packets from the virtual server IP address to the real server IP addresses. 1. Go to Policy & Objects > IPv4 Policy. 2. Select Create New. 3. Configure the security policy: Name

Policy name

Incoming Interface

port2

Outgoing Interface

port1

Source

all (or a more specific address)

Destination

HTTP_weghted_LB

Schedule

always

Service

ALL

Action

ACCEPT

NAT



CLI configuration Load balancing is configured from the CLI using the config firewall vip command and by setting type to server-load-balance. The default weight is 1 and does not have to be changed for the first real server. Use the following command to add the virtual server and the three weighted real servers. config firewall vip edit HTTP_weghted_LB set type server-load-balance set server-type ip set extintf port2 set extip 192.168.20.20 set ldb-method weighted config realservers edit 1 set ip 10.10.10.1 next edit 2 set ip 10.10.10.2 set weight 2 next


59

CLI configuration


edit 3 set ip 10.10.10.3 set weight 3 end end

60


Example HTTP and HTTPS persistence configuration

CLI configuration

Example HTTP and HTTPS persistence configuration This example shows how to add a virtual server named HTTP_Load_Balance that load balances HTTP traffic using port 80 and a second virtual server named HTTPS_Load_Balance that load balances HTTPS traffic using port 443. The Internet is connected to port2 and the virtual IP address of the virtual server is 192.168.20.20. Both server load balancing virtual IPs load balance sessions to the same three real servers with IP addresses 10.10.10.2, 10.10.10.2, and 10.10.10.3. The real servers provide HTTP and HTTPS services. For both virtual servers, persistence is set to HTTP Cookie to enable HTTP cookie persistence.

To add the HTTP and HTTPS virtual servers 1. Go to Policy & Objects > Virtual Servers. 2. Add the HTTP virtual server that includes HTTP Cookie persistence. Name

HTTP_Load_Balance

Type

HTTP

Outgoing Interface

port2

Virtual Server IP

192.168.20.20

Virtual Server Port

80 In this example the virtual server uses port 8080 for HTTP sessions instead of port 80.

Load Balance Method

Static

Persistence

HTTP cookie

3. Select OK. 4. Select Create New. 5. Add the HTTPS virtual server that also includes HTTP Cookie persistence. Name

HTTPS_Load_Balance

Type

HTTPS

Outgoing Interface

port2

Virtual Server IP

192.168.20.20

Virtual Server Port

443

Load Balance Method

Static

Persistence

HTTP cookie

6. Select OK.


61

CLI configuration


To add the real servers and associate them with the virtual servers 1. Go to Policy & Objects > Real Servers. 2. Select Create New. 3. Configure three real servers for HTTP that include the virtual server HTTP_Load_Balance. Configuration for the first HTTP real server. Virtual Server

HTTP_Load_Balance

IP Address

10.10.10.1

Port

80

Weight


Max Connections

0

Configuration for the second HTTP real server. Virtual Server

HTTP_Load_Balance

IP Address

10.10.10.2

Port

80

Weight


Maximum Connections

0

Configuration for the third HTTP real server. Virtual Server

HTTP_Load_Balance

IP Address

10.10.10.3

Port

80

Weight


Max Connections

0

4. Configure three real servers for HTTPS that include the virtual server HTTPS_Load_Balance. Configuration for the first HTTPS real server.

62

Virtual Server

HTTP_Load_Balance

IP Address

10.10.10.1

Port

443



CLI configuration

Weight


Max Connections

0

Configuration for the second HTTPS real server. Virtual Server

HTTP_Load_Balance

IP Address

10.10.10.2

Port

443

Weight


Max Connections

0

Configuration for the third HTTPS real server. Virtual Server

HTTPS_Load_Balance

IP Address

10.10.10.3

Port

443

Weight


Max Connections

0

To add the virtual servers to security policies Add a port2 to port1 security policy that uses the virtual server so that when s on the Internet attempt to connect to the web server’s IP address, packets through the FortiGate unit from the wan1 interface to the dmz1 interface. The virtual IP translates the destination address of these packets from the virtual server IP address to the real server IP addresses. 1. Go to Policy & Objects > IPv4 Policy. 2. Select Create New. 3. Configure the HTTP security policy: Name

Policy name.

Incoming Interface

port2

Outgoing Interface

port1

Source

all

Destination

HTTP_Load_Balance

Schedule

always


63

CLI configuration: adding persistence for a specific domain


Service

HTTP

Action

ACCEPT

NAT


4. Select other security policy options as required. 5. Select OK. 6. Select Create New. 7. Configure the HTTP security policy: Name

Policy name.

Incoming Interface

port2

Outgoing Interface

port1

Source

all

Destination

HTTPS_Load_Balance

Schedule

always

Service

HTTPS

Action

ACCEPT

NAT



CLI configuration: adding persistence for a specific domain Load balancing is configured from the CLI using the config firewall vip command and by setting type to server-load-balance. For the CLI configuration, both virtual servers include setting http-cookie-domain to .example.org because HTTP cookie persistence is just required for the example.org domain. First, the configuration for the HTTP virtual IP: config firewall vip edit HTTP_Load_Balance set type server-load-balance set server-type http set extport 8080 set extintf port2 set extip 192.168.20.20 set persistence http-cookie set http-cookie-domain .example.org config realservers edit 1

64



CLI configuration: adding persistence for a specific domain

set ip 10.10.10.1 next edit 2 set ip 10.10.10.2 next edit 3 set ip 10.10.10.3 end end

Second, the configuration for the HTTPS virtual IP. In this configuration you don’t have to set extport to 443 because extport is automatically set to 443 when server-type is set to https. config firewall vip edit HTTPS_Load_Balance set type server-load-balance set server-type https set extport 443 set extintf port2 set extip 192.168.20.20 set persistence http-cookie set http-cookie-domain .example.org config realservers edit 1 set ip 10.10.10.1 next edit 2 set ip 10.10.10.2 next edit 3 set ip 10.10.10.3 end end


65

Copyright© 2017 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare® and FortiGuard®, and certain other marks are ed trademarks of Fortinet, Inc., in the U.S. and other jurisdictions, and other Fortinet names herein may also be ed and/or common law trademarks of Fortinet. All other product or company names may be trademarks of their respective owners. Performance and other metrics contained herein were attained in internal lab tests under ideal conditions, and actual performance and other results may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written contract, signed by Fortinet’s General Counsel, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-identified performance metrics and, in such event, only the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For absolute clarity, any such warranty will be limited to performance in the same ideal conditions as in Fortinet’s internal lab tests. In no event does Fortinet make any commitment related to future deliverables, features, or development, and circumstances may change such that any forward-looking statements herein are not accurate. Fortinet disclaims in full any covenants, representations, and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify, transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable.

Fortigate Load Balancing 2m2v2v

Overview 1s532p

More details 6h715l

Related Documents 2w1qw

Fortigate Load Balancing 2m2v2v

Fortigate Load Balancing 54 57383h

Fortigate Load Balance 521 111c48

Load Balancing Error 6w69

Informatica Load Balancing 72b5b

More Documents from "Mario Ortiz" 3k2y50

Maquinas Electricas Rotativas Mc Graw Hill.pdf 11tu

Fortigate Load Balancing 2m2v2v

Estatuto De La Upea e59x

Organigrama Del Departamento De Compra 2ry4a

504uu

Funciones Del Lenguaje 5f5t4f