Yearly Archives: 2019

Basic load balancing configuration example

This section describes the steps required to configure the load balancing configuration shown below. In this configuration a FortiGate-51B unit is load balancing HTTP traffic from the Internet to three HTTP servers on the Internal network. HTTP sessions are accepted at the wan1 interface with destination IP address 172.20.120.121 on TCP port 8080 and forwarded from the internal interface to the web servers. When forwarded the destination address of the sessions is translated to the IP address of one of the web servers.

The load balancing configuration also includes session persistence using HTTP cookies, round-robin load balancing, and TCP health monitoring for the real servers. Ping health monitoring consists of the FortiGate unit using ICMP ping to make sure the web servers can respond to network traffic.

Virtual server and real servers setup

To configure the example load balancing configuration – general configuration steps

Add a load balance ping health check monitor.

A ping health check monitor causes the FortiGate unit to ping the real servers every 10 seconds. If one of the servers does not respond within 2 seconds, the FortiGate unit will retry the ping 3 times before assuming that the HTTP server is not responding.

Add a load balance virtual server.
Add the three load balance real servers to the virtual server.
Add a security policy that includes the load balance virtual server as the destination address.

To configure the example load balancing configuration

Go to Policy & Objects > Health Check and add the following health check monitor.

Name		Ping-mon-1
Type		Ping
Interval		10 seconds
Timeout		2 seconds
Retry		3

Go to Policy & Objects > Virtual Servers and add a virtual server that accepts the traffic to be load balanced.

Name	Vserver-HTTP-1
Type	HTTP
Interface	wan1
Virtual Server IP	172.20.120.121
Virtual Server Port	8080
Load Balance Method	Round Robin
Persistence	HTTP Cookie
Health Check	Ping-mon-1
HTTP Multiplexing	Do not select
Preserve Client IP	Do not select

On the same GUI page and the real servers to the virtual server.

IP Address		10.31.101.30
Port		80
Max Connections		0
Mode		Active

Basic load balancing configuration example

IP Address	10.31.101.40
Port	80
Max Connections	0
Mode	Active
IP Address	10.31.101.50
Port	80
Max Connections	0
Mode	Active

Go to Policy & Objects > IPv4 Policy and add a wan1 to internal security policy that includes the virtual server.

This policy also applies an Antivirus profile to the load balanced sessions.

Name	Example-policy
Incoming Interface	wan1
Outgoing Interface	internal
Source	all
Destination	Vserver-HTTP-1
Schedule	always
Service	ALL
Action	ACCEPT
NAT	Turn on NAT and select Use Outgoing Interface Address.
Antivirus	Turn on and select an Antivirus profile.

Select OK.

To configure the example load balancing configuration from the CLI

Use the following command to add a Ping health check monitor.

config firewall ldb-monitor edit ping-mon-l set type ping set interval 10 set timeout 2

set retry 3 end

Use the following command to add the virtual server that accepts HTTP sessions on port 8080 at the wan1 interface and load balances the traffic to three real servers. config firewall vip

Basic load balancing configuration example

edit Vserver-HTTP-1 set type server-load-balance set server-type http set ldb-method round-robin set extip 172.20.120.30 set extintf wan1 set extport 8080 set persistence http-cookie set monitor tcp-mon-1 config realservers edit 1 set ip 10.31.101.30

set port 80 next edit 2 set ip 10.31.101.40

set port 80 end edit 3 set ip 10.31.101.50

set port 80 end

end

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 srcintf wan1 set srcaddr all set dstintf internal set dstaddr Vserver-HTTP-1 set action accept set schedule always set service ALL set nat enable set utm-status enable

set profile-protocol-options default set av-profile scan end

Inside FortiOS: Server Load Balancing

Leave a reply

Inside FortiOS: Server Load Balancing

Server load balancing distributes workloads across multiple network servers, allowing simultaneous IPv4, IPv6, IPv4 to IPv6 and IPv6 to IPv4 requests to be handled quickly and reliably.

Server Load Balancing combined with NGFW and UTM protection

By introducing comprehensive server load balancing functionality to Next Generation Firewall (NGFW) and Unified Threat Management (UTM) solutions FortiOS takes threat protection to a whole new level. Rather than going to the expense of deploying multiple solutions to protect your server farm, you can combine firewalling, NGFW, UTM and load balancing into a single FortiGate unit or cluster. The benefit of consolidation is not only limited to cost.

Key Features & Benefits

Increased resilience

A consolidated solution results in significantly simplified network architecture. High availability can be provided for all technologies with just a pair of devices rather than several.

Reduced

operational overheads

A unified management solution consisting of a single GUI, logging and reporting, SNMP monitoring and other management functions will significantly reduce the resources required to manage the multiple technology areas. A consolidated solution provides a single point of contact for support and renewals rather than having to deal with multiple vendors.

The FortiOS server load balancing feature set contains all of the features you would expect of a server load balancing solution. Traffic can be balanced across multiple backend servers based on multiple load balancing schedules including static (failover), round robin, weighted to account for different sized servers, or based on the health and performance of the server including round trip time and number of connections.

The load balancer supports HTTP, HTTPS, IMAPS, POP3S, SMTPS, SSL/TLS, and generic TCP/UDP and IP protocols. Session persistence is supported based on the SSL session ID, based on an injected HTTP cookie, or based on the HTTP or HTTPS host. SSL/TLS load balancing includes protection from protocol downgrade SSL/TLS offloading Inside FortiOS: Server Load Balancing attacks. Server load balancing is supported on most FortiGate devices and includes up to 10,000 virtual servers on our high end systems.

SSL/TLS offloading

With more and more critical business applications being made available online and in the cloud, the demand for secure remote continues to increase. While securing web and email applications with SSL/TLS is essential, this protection adds significant performance overheads. An SSL/TLS protected application running on a standard server will perform all the costly encryption/decryption and key exchange routines in software which uses vital CPU resources that should be available for running the application. The consequence of this is that many more or more powerful servers are required to deliver the application.

FortiGate SSL/TLS offloading is designed with the explosion of SSL/TLS applications in mind. The key exchange and encryption/decryption tasks are offloaded to the FortiGate unit where they are accelerated using FortiASIC technology providing significantly more performance than a standard server or load balancer could handle. This frees up valuable resources on the server farm which can be used to run a more responsive business. Server load balancing offloads most SSL/TLS versions including SSL 3.0, TLS 1.0 and TLS 1.2 and supports full mode or half mode SSL offloading with DH key sizes up to 4096 bits.

SSL/TLS content inspection

Traditionally, SSL encrypted application data would be invisible to any border gateway filtering solution. This is because the encryption process prevents the payload of any connection from being seen other than by the communicating systems. FortiGate SSL Offloading allows the application payload to be inspected before it reaches your servers; preventing intrusion attempts, blocking viruses, stopping unwanted applications, and preventing data leakage. SSL/TLS content inspection supports TLS versions 1.0, 1.1, and 1.2 and SSL versions 1.0, 1.1, 1.2, and 3.0.

Health Check

Health checking can be enabled to prevent load balancing traffic from being sent to a non-functioning real server. Real server health can be monitored using ICMP ping or more sophisticated TCP testing. The most comprehensive test is HTTP which verifies that the HTTP application is responding and that it is returning the correct content.

Health checking removes real servers from the load balancing cluster which are returning invalid content. The removal of real servers from the clusters is based on the Interval, Timeout and Retry Settings:

Interval	How often to test the server.
Timeout	What maximum response time is permissible before a server is treated as non-functional.
Retry	How many failures before the server is considered “dead” and removed from the cluster.

Server Monitoring and Management

The health and performance of real servers can be monitored from the FortiGate GUI. Virtual servers and their assigned real servers can be monitored for health status, if there have been any monitor events, number of active sessions, round trip time and number of bytes processed. Should a server become problematic and require

administration, it can be gracefully removed from the Real Server pool to enable disruption free maintenance. When a removed real server is able to operate it can gracefully be added back to the virtual server.

HTTP Multiplexing

A performance saving feature of HTTP/1.1 compliant web servers is the ability to pipeline requests on the same connection. This allows a single HTTPD process on the server to interleave and server multiple requests. HTTP multiplexing reduces the number idle sessions, too many of which can exhaust the resources on a server. The Fortinet solution has the ability to take multiple separate inbound sessions and multiplex them over the same internal session. This reduces the load on the backend server and increases the overall performance.

FortiOS Server Load Balancing Introduction

Leave a reply

Introduction

FortiOS server load balancing includes the features you would expect of any server load balancing solution. Traffic can be distributed across multiple backend servers based on multiple methods including static (failover), round robin, weighted to account for different sized servers, or based on the health and performance of the server including round trip time, number of connections. The load balancer supports HTTP, HTTPS, IMAPS, POP3S, SMTPS, SSL or generic TCP/UDP or IP protocols. Session persistence is supported based on the SSL session ID or based on an injected HTTP cookie.

Before you begin

Before you can configure server load balancing on the GUI go to System > Feature Visibility and turn on Load Balance. Its in the Additional Features list.

To be able to use all of the features described in this chapter you should go to System > Settings and setting the Inspection Mode to Proxy. If Inspection mode is set to Flow-based, you can only configure Virtual Servers with Type set to HTTP, TCP, UDP, or IP. Proxy mode is required for persistence, HTTP Multiplexing, SSL offloading and other advanced HTTP and SSL features.

White Board Session – ADVPN Architecture Explanation

2 Replies

This is a short explanation video / white board session where I go over the high level architecture and benefits of an ADVPN. Dynamic VPN’s provide us the opportunity to grow our IT infrastructure without growing our management headache.

Diagnose commands for WAN optimization

Leave a reply

Diagnose commands for WAN optimization

The following get and diagnose commands are available for troubleshooting WAN optimization, web cache, explicit proxy and WCCP.

get test {wad | wccpd} <test_level>

Display usage information about WAN optimization, explicit proxy, web cache, and WCCP applications. Use <test_level> to display different information.

get test wad <test_level> get test wccpd <test_level>

Variable	Description
wad	Display information about WAN optimization, web caching, the explicit web proxy, and the explicit FTP proxy.
wccpd	Display information about the WCCP application.

Examples

Enter the following command to display WAN optimization tunnel protocol statistics. The http tunnel and tcp tunnel parts of the command output below shows that WAN optimization has been processing HTTP and TCP packets.

get test wad 1

WAD manager process status: pid=113 n_workers=1 ndebug_workers=0 Enter the following command to display all test options:

get test wad

WAD process 82 test usage:

1: display process status 2: display total memory usage.

99: restart all WAD processes 1000: List all WAD processes.

1001: dispaly debug level name and values 1002: dispaly status of WANOpt storages 1068: Enable debug for all WAD workers.

1069: Disable debug for all WAD workers.

2yxx: Set No. xx process of type y as diagnosis process. 3: display all fix-sized advanced memory stats

4: display all fix-sized advanced memory stats in details

500000..599999: cmem bucket stats (599999 for usage)

800..899: mem_diag commands (800 for help & usage)

800000..899999: mem_diag commands with 1 arg (800 for help & usage) 80000000..89999999: mem_diag commands with 2 args (800 for help & usage) 60: show debug stats.

diagnose wad

61: discard all wad debug info that is currently pending

62xxx: set xxxM maximum ouput buffer size for WAD debug. 0, set back to default.

68: Enable process debug

69: Disable process debug

98: gracefully stopping WAD process

9xx: Set xx workers(0: default based on user configuration.)

diagnose wad

Display diagnostic information about the WAN optimization daemon (wad).

diagnose wad console-log {disable | enable) diagnose wad debug-url {disable | enable)

diagnose wad filter {clear | dport | dst | list | negate | protocol | sport | src | vd} diagnose wad history {clear | list} diagnose wad session {clear | list}

diagnose wad stats {cache | cifs | clear | crypto | ftp | http | list | mapi | mem | scan | scripts | summary | tcp | tunnel}

diagnose wad user {clear | list} diagnose wad tunnel {clear | list}1

diagnose wad webcache {clear | list} {10min | hour | day | 30days}

Variable	Description
console-log	Enable or disable displaying WAN optimization log messages on the CLI console.
filter	Set a filter for listing WAN optimization daemon sessions or tunnels. clear reset or clear the current log filter settings. dport enter the destination port range to filter by. dst enter the destination address range to filter by. list display the current log filter settings
history	Display statistics for one or more WAN optimization protocols for a specified period of time (the last 10 minutes, hour, day or 30 days).
session	Display diagnostics for WAN optimization sessions or clear active sessions.
stats	Display statistics for various parts of WAN optimization such as cache statistics, CIFS statistics, MAPI statistics, HTTP statistics, tunnel statistics etc. You can also clear WAN optimization statistics and display a summary.
tunnel	Display diagnostic information for one or all active WAN optimization tunnels. Clear all active tunnels. Clear all active tunnels.
webcache	Display web cache activity for the specified time period.

diagnose wad

Example diagnose wad tunnel list

Enter the following command to list all of the running WAN optimization tunnels and display information about each one. The command output shows 10 tunnels all created by peer-to-peer WAN optimization rules (autodetect set to off).

diagnose wad tunnel list

Tunnel: id=100 type=manual vd=0 shared=no uses=0 state=3

peer name=Web_servers id=100 ip=172.20.120.141

SSL-secured-tunnel=no auth-grp= bytes_in=348 bytes_out=384

Tunnel: id=99 type=manual vd=0 shared=no uses=0 state=3

peer name=Web_servers id=99 ip=172.20.120.141

SSL-secured-tunnel=no auth-grp= bytes_in=348 bytes_out=384

Tunnel: id=98 type=manual vd=0 shared=no uses=0 state=3

peer name=Web_servers id=98 ip=172.20.120.141

SSL-secured-tunnel=no auth-grp= bytes_in=348 bytes_out=384

Tunnel: id=39 type=manual vd=0 shared=no uses=0 state=3

peer name=Web_servers id=39 ip=172.20.120.141

SSL-secured-tunnel=no auth-grp= bytes_in=1068 bytes_out=1104

Tunnel: id=7 type=manual vd=0 shared=no uses=0 state=3

peer name=Web_servers id=7 ip=172.20.120.141