WCCP packet flow

The following packet flow sequence assumes you have configured a FortiGate unit to be a WCCP server and one or more FortiGate units to be WCCP clients.

1. A user’s web browser sends a request for web content.
2. The FortiGate unit configured as a WCCP server includes a security policy that intercepts the request and forwards it to a WCCP client.

The security policy can apply UTM features to traffic accepted by the policy.

3. The WCCP client receives the WCCP session.
4. The client either returns requested content to the WCCP server if it is already cached, or connects to the destination web server, receives and caches the content and then returns it to the WCCP server.
5. The WCCP server returns the requested content to the user’s web browser.
6. The WCCP router returns the request to the client web browser.

The client we browser is not aware that all this is taking place and does not have to be configured to use a web proxy.

Configuring the forward and return methods and adding authentication

The WCCP forwarding method determines how intercepted traffic is transmitted from the WCCP router to the WCCP cache engine. There are two different forwarding methods:

• GRE forwarding (the default) encapsulates the intercepted packet in an IP GRE header with a source IP address of the WCCP router and a destination IP address of the target WCCP cache engine. The results is a tunnel that allows the WCCP router to be multiple hops away from the WCCP cache server.
• L2 forwarding rewrites the destination MAC address of the intercepted packet to match the MAC address of the target WCCP cache engine. L2 forwarding requires that the WCCP router is Layer 2 adjacent to the WCCP client.

You can use the following command on a FortiGate unit configured as a WCCP router to change the forward and return methods to L2:

config system wccp edit 1 set forward-method L2 set return-method L2

end

You can also set the forward and return methods to any in order to match the cache server configuration.

By default the WCCP communication between the router and cache servers is unencrypted. If you are concerned about attackers sniffing the information in the WCCP stream you can use the following command to enable hashbased authentication of the WCCP traffic. You must enable authentication on the router and the cache engines and all must have the same password.

config system wccp edit 1 set authentication enable set password <password>

end

WCCP Messages

When the WCCP service is active on a web cache server it periodically sends a WCCP HERE I AM broadcast or unicast message to the FortiGate unit operating as a WCCP router. This message contains the following information:

• Web cache identity (the IP address of the web cache server). l Service info (the service group to join).

If the information received in the previous message matches what is expected, the FortiGate unit replies with a WCCP I SEE YOU message that contains the following details:

• Router identity (the FortiGate unit’s IP address. l Sent to IP (the web cache IP addresses to which the packets are addressed)

When both ends receive these two messages the connection is established, the service group is formed and the designated web cache is elected.

Troubleshooting WCCP

Two types of debug commands are available for debugging or troubleshooting a WCCP connection between a FortiGate unit operating as a WCCP router and its WCCP cache engines.

Real time debugging

The following commands can capture live WCCP messages:

diag debug en diag debug application wccpd <debug level>

Application debugging

The following commands display information about WCCP operations:

get test wccpd <integer> diag test application wccpd <integer> Where <integer> is a value between 1 and 6:

1. Display WCCP stats
2. Display WCCP config
3. Display WCCP cache servers
4. Display WCCP services
5. Display WCCP assignment
6. Display WCCP cache status

Enter the following command to view debugging output:

diag test application wccpd 3

Sample output from a successful WCCP connection:

service-0 in vdom-root: num=1, usable=1 cache server ID:

Troubleshooting WCCP

len=44, addr=172.16.78.8, weight=4135, status=0 rcv_id=6547, usable=1, fm=1, nq=0, dev=3(k3),

to=192.168.11.55 ch_no=0, num_router=1:

192.168.11.55

Sample output from the same command from an unsuccessful WCCP connection (because of a service group password mismatch):

service-0 in vdom-root: num=0, usable=0 diag debug application wccpd -1 Sample output: wccp_on_recv()-98: vdom-root recv: num=160, dev=3(3),

172.16.78.8->192.168.11.55

wccp2_receive_pkt()-1124: len=160, type=10, ver=0200, length=152 wccp2_receive_pkt()-1150: found component:t=0, len=20 wccp2_receive_pkt()-1150: found component:t=1, len=24 wccp2_receive_pkt()-1150: found component:t=3, len=44 wccp2_receive_pkt()-1150: found component:t=5, len=20 wccp2_receive_pkt()-1150: found component:t=8, len=24 wccp2_check_security_info()-326: MD5 check failed

Web Proxy Concepts

These are concepts that apply to both Transparent and Explicit Proxy.

Proxy Policy

Information on Proxy policy options can be found at Proxy Option Components on page 58

Configuration information can be found at Web Proxy Configuration on page 309

Proxy Authentication

Beginning in FortiOS 5.6, authentication is separated from authorization for user based policy. You can add authentication to proxy policies to control access to the policy and to identify users and apply different UTM features to different users. The described authenication methodology works with Explicit Web Proxy and Transparent Proxy.

Authentication of web proxy sessions uses HTTP basic and digest authentication as described in RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication) and prompts the user for credentials from the browser allowing individual users to be identified by their web browser instead of IP address. HTTP authentication allows the FortiGate unit to distinguish between multiple users accessing services from a shared IP address.

The methodology of adding authentication has changed from FortiOS version 5.4 and previous version. Splitpolicy has been obsoleted and instead of identity-based-policy, authentication is managed by authenticationscheme, setting and rule settings. These authentication settings are no longer configured with the individual policies. Authentication is set up in the contexts of:

config authentication scheme config authentication setting config authentication rule

The Authentication rule table defines how to identify user-ID. It uses the match factors:

l Protocol l Source Address

For one address and protocol, there is only one authentication rule. It is possible to configure multiple authentication methods for on one address. The client browser will chose one authentication method from the authentication methods list, but you can not control which authentication method will be chosen by the browser.

Matching

If a rule is matched, the authentication methods defined in the rule will be used to authenticate a user. The procedure works as the following:

Proxy Authentication

1. If it is IP-based, look up active user list to see a user existed from the source IP. If found, return the user ID.
2. If no method is set, an anonymous user is created to associate to the source-IP. Return the anonymous user. It is another way to bypass user authentication for some source IPs.
3. Use authentication methods to authenticate the user.
   • If no active method is defined, a failure will result to return an anonymous user. l Otherwise, a valid or guest user has to be identified to move on.
   • Return the identified user ID.

Once a user is returned, the policy match resumes until a policy is matched or default policy will be used.

Processing policies for Authentication

Authentication rules are checked once a User-ID is needed in order to resolve a match to a policy Use the following scenario as an example of the process.

There are 3 policies:

l policy1 does not have an associated user group l policy2 has an associated user group l policy3 does not have an associated user group

Step 1

If the traffic, based on protocol and source address matchespolicy 1, no user authentication is needed. The traffic is processed by policy1.

Step 2

If the traffic does not match policy 1, and any factor of policy 2 is not matched, continue to next policy.

If all the factors except the user-group of policy 2 are matched the authentication rule table is checked to get user-ID in the process in based on the procedure described earlier in Matching.

Step 3

When a user-ID is returned, whether it is a valid user or anonymous user, it is checked to see if the user is authorized by the user group associated with policy2. If yes, it is a match of policy2, and the traffic is processed by policy2. If not move on the next policy.

Step 4

For the purposes of the scenario, it will be assumed that the traffic either matches policy3 or that policy3 is the final policy that denies everything.

CLI Syntax

Removals:

l “split-policy” from firewall explicit-proxy-policy.

The previous method to set up a split policy was: config firewall explicit-proxy-policy Proxy Authentication

edit 1 set proxy web set identity-based enable set groups <User group> config identity-based-policy edit 1 set schedule “always” set utm-status enable set users “guest”

set profile-protocol-options “default” next

end

next

end

• “auth relative” from firewall explicit-proxy-policy

The following attributes have been removed from firewall explicit-proxy-policy:

• identity-based l ip-based l active-auth-method l sso-auth-method l require-tfa

Moves:

users and groups from firewall explicit-proxy-policy identity-based-policy to

config firewall proxy-policy edit 1 set groups <Group name> set users <User name> end Additions:

authentication scheme

config authentication scheme edit <name> set method [ntlm|basic|digest|form|negotiate|fsso|rsso|none]

• ntlm – NTLM authentication. l basic – Basic HTTP authentication. l digest – Digest HTTP authentication. l form – Form-based HTTP authentication. l negotiate – Negotiate authentication. l fsso – FSSO authentication.
• rsso – RADIUS Single Sign-On authentication. l none – No authentication.

Proxy Authentication authentication setting

config authentication setting set active-auth-scheme <string> set sso-auth-scheme <string> set captive-portal <string>

set captive-portal-port <integer value from 1 to 65535>

l active-auth-scheme – Active authentication method. l sso-auth-scheme – SSO authentication method. l captive-portal – Captive portal host name. l captive-portal-port – Captive portal port number.

authentication rule

config authentication rule edit <name of rule> set status [enable|disable] set protocol [http|ftp|socks] set srcaddr <name of address object> set srcaddr6 <name of address object> set ip-based [enable|disable] set active-auth-method <string> set sso-auth-method <string> set web-auth-cookie [enable|disable] set transaction-based [enable|disable] set comments

• status – Enable/disable auth rule status. l protocol – set protocols to be matched l srcaddr /srcaddr6 – Source address name. [srcaddr or srcaddr6(web proxy only) must be set]. l ip-based – Enable/disable IP-based authentication. l active-auth-method – Active authentication method.
• sso-auth-method – SSO authentication method (require ip-based enabled) l web-auth-cookie – Enable/disable Web authentication cookie. l transaction-based – Enable/disable transaction based authentication. l comments – Comment.

Configuring Authentication in Transparent Proxy

You can enable transparent web-proxy feature to support authentication. Follow these steps

1. Configure a firewall policy
2. Enable a UTM profile in the firewall policy. Whenever there is a UTM item enabled, the feature enables the profile-protocol-options.
3. Go to the Proxy Options

l In the GUI this is Security Profiles > Proxy Options. l In the CLI it is config firewall profile-protocol-options.

Edit the profile used by the policy.

Addresses

4. Enable HTTP in the profile.

In the GUI toggle on HTTP under Protocol Port Mapping In the CLI, the command sequence is:

config firewall profile-protocol-options edit <profile id> config http set status enable end

Fill out any other appropriate values.

5. Configure the proxy-policy, and set the value transparent-web for proxy option, others configuration are same as the explicit-web proxy

In the GUI, go to Policy & Objects > Proxy Policy. In the Proxy Type field choose Transparent Web .

In the CLI, the command sequence is:

config firewall proxy-policy edit <profile id> set proxy transparent-web end

Fill out any other appropriate values.

6. Setup the authentication rule and scheme

With this configuration, if a HTTP request passes through FortiGate without explicit web proxy being applied, the traffic will be redirected to WAD daemon after it matches the proxy with HTTP-policy enabled, then WAD will do the proxy-policy matching, and all of the proxy authentication method can be used for the request.

Proxy Addresses

Information on Proxy addresses can be found at Proxy Addresses on page 175

Proxy Address group

In the same way that IPv4 and IPv6 addresses can only be grouped together, Proxy addresses can only be grouped with other Proxy addresses. Unlike the other address groups, the Proxy address groups are further divided into source address groups and destination address groups. To see the configuration steps go to Proxy Address Groups on page 177

Web Proxy firewall services and service groups

Configure web proxy services by selecting Explicit Proxy when configuring a service. Web proxy services can be selected in a explicit web proxy policy when adding one from the CLI. If you add a policy from the web-based manager the service is set to the webproxy service. The webproxy service should be used in most cases, it matches with any traffic with any port number. However, if you have special requirements, such as using a

Learn client IP

custom protocol type or a reduced port range or need to add an IP/FQDN to an proxy service you can create custom explicit web proxy services.

Web proxy services are similar to standard firewall services. You can configure web proxy services to define one or more protocols and port numbers that are associated with each web proxy service. Web proxy services can also be grouped into web proxy service groups.

One way in which web proxy services differ from firewall services is the protocol type you can select. The following protocol types are available:

l ALL l CONNECT l FTP l HTTP l SOCKS-TCP l SOCKS-UDP

To add a web proxy service go to Policy & Objects > Servicesand select Create New. Set Service Type to Explicit Proxy and configure the service as required.

To add a web proxy service from the CLI enter:

config firewall service custom edit my-socks-service set explicit-proxy enable set category Web Proxy set protocol SOCKS-TCP set tcp-portrange 3450-3490

end

To add a web proxy service group go to Policy & Objects > Servicesand select Create New > Service Group. Set Type to Explicit Proxy and add web proxy services to the group as required.

To add a web proxy service group from the CLI enter:

config firewall service group edit web-group set explicit-proxy enable set member webproxy my-socks-service

end

Learn client IP

If there is another NATing device between the FortiGate and the Client (browser), this feature can be used to identify the real client in spite of the address translation. Knowing the actual client is imperative in cases where authorization is taking place.

The settings for the feature are in the CLI in the context of config web-proxy global

Once here, enable the feature with the command:

set learn-client-ip enable

Learn client IP

Once the feature is enabled, the other settings become available.

learn-client-ip-from-header This command has the following options:

learn-client-ip-srcaddr/learn-client-ip-srcaddr6

The options for this setting are selected from the list of IPv4 address or IPv6 address objects.

Example

Below is a config example where the real client ip address will be used to match policy or fsso authentication after the learn-client-ip feature enabled.

The value of learn-client-ip-from-header option can be set to true-client-ip, x-real-ip or x-forwarded-for, but in this case it has been set to x-forward-for.

config web-proxy global set proxy-fqdn “default.fqdn” set webproxy-profile “default” set learn-client-ip enable

set learn-client-ip-from-header x-forwarded-for set learn-client-ip-srcaddr “all” end

config firewall proxy-policy edit 1 set proxy explicit-web set dstintf “mgmt1” set srcaddr “all” set dstaddr “all” set service “w” set action accept set schedule “always” set groups “fsso1” set utm-status enable set av-profile “default” set dlp-sensor “default” set profile-protocol-options “default” set ssl-ssh-profile “deep-inspection” end

config authentication rule edit “rule1” set srcaddr “all” set sso-auth-method “scheme1”

end

Learn client IP

config authentication scheme

edit “scheme1”

set method fsso end

Web Proxy Configuration

General web proxy configuration steps

You can use the following general steps to configure the explicit web proxy.

To enable the explicit web proxy – web-based manager:

1. Go to Network > Explicit Proxy and enable Explicit Web Proxy. From here you can optionally change the HTTP port that the proxy listens on (the default is 8080) and optionally specify different ports for HTTPS, FTP, PAC, and other options.
2. Optionally enable IPv6 Explicit Proxy to turn on the explicit web proxy for IPv6 traffic.

If you enable both the IPv4 and the IPv6 explicit web proxy you can combine IPv4 and IPv6 addresses in a single explicit web proxy policy to allow both IPv4 and IPv6 traffic through the proxy.

3. Select Apply.
4. Go to Network > Interfaces and select one or more interfaces for which to enable the explicit web proxy. Edit the interface. Under the Miscellaneous heading select Enable Explicit Web Proxy.

Enabling the explicit web proxy on an interface connected to the Internet is a security risk because anyone on the Internet who finds the proxy could use it to hide their source address. If you enable the proxy on such an interface make sure authentication is required to use the proxy.

5. Go to Policy & Objects > Addresses and select Create New to add a firewall address that matches the source address of packets to be accepted by the explicit proxy.

*The Interface must be set to Any.

You can also set the Type to URL Pattern (Explicit Proxy) to add a destination URL that is only used by the explicit proxy. For example, to create an explicit policy that only allows access to Fortinet.com:

General web proxy configuration steps                                                                                 Web Proxy Configuration

6. Go to Policy & Objects > Proxy Policyand select Create New. Configure the policy as required to accept the traffic that you want to be allowed to use the explicit web proxy.
7. Set the Outgoing Interface parameter by selecting the field with the “+” next to the field label. Selecting the field will slide out a window from the right where you can select from the available interfaces. You can select one or more specific interfaces For more information on interfaces, check the Concepts section called Interfaces and Zones.
8. The Source of the policy must match the client’s source IP addresses. The interface of this firewall address must be set to any.
9. The Destination field should match the addresses of web sites that clients are connecting to. Usually the destination address would be all if proxying Internet web browsing. You could also specify a URL firewall address to limit the policy to allowing access to this URL.
10. Set the Schedule parameter by using the drop down menu to select a preconfigured schedule. The “+” icon next to the Search field is a shortcut for creating a new schedule object. For more information on addresses, check the Firewall Objects section called Firewall schedules
11. If Default Firewall Policy Action is set to Deny (under Network > Explicit Proxy), traffic sent to the explicit web proxy that is not accepted by a web-proxy policy is dropped. If Default Firewall Policy Action is set to Allow then all web-proxy sessions that don’t match with a security policy are allowed.

For example, the following security policy allows users on an internal network to access fortinet.com websites through the wan1 interface of a FortiGate unit.

12. Set the Disclaimer Options

You can configure a disclaimer for each Authentication Rule by enabling one of the options here. The

choices are:

If you chose a disclaimer option other than Disable, you will have the option to enable Customize Messages. If enabled, select the Edit Disclaimer Message button to customize the message to your needs. This can be done as text or as HTML. The default HTML version is there if you just want to make minor changes.

13. Enable Security Profiles as required. Once the profile type is toggled to enabled, you can use the drop down menu to select a specific profile. The available profile types are:

• AntiVirus l WebFilter l Application Control l IPS l DLP Sensor
• ICAP
• Web Application Firewall

Just like with a regular policy, as soon as any of the Security Profiles is enabled, the following fields, with their own drop down menus for specific profiles will appear:

• Proxy Options l SSL/SSH Inspection

14. Select OK.

To enable the explicit web proxy – CLI:

1. Enter the following command to turn on the IPv4 and IPv6 explicit web proxy for HTTP and HTTPS traffic.

config web-proxy explicit set status enable set ipv6-status enable

end

You can also enter the following command to enable the web proxy for FTP sessions in a web browser.

config web-proxy explicit set ftp-over-http enable

end

The default explicit web proxy configuration has sec-default-action set to deny and requires you to add a security policy to allow access to the explicit web proxy.

General web proxy configuration steps                                                                                 Web Proxy Configuration

2. Enter the following command to enable the explicit web proxy for the internal interface. config system interface edit internal set explicit-web-proxy enable

end

end

3. Use the following command to add a firewall address that matches the source address of users who connect to the explicit web proxy.

config firewall address edit Internal_subnet set type iprange set start-ip 10.31.101.1 set end-ip 10.31.101.255

end

The source address for a web-proxy security policy cannot be assigned to a FortiGate interface.

4. Optionally use the following command to add a destination URL that is only used by the explicit proxy. For example, to create an explicit policy that only allows access to Fortinet.com:

config firewall address edit Fortinet-web-sites set type url set url fortinet.com

end

5. Use the following command to add an explicit web proxy policy that allows all users on the internal subnet to use the explicit web proxy for connections through the wan1 interface to the Internet.

config firewall proxy-policy edit 0 set proxy explicit-web set dstintf wan1 set scraddr Internal_subnet

set dstaddr all set action accept set service webproxy set schedule always

end

6. Use the following command to add an explicit web proxy policy that allows authenticated users on the internal subnet to use the explicit web proxy for connections through the wan1 interface to the Internet.

config firewall proxy-policy edit 0 set proxy explicit-web set dstintf wan1 set scraddr Internal_subnet set dstaddr Fortinet-web-sites set action accept set service webproxy set schedule always set groups <User group>

end

end

7. Use the following command to change global web proxy settings, for example to set the maximum request length for the explicit web proxy to 10:

config web-proxy global set max-request-length 10

end

8. Determine whether or not to use Botnet feature.

The option scan-botnet-connections uses the following syntax:

config firewall proxy-policy edit <policy id> set scan-botnet-connections [disable|block|monitor] end

Where:

l disable means do not scan connections to botnet servers l block means block connection to botnet servers l monitor means log connections to botnet servers

Explicit Proxy Concepts

The following is information that is specific to Explicit Proxy concepts. Any information that is common to Web

Proxy in general is covered in the more inclusive section of Web Proxy Concepts on page 301

The FortiGate explicit web proxy

You can use the FortiGate explicit web proxy to enable explicit proxying of IPv4 and IPv6 HTTP, and HTTPS traffic on one or more FortiGate interfaces. The explicit web proxy also supports proxying FTP sessions from a web browser and proxy auto-config (PAC) to provide automatic proxy configurations for explicit web proxy users. From the CLI you can also configure the explicit web proxy to support SOCKS sessions from a web browser.

The explicit web and FTP proxies can be operating at the same time on the same or on different FortiGate interfaces.

In most cases you would configure the explicit web proxy for users on a network by enabling the explicit web proxy on the FortiGate interface connected to that network. Users on the network would configure their web browsers to use a proxy server for HTTP and HTTPS, FTP, or SOCKS and set the proxy server IP address to the IP address of the FortiGate interface connected to their network. Users could also enter the PAC URL into their web browser PAC configuration to automate their web proxy configuration using a PAC file stored on the FortiGate unit.

Enabling the explicit web proxy on an interface connected to the Internet is a security risk because anyone on the Internet who finds the proxy could use it to hide their source address.

If the FortiGate unit is operating in Transparent mode, users would configure their browsers to use a proxy server with the FortiGate management IP address.

If the FortiGate unit is operating with multiple VDOMs the explicit web proxy is configured for each VDOM.

The web proxy receives web browser sessions to be proxied at FortiGate interfaces with the explicit web proxy enabled. The web proxy uses FortiGate routing to route sessions through the FortiGate unit to a destination interface. Before a session leaves the exiting interface, the explicit web proxy changes the source addresses of the session packets to the IP address of the exiting interface. When the FortiGate unit is operating in Transparent mode the explicit web proxy changes the source addresses to the management IP address. You can configure the explicit web proxy to keep the original client IP address. See The FortiGate explicit web proxy on page 314.

For more information about explicit web proxy sessions, see The FortiGate explicit web proxy on page 314. 314

Other explicit web proxy options

Example explicit web proxy topology

To allow all explicit web proxy traffic to pass through the FortiGate unit you can set the explicit web proxy default firewall policy action to accept. However, in most cases you would want to use security policies to control explicit web proxy traffic and apply security features such as access control/authentication, virus scanning, web filtering, application control, and traffic logging. You can do this by keeping the default explicit web proxy security policy action to deny and then adding web-proxy security policies.

You can also change the explicit web proxy default security policy action to accept and add explicit web proxy security policies. If you do this, sessions that match web-proxy security policies are processed according to the security policy settings. Connections to the explicit web proxy that do not match a web-proxy security policy are allowed with no restrictions or additional security processing. This configuration is not recommended and is not a best practice.

The explicit web-proxy can accept VIP addresses for destination address. If an external IP matches a VIP policy, the IP is changed to the mapped-IP of the VIP.

Web-proxy policies can selectively accept or deny traffic, apply authentication, enable traffic logging, and use security profiles to apply virus scanning, web filtering, IPS, application control, DLP, and SSL/SSH inspection to explicit web proxy traffic.

You cannot configure IPsec, SSL VPN, or Traffic shaping for explicit web proxy traffic. Web Proxy policies can only include firewall addresses not assigned to a FortiGate unit interface or with interface set to Any. (On the web-based manager you must set the interface to Any. In the CLI you must unset the associatedinterface.)

Authentication of explicit web proxy sessions uses HTTP authentication and can be based on the user’s source IP address or on cookies from the user’s web browser. For more information, see The FortiGate explicit web proxy on page 314.

To use the explicit web proxy, users must add the IP address of a FortiGate interface on which the explicit web proxy is enabled and the explicit web proxy port number (default 8080) to the proxy configuration settings of their web browsers.

On FortiGate units that support it, you can also enable web caching for explicit web proxy sessions.

Other explicit web proxy options

You can change the following explicit web proxy options as required by your configuration.

Other explicit web proxy options

HTTP port, HTTPS port, FTP port, PAC port

The TCP port that web browsers use to connect to the explicit proxy for HTTP, HTTPS, FTP and PAC services. The default port is 8080 for all services. By default HTTPS, FTP. and PAC use the same port as HTTP. You can change any of these ports as required. Users configuring their web browsers to use the explicit web proxy should add the same port numbers to their browser configurations.

Proxy FQDN

Enter the fully qualified domain name (FQDN) for the proxy server. This is the domain name to enter into browsers to access the proxy server.

Max HTTP request length

Enter the maximum length of an HTTP request in Kbytes. Larger requests will be rejected.

Max HTTP message length

Enter the maximum length of an HTTP message in Kbytes. Larger messages will be rejected.

Multiple incoming ports and port ranges

Web proxy can be configured to listen on multiple ports on the same IP as well as listen for HTTP and HTTPS on those same (or different) ports. This is done in the CLI.

Define the IP ranges using a hyphen (–). As shown below, port_high is not necessary to specify if port_low is equal to port_high.

CLI syntax

config web-proxy explicit set http-incoming-port <port_low> [-<port_high>]

end

Internet services

FortiOS can use the Internet Service Database (introduced in 5.4.1) as a web-proxy policy matching factor. This can only be done in the CLI.

CLI syntax:

config firewall proxy-policy edit 0 set internet-service <application-id> set internet-service-custom <application-name>

IP Pools

IP Pools can be used with web proxy. When using this option of setting the IP pool name, the outgoing IP will be selected.

Proxy chaining (web proxy forwarding servers)

CLI syntax

config firewall proxy-policy edit <example> set poolname <name> end

Proxy chaining (web proxy forwarding servers)

For the explicit web proxy you can configure web proxy forwarding servers to use proxy chaining to redirect web proxy sessions to other proxy servers. Proxy chaining can be used to forward web proxy sessions from the FortiGate unit to one or more other proxy servers on your network or on a remote network. You can use proxy chaining to integrate the FortiGate explicit web proxy with an web proxy solution that you already have in place.

A FortiGate unit can forward sessions to most web proxy servers including a remote FortiGate unit with the explicit web proxy enabled. No special configuration of the explicit web proxy on the remote FortiGate unit is required.

You can deploy the explicit web proxy with proxy chaining in an enterprise environment consisting of small satellite offices and a main office. If each office has a FortiGate unit, users at each of the satellite offices can use their local FortiGate unit as an explicit web proxy server. The satellite office FortiGate units can forward explicit web proxy sessions to an explicit web proxy server at the central office. From here the sessions can connect to web servers on the Internet.

FortiGate proxy chaining does not support authenticating with the remote forwarding server.

Adding a web proxy forwarding server

To add a forwarding server, select Create New in the Web Proxy Forwarding Servers section of the Explicit Proxy page by going to Network > Explicit Proxy.

Proxy chaining (web proxy forwarding servers)

Use the following CLI command to add a web proxy forwarding server named fwd-srv at address proxy.example.com and port 8080.

config web-proxy forward-server edit fwd-srv set addr-type fqdn set fqdn proxy.example.com

set port 8080

end

Web proxy forwarding server monitoring and health checking

By default, a FortiGate unit monitors web proxy forwarding server by forwarding a connection to the remote server every 10 seconds. If the remote server does not respond it is assumed to be down. Checking continues and when the server does send a response the server is assumed to be back up. If you configure health checking, every 10 seconds the FortiGate unit attempts to get a response from a web server by connecting through the remote forwarding server.

You can configure health checking for each remote server and specify a different website to check for each one.

If the remote server is found to be down you can configure the FortiGate unit to block sessions until the server comes back up or to allow sessions to connect to their destination, bypassing the remote forwarding server. You cannot configure the FortiGate unit to fail over to another remote forwarding server.

Configure the server down action and enable health monitoring from the web-based manager by going to Network > Explicit Proxy, selecting a forwarding server, and changing the server down action and changing the health monitor settings.

Use the following CLI command to enable health checking for a web proxy forwarding server and set the server down option to bypass the forwarding server if it is down.

config web-proxy forward-server edit fwd-srv set healthcheck enable set monitor http://example.com set server-down-option pass

end

Grouping forwarding servers and load balancing traffic to them

You can add multiple web proxy forwarding servers to a forwarding server group and then add the server group to an explicit web proxy policy instead of adding a single server. Forwarding server groups are created from the FortiGate CLI but can be added to policies from the web-based manager (or from the CLI).

When you create a forwarding server group you can select a load balancing method to control how sessions are load balanced to the forwarding servers in the server group. Two load balancing methods are available:

Proxy chaining (web proxy forwarding servers)

l Weighted load balancing sends more sessions to the servers with higher weights. You can configure the weight for each server when you add it to the group. l Least-session load balancing sends new sessions to the forwarding server that is processing the fewest sessions.

When you create a forwarding server group you can also enable affinity. Enable affinity to have requests from the same client processed by the same server. This can reduce delays caused by using multiple servers for a single multi-step client operation. Affinity takes precedence over load balancing.

You can also configure the behavior of the group if all of the servers in the group are down. You can select to block traffic or you can select to have the traffic pass through the FortiGate explicit proxy directly to its destination instead of being sent to one of the forwarding servers.

Use the following command to add a forwarding server group that users weighted load balancing to load balance traffic to three forwarding servers. Server weights are configured to send most traffic to server2. The group has affinity enabled and blocks traffic if all of the forward servers are down:

config web-proxy forward-server edit server_1 set ip 172.20.120.12 set port 8080

next edit server_2 set ip 172.20.120.13 set port 8000

next edit server_3 set ip 172.20.120.14 set port 8090

next end

config web-proxy forward-server-group edit New-fwd-group set affinity enable set ldb-method weight set group-down-option block config server-list edit server_1 set weight 10

next edit server_2 set weight 40

next edit server_3 set weight 10

next end

Adding proxy chaining to an explicit web proxy policy

You enable proxy chaining for web proxy sessions by adding a web proxy forwarding server or server group to an explicit web proxy policy. In a policy you can select one web proxy forwarding server or server group. All explicit web proxy traffic accepted by this security policy is forwarded to the specified web proxy forwarding server or server group.

Security profiles, threat weight, device identification, and the explicit web proxy

To add an explicit web proxy forwarding server – web-based manager:

1. Go to Policy & Objects > Proxy Policy and select Create New.
2. Configure the policy:

3. Select OK to save the security policy.

To add an explicit web proxy forwarding server – CLI:

1. Use the following command to add a security policy that allows all users on the 10.31.101.0 subnet to use the explicit web proxy for connections through the wan1 interface to the Internet. The policy forwards web proxy sessions to a remote forwarding server named fwd-srv config firewall proxy-policy edit 0 set proxy explicit-web set dstintf wan1 set scraddr Internal_subnet

set dstaddr all set action accept set schedule always

set webproxy-forward-server fwd-srv end

Security profiles, threat weight, device identification, and the explicit web proxy

You can apply all security profiles to explicit web proxy sessions. This includes antivirus, web filtering, intrusion protection (IPS), application control, data leak prevention (DLP), and SSL/SSH inspection. Security profiles are applied by selecting them in an explicit web proxy policy or in authentication rules added to web proxy policies.

Traffic accepted by explicit web proxy policies contributes to threat weight data.

The explicit web proxy is not compatible with device identification.

Since the traffic accepted by the explicit web proxy is known to be either HTTP, HTTPS, or FTP over HTTP and since the ports are already known by the proxy, the explicit web proxy does not use all of the SSL/SSH inspection options. The explicit web proxy does support the following proxy options:

Explicit web proxy sessions and user limits

• Enable chunked bypass
• HTTP oversized file action and threshold

The explicit web proxy does not support the following proxy options:

• Client comforting l Server comforting l Monitor content information from dashboard. URLs visited by explicit web proxy users are not added to dashboard usage and log and archive statistics widgets.

For explicit web proxy sessions, the FortiGate unit applies antivirus scanning to HTTP POST requests and HTTP responses. The FortiGate unit starts virus scanning a file in an HTTP session when it receives a file in the body of an HTML request. The explicit web proxy can receive HTTP responses from either the originating web server or the FortiGate web cache module.

Explicit web proxy sessions and user limits

Web browsers and web servers open and close multiple sessions with the explicit web proxy. Some sessions open and close very quickly. HTTP 1.1 keepalive sessions are persistent and can remain open for long periods of time. Sessions can remain on the explicit web proxy session list after a user has stopped using the proxy (and has, for example, closed their browser). If an explicit web proxy session is idle for more than 3600 seconds it is torn down by the explicit web proxy. See RFC 2616 for information about HTTP keepalive/persistent HTTP sessions.

This section describes proxy sessions and user limits for both the explicit web proxy and the explicit FTP proxy. Session and user limits for the two proxies are counted and calculated together. However, in most cases if both proxies are active there will be many more web proxy sessions than FTP proxy sessions.

The FortiGate unit adds two sessions to its session table for every explicit proxy session started by a web browser and every FTP session started by an FTP client. An entry is added to the session table for the session from the web browser or client to the explicit proxy. All of these sessions have the same destination port as the explicit web proxy port (usually 8080 for HTTP and 21 for FTP). An entry is also added to the session table for the session between the exiting FortiGate interface and the web or FTP server destination of the session. All of these sessions have a FortiGate interface IP address and the source address of the session and usually have a destination port of 80 for HTTP and 21 for FTP.

Proxy sessions that appear in FortiView do not include the Policy ID of the web-proxy or ftp-proxy security policy that accepted them. However, the explicit proxy sessions include a destination port that matches the explicit proxy port number (usually 8080 for the web proxy and 21 for the FTP proxy). The proxied sessions from the FortiGate unit have their source address set to the IP address of the FortiGate unit interface that the sessions use to connect to their destinations (for example, for connections to the Internet the source address would be the IP address of the FortiGate interface connected to the Internet).

FortiOS limits the number of explicit proxy users. This includes both explicit FTP proxy and explicit web proxy users. The number of users varies by FortiGate model from as low as 10 to up to 18000 for high end models. You cannot raise this limit.

If your FortiGate unit is configured for multiple VDOMs you can go to System > Global Resourcesto view the maximum number of Concurrent explicit proxy users and optionally reduce the limit. You can also use the following command:

config global config system resource-limits set proxy 50

Explicit web proxy sessions and user limits

end

end

To limit the number of explicit proxy users for a VDOM, from the web-based manager enable multiple VDOMs and go to System > VDOM and edit a VDOM or use the following command to change the number of explicit web proxy users for VDOM_1:

config global config system vdom-property edit VDOM_1 set proxy 25

end

end

You can use the diagnose wad user list command to view the number of explicit web proxy users. Users may be displayed with this command even if they are no longer actively using the proxy. All idle sessions time out after 3600 seconds.

You can use the command diagnose wad user clear to clear current explicit proxy users. You can also use the command diagnose wad user clear <user-name> to clear individual users. This means delete information about all users and force them re-authenticate.

Users that authenticate with explicit web-proxy or ftp-proxy security policies do not appear in the Monitor > Firewall User Monitor list and selecting De-authenticate All Users has no effect on explicit proxy users.

How the number of concurrent explicit proxy users is determined depends on their authentication method:

• For session-based authenticated users, each authenticated user is counted as a single user. Since multiple users can have the same user name, the proxy attempts to identify users according to their authentication membership (based upon whether they were authenticated using RADIUS, LADAP, FSAE, local database etc.). If a user of one session has the same name and membership as a user of another session, the explicit proxy assumes this is one user.
• For IP Based authentication, or no authentication, or if no web-proxy security policy has been added, the source IP address is used to determine a user. All sessions from a single source address are assumed to be from the same user.

The explicit proxy does not limit the number of active sessions for each user. As a result the actual explicit proxy session count is usually much higher than the number of explicit web proxy users. If an excessive number of explicit web proxy sessions is compromising system performance you can limit the amount of users if the FortiGate unit is operating with multiple VDOMs.

Explicit Proxy Configuration

The following is information that is specific to Explicit Proxy configuration.

Configuring an external IP address for the IPv4 explicit web proxy

You can use the following command to set an external IP address (or pool) that will be used by the explicit web proxy policy.

config web-proxy explicit set status enable

set outgoing-ip <ip1> <ip2> … <ipN>

end

Configuring an external IP address for the IPv6 explicit web proxy

You can use the following command to set an external IP address (or pool) that will be used by the explicit web proxy policy.

config web-proxy explicit set status enable

set outgoing-ipv6 <ip1> <ip2> … <ipN>

end

Restricting the IP address of the IPv4 explicit web proxy

You can use the following command to restrict access to the explicit web proxy using only one IP address. The IP address that you specify must be the IP address of an interface that the explicit web proxy is enabled on. You might want to use this option if the explicit FTP proxy is enabled on an interface with multiple IP addresses.

For example, to require uses to connect to the IP address 10.31.101.100 to connect to the explicit web proxy:

config web-proxy explicit set incoming-ip 10.31.101.100

end

Restricting the outgoing source IP address of the IPv4 explicit web proxy

You can use the following command to restrict the source address of outgoing web proxy packets to a single IP address. The IP address that you specify must be the IP address of an interface that the explicit web proxy is Restricting the IP address of the explicit IPv6 web proxy

enabled on. You might want to use this option if the explicit web proxy is enabled on an interface with multiple IP addresses.

For example, to restrict the outgoing packet source address to 172.20.120.100:

config web-proxy explicit set outgoing-ip 172.20.120.100

end

Restricting the IP address of the explicit IPv6 web proxy

You can use the following command to restrict access to the IPv6 explicit web proxy to use only one IP6 IP address. The IPv6 address that you specify must be the IPv6 address of an interface that the explicit web proxy is enabled on. You might want to use this option if the explicit web proxy is enabled on an interface with multiple IPv6 addresses.

For example, to require uses to connect to the IPv6 address 2001:db8:0:2::30 to connect to the explicit IPv6 web proxy:

config web-proxy explicit set incoming-ipv6 2001:db8:0:2::30

end

Restricting the outgoing source IP address of the IPv6 explicit web proxy

You can use the following command to restrict the source address of outgoing web proxy packets to a single IPv6 address. The IP address that you specify must be the IPv6 address of an interface that the explicit web proxy is enabled on. You might want to use this option if the explicit web proxy is enabled on an interface with multiple IPv6 addresses.

For example, to restrict the outgoing packet source address to 2001:db8:0:2::50:

config web-proxy explicit set outgoing-ipv6 2001:db8:0:2::50

end

Explicit proxy firewall address types

Explicit proxy firewall address types improve granularity over header matching for explicit web proxy policies. You can enable this option using the Show in Address List button on the Address and Address Group New/Edit forms under Policy & Objects > Addresses.

The following address types are available:

• URL Pattern – destination address l Host Regex Match – destination address l URL Category – destination address (URL filtering) l HTTP Method – source address l User Agent – source address

Proxy auto-config (PAC) configuration

• HTTP Header – source address l Advanced (Source) – source address (combines User Agent, HTTP Method, and HTTP Header) l Advanced (Destination) – destination address (combines Host Regex Match and URL Category)

Proxy auto-config (PAC) configuration

A proxy auto-config (PAC) file defines how web browsers can choose a proxy server for receiving HTTP content. PAC files include the FindProxyForURL(url, host) JavaScript function that returns a string with one or more access method specifications. These specifications cause the web browser to use a particular proxy server or to connect directly.

To configure PAC for explicit web proxy users, you can use the port that PAC traffic from client web browsers use to connect to the explicit web proxy. explicit web proxy users must configure their web browser’s PAC proxy settings to use the PAC port.

PAC File Content

You can edit the default PAC file from the web-based manager or use the following command to upload a custom PAC file:

config web-proxy explicit set pac-file-server-status enable set pac-file-data <pac_file_str>

end

Where <pac_file_str> is the contents of the PAC file. Enter the PAC file text in quotes. You can copy the contents of a PAC text file and paste the contents into the CLI using this option. Enter the command followed by two sets of quotes then place the cursor between the quotes and paste the file content.

The maximum PAC file size is 256 kbytes. If your FortiGate unit is operating with multiple VDOMs each VDOM has its own PAC file. The total amount of FortiGate memory available to store all of these PAC files 2 MBytes. If this limit is reached you will not be able to load any additional PAC files.

You can use any PAC file syntax that is supported by your users’s browsers. The FortiGate unit does not parse the PAC file.

To use PAC, users must add an automatic proxy configuration URL (or PAC URL) to their web browser proxy configuration. The default FortiGate PAC file URL is:

http://<interface_ip>:<PAC_port_int>/<pac_file_str>

For example, if the interface with the explicit web proxy has IP address 172.20.120.122, the PAC port is the same as the default HTTP explicit web proxy port (8080) and the PAC file name is proxy.pac the PAC file URL would be:

http://172.20.120.122:8080/proxy.pac

From the CLI you can use the following command to display the PAC file URLs:

get web-proxy explicit

Unknown HTTP version

Unknown HTTP version

You can select the action to take when the proxy server must handle an unknown HTTP version request or message. Set unknown HTTP version to Reject or Best Effort. Best Effort attempts to handle the HTTP traffic as best as it can. Reject treats known HTTP traffic as malformed and drops it. The Reject option is more secure.

Authentication realm

You can enter an authentication realm to identify the explicit web proxy. The realm can be any text string of up to 63 characters. If the realm includes spaces enclose it in quotes. When a user authenticates with the explicit web proxy the HTTP authentication dialog includes the realm so you can use the realm to identify the explicitly web proxy for your users.

Implementing Botnet features

The option scan-botnet-connections can be added to an explicit proxy policy.

CLI Syntax:

config firewall proxy-policy edit <policy_id> set scan-botnet-connections [disable|block|monitor]

end where:

l disable means do not scan connections to botnet servers. l block means block connections to botnet servers. l monitor means log connections to botnet servers.

Adding disclaimer messages to explicit proxy policies

This feature allows you to create user exceptions for specific URL categories (including warning messages) based on user groups. The Disclaimer Options are configured under Policy & Objects > Proxy Policy.

You can also configure a disclaimer for each Authentication Rule by setting Action to Authenticate.

Disclaimer explanations

• Disable: No disclaimer (default setting).
• By Domain: The disclaimer will be displayed on different domains. The explicit web proxy will check the referring header to mitigate the javascript/css/images/video/etc page.
• By Policy: The disclaimer will be displayed if the HTTP request matches a different explicit firewall policy. l By User: The disclaimer will be displayed when a new user logs on.

Changing HTTP headers

Changing HTTP headers

You can create explicit web proxy profiles that can add, remove and change HTTP headers. The explicit web proxy profile can be added to a web explicit proxy policy and will be applied to all of the HTTP traffic accepted by that policy.

You can change the following HTTP headers:

• client-ip l via header for forwarded requests l via header for forwarded responses l x-forwarded-for l front-end-https

For each of these headers you can set the action to:

• Pass to forward the traffic without changing the header l Add to add the header l Remove to remove the header

You can also configure how the explicit web proxy handles custom headers. The proxy can add or remove custom headers from requests or responses. If you are adding a header you can specify the content to be included in the added header.

Create web proxy profiles from the CLI:

config web-proxy profile edit <name> set header-client-ip {add | pass | remove} set header-via-request {add | pass | remove} set header-via-response {add | pass | remove} set header-x-forwarded-for {add | pass | remove} set header-front-end-https {add | pass | remove} config headers edit <id> set action {add-to-request | add-to-response | remove-from-request | remove-from-response}

set content <string> set name <name>

end end

Use the following command to add a web proxy profile to an explicit proxy policy:

config firewall proxy-policy edit <id> set webproxy-profile <name>

end

Preventing the explicit web proxy from changing source addresses

By default in NAT/Route mode the explicit web proxy changes the source address of packets leaving the

FortiGate to the IP address of the FortiGate interface that the packets are exiting from. In Transparent mode the

source address is changed to the management IP.

This configuration hides the IP addresses of clients and allows packets to return to the FortiGate unit interface without having to route packets from clients. You can use the following command to configure the explicit web proxy to keep the original client’s source IP address:

config firewall proxy-policy edit 0 set proxy explicit-web set transparent enable

end

Example users on an internal network browsing the Internet through the explicit web proxy with web caching, RADIUS authentication, web filtering, and virus scanning

This example describes how to configure the explicit web proxy for the example network shown below. In this example, users on the internal network connect to the explicit web proxy through the Internal interface of the FortiGate unit. The explicit web proxy is configured to use port 8888 so users must configure their web browser proxy settings to use port 8888 and IP address 10.31.101.100.

Example explicit web proxy network topology

Explicit web proxy users must authenticate with a RADIUS server before getting access to the proxy. The explicit proxy policy that accepts explicit web proxy traffic applies per session authentication and includes a RADIUS server user group. The authentication rule also applies web filtering and virus scanning.

General configuration steps

This section breaks down the configuration for this example into smaller procedures. For best results, follow the procedures in the order given:

1. Enable the explicit web proxy for HTTP and HTTPS and change the HTTP and HTTPS ports to 8888.
2. Enable the explicit web proxy on the internal interface.
3. Add a RADIUS server and user group for the explicit web proxy.
4. Add an authentication explicit proxy policy. Enable web caching. Add an authentication rule and enable antivirus and web filtering.

Preventing the explicit web proxy from changing source addresses

Configuring the explicit web proxy – web-based manager

Use the following steps to configure the explicit web proxy.

To enable and configure the explicit web proxy

1. Go to System > Feature Visibility and turn on the Explicit Proxy
2. Go to Network > Explicit Proxy and change the following settings:

3. Select Apply.

To enable the explicit web proxy on the Internal interface

1. Go to Network > Interfaces.
2. Edit the internal interface.
3. Select Enable Explicit Web Proxy.
4. Select OK.

To add a RADIUS server and user group for the explicit web proxy

1. Go to User & Device > RADIUS Servers and select Create New to add a new RADIUS server:

2. Select OK.
3. Go to User & Device > User Groups and select Create New to add a new user group.

4. Select OK.

To add an explicit proxy policy

1. Go to Policy & Objects > Addresses and select Create New.
2. Add a firewall address for the internal network:

3. Go to Policy & Objects > Proxy Policy and select Create New.
4. Configure the explicit web proxy policy.

5. Under Configure Authentication Rules select Create New to add an authentication rule:

6. Turn on Antivirus and Web Filter and select the default profiles for both.
7. Select the default proxy options profile.
8. Select OK.
9. Make sure Enable IP Based Authentication is not selected.
10. Turn on Web Cache.
11. Select OK.

Configuring the explicit web proxy – CLI

Use the following steps to configure the example explicit web proxy configuration from the CLI.

To enable the explicit web proxy on the Internal interface

1. Enter the following command to enable the explicit web proxy on the internal interface.

Preventing the explicit web proxy from changing source addresses

config system interface edit internal set explicit-web-proxy enable

end

To enable and configure the explicit web proxy

1. Enter the following command to enable the explicit web proxy and set the TCP port that proxy accepts HTTP and HTTPS connections on to 8888.

config web-proxy explicit set status enable set http-incoming-port 8888 set https-incoming-port 8888

set realm “You are authenticating with the explicit web proxy” set sec-default-action deny

end

To add a RADIUS server and user group for the explicit web proxy

1. Enter the following command to add a RADIUS server:

config user radius edit RADIUS_1 set server 10.31.101.200 set secret RADIUS_server_secret

end

2. Enter the following command to add a user group for the RADIUS server.

config user group edit Explicit_proxy_user_group set group-type firewall set member RADIUS_1

end

To add a security policy for the explicit web proxy

1. Enter the following command to add a firewall address for the internal subnet:

config firewall address edit Internal_subnet set type iprange set start-ip 10.31.101.1 set end-ip 10.31.101.255

end

2. Enter the following command to add the explicit web proxy security policy:

config firewall proxy-policy edit 0 set proxy explicit-web set dstintf wan1 set srcaddr Internal_subnet

set dstaddr all set action accept set service webproxy set webcache enable set identity-based enable set ipbased disable

set active-auth-method basic set groups <User group> end

Testing and troubleshooting the configuration

You can use the following steps to verify that the explicit web proxy configuration is working as expected:

To test the explicit web proxy configuration

1. Configure a web browser on the internal subnet to use a web proxy server at IP address 10.31.101.100 and port 8888.
2. Browse to an Internet web page.

The web browser should pop up an authentication window that includes the phrase that you added to the Realm option.

3. Enter the username and password for an account on the RADIUS server.

If the account is valid you should be allowed to browse web pages on the Internet.

4. Close the browser and clear its cache and cookies.
5. Restart the browser and connect to the Internet.

You could also start a second web browser on the same PC. Or you could start a new instance of the same browser as long as the browser asks for a user name and password again.

You should have to authenticate again because identity-based policies are set to session-based authentication.

6. If this basic functionality does not work, check your FortiGate and web browser configuration settings.
7. Browse to a URL on the URL filter list and confirm that the web page is blocked.
8. Browse to http://eicar.org and attempt to download an anti-malware test file.

The antivirus configuration should block the file.

Sessions for web-proxy security policies do not appear on the Top Sessions dashboard widget and the count column for security policies does not display a count for explicit web proxy security policies.

9. You can use the following command to display explicit web proxy sessions

get test wad 60 IP based users:

Session based users:

user:0x9c20778, username:User1, vf_id:0, ref_cnt:9

Total allocated user:1

Total user count:3, shared user quota:50, shared user count:3

This command output shows one explicit proxy user with user name User1 authenticated using session-based authentication.

Kerberos and NTLM authentication

FortiOS recognizes the client’s authentication method from the token and selects the correct authentication scheme to authenticate successfully.

CLI syntax

config firewall proxy-policy edit 0

set active-auth-method [ntlm|basic|digest|negotiate|none] end

Kerberos authentication for explicit proxy users

Kerberos authentication is a method for authenticating both explicit web proxy and transparent web proxy users. It has several advantages over NTLM challenge response:

• Does not require FSSO/AD agents to be deployed across domains. l Requires fewer round-trips than NTLM SSO, making it less latency sensitive.
• Is (probably) more scalable than challenge response. l Uses existing Windows domain components rather than added components. l NTLM may still be used as a fallback for non-Kerberos clients.

Enhancements to Kerberos explicit and transparent web proxy

FortiOS 5.6.x authentication is managed by schemes and rules based on protocol and source address. As such, configurable authentication settings have been introduced to enhance authentication.

CLI commands (config authentication rule, scheme, and setting) allow explicit proxy rules and schemes to be created to separate user authentication (e.g. authentication rules and schemes used to match conditions in order to identify users) from user authorization (proxy-based policies with users and/or user groups).

CLI syntax – config authentication rule

config authentication rule edit <name> set name <name> set status {enable|disable} set protocol {http|ftp|socks} config srcaddr <addr-name or addrgrp-name> edit <name> set name <ipv4-policy-name>

next

end

config srcaddr6 <addr-name or addrgrp-name> edit <name> set name <ipv6-policy-name>

next

end set ip-based {enable|disable} set active-auth-method <scheme-name> set sso-auth-method <scheme-name>

set transaction-based {enable|disable} – basic scheme + session-based set web-auth-cookie {enable|disable} set comments <comments>

next

end

Note: As shown above, HTTP, FTP, and SOCKSv5 authentication protocols are supported for explicit proxy.

Authentication rules are used to receive user-identity, based on the values set for protocol and source address. Having said this, if a rule fails to match based on source address, there will be no other attempt to match the rule, however the next policy will be attempted. This occurs only when:

l there is an authentication rule, but no authentication method has been set (under config authentication scheme; see below), so user identity cannot be found. l the user is successfully matched in the rule, but fails to match the current policy.

Once a rule is positively matched through protocol and/or source address, it must also match the authentication method specified (active-auth-method and sso-auth-method). These methods point to schemes, as defined under config authentication scheme.

CLI syntax – config authentication scheme

config authentication scheme edit <name> set name <name>

set method {basic|digest|ntlm|form|negotiate|fsso|rsso} set negotiate-ntlm {enable|disable} set require-tfa {enable|disable} set fsso-guest {enable|disable} config user-database edit <name> set name {local|<ldap-server>|<radius-server>|<fsso-name>|<rsso-name>|<tacacs+name>}

next

end

next

end

Combining authentication rules and schemes, granular control can be exerted over users and IPs, creating an efficient process for users to successfully match a criteria before matching the policy.

Additional options can be set under config authentication setting.

CLI syntax – config authentication setting

config authentication setting set sso-scheme <scheme-name> set active-scheme <scheme-name> set captive-portal <host-name> set captive-portal-port <tcp-port>

end

Integration of Transparent and Explicit proxy HTTP policy checking

A CLI command, under config firewall profile-protocol-options, allows HTTP policy checking to be enable or disabled. When enabled, transparent traffic can be matched in a firewall policy and policy user authentication can occur. In addition, separate SSL inspection policies can be created:

config firewall profile-protocol-options edit <name> set http-policy {enable|disable} end

Internet Service Database in Explicit/Implicit proxy policies

CLI commands, under config firewall proxy-policy, implement the Internet Service Database (ISDB) as the webproxy matching factor, and override IP pool is also support:

config firewall proxy-policy edit <name> set proxy {explicit-web|transparent-web|ftp|wanopt} set dstintf <dst-name> set poolname <ip-pool-name>

end

Multiple port/port range support for explicit web and explicit FTP proxy

Multiple port numbers and/or ranges can be set for explicit proxy, specifically for HTTP/HTTPS and FTP. Go to Network > Explicit Proxy and configure settings under Explicit Web Proxy and Explicit FTP Proxy, or under config web-proxy explicit in the CLI Console.

1. General configuration

1.1 Kerberos environment – Windows server setup

1. Build a Windows 2008 Platform server.
2. Enable domain configuration in windows server (dcpromo).
3. Set the domain name TEST.COM (realm name).

1.2 Create users

• testuser is a normal user (could be any existing domain user account).
• testfgt is the service name. In this case it should be the FQDN for the explicit proxy Interface, For example the hostname in the client browser proxy config. l Recommendation: create username all in lowercase (even if against corporate standards).
• The account only requires “domain users” membership l Password set to never expire l Set a very strong password
  • Add FortiGate to DNS

For Lab/Testing add the FortiGate Domain name and IP mapping in the hosts file

(windows/system32/drivers/etc/hosts). e.g., TESTFGT.TEST.COM 10.10.1.10

• Generate the Kerberos keytab

Use the ktpass command (found on Windows Servers and many domain workstations) to generate the Kerberos keytab.

Example:

ktpass -princ HTTP/<domain name of test fgt>@realm -mapuser testfgt -pass <password> crypto all -ptype KRB5_NT_PRINCIPAL -out fgt.keytab

Example:

ktpass -princ HTTP/testfgt.test.com@TEST.COM -mapuser testfgt -pass 12345678 -crypto all ptype KRB5_NT_PRINCIPAL -out fgt.keytab

• Encode base64

Use the base64 command (available in most Linux distros) command to encode the fgt.keytab file. Any LF (Line Feed) need to be deleted from the file. Example:

base64 fgt.keytab > fgt.txt

2. FortiGate configuration

2.1 Create LDAP Server instance

config user ldap edit “ldap” <<< Required for authorization set server “10.10.1.1” <<< LDAP server IP, normally it should be same as KDC server set cnid “cn” set dn “dc=test,dc=com” set type regular

set username “CN=admin,CN=Users,DC=test,DC=com” <<< Your domain may require STARTTLS set password <FOOS>

next

end

2.2 Define Kerberos as an authentication service

config user krb-keytab edit “http_service” set principal “HTTP/testfgt.test.com@TEST.COM” <<< Same as the principal name in 1.4 set ldap-server “ldap” <<< the defined ldap server for authoriztion set keytab

“BQIAAABNAAIACkJFUkJFUi5DT00ABEhUVFAAGlRPTllfRkdUXzEwMERfQS5CRVJCRVIuQ09NAAAAAQA

AAAAKABcAEJQl0MHqovwplu7XzfENJzw=” <<< base64 endoding keytab data, created in step 1.5 next

end

2.3 Create user group(s)

config user group <<< the group is used for kerberos authentication edit “testgrp” set member “ldap” config match

edit 1 set server-name “ldap” <<< Same as ldap-server option in krb-keytab set group-name “CN=Domain Users,CN=Users,DC=TEST,DC=com”

next

end

next

end

2.4 Create firewall policy

config firewall proxy-policy

edit 1 set uuid 5e5dd6c4-952c-51e5-b363-120ad77c1414 set proxy explicit-web set dstintf “port1” set srcaddr “all” set dstaddr “all” set service “webproxy” set action accept set schedule “always” set groups “CN=USERS LAB.PS FSSO”

next

end

2.5 Diagnostics

Once the keytab is imported, check that it has been properly decoded. The filename generated will be relatively random, but should be clearly visible.

Artoo-Deetoo (root) # fnsysctl ls -la /tmp/kt drwxr–r– 2 0  0 Fri Dec 2 10:06:43 2016   60 . drwxrwxrwt 22 0  0 Tue Dec 6 14:28:29 2016    3280 .. -rw-r–r– 1 0  0 Fri Dec 2 10:06:43 2016   392 1.0.89.keytab

3. Client side walkthrough

3.1 Check Kerberos is working

Log on to the domain by using testuser, created in 1.2. Use the klist command to list ticket information. In the below example, the client has received krbtgt, CIFS, and LDAP tickets. As there has been no interaction with the FortiGate, there are no references to it.

C:\Users\glenk>klist Cached Tickets: (5)

C:\Users\glenk>klist

Cached Tickets: (5)

#0> Client: glenk @ home.local

Server: krbtgt/HOME.LOCAL @ HOME.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x60a00000 -> forwardable forwarded renewable pre_authent

Start Time: 12/6/2016 14:58:06 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

#1> Client: glenk @ home.local

Server: krbtgt/HOME.LOCAL @ HOME.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent

Start Time: 12/6/2016 14:58:04 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

#2> Client: glenk @ home.local

Server: cifs/EthicsGradient.home.local @ HOME.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate

Start Time: 12/6/2016 14:58:06 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

#3> Client: glenk @ home.local

Server: ldap/EthicsGradient.home.local @ HOME.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate

Start Time: 12/6/2016 14:58:06 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

#4> Client: glenk @ home.local

Server: LDAP/EthicsGradient.home.local/home.local @ HOME.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate

Start Time: 12/6/2016 14:58:06 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

3.2 Configure client

Set up web-proxy in browser through the FortiGate. This can be achieved via a PAC file or direct browser configuration.

Some Firefox documentation indicates that it is necessary to make manual advanced configuration changes to allow Kerberos authentication work. However, builds 48 (and possibly much earlier) require no additional configuration beyond setting of the proxy server.

3.3 Open a connection to the Internet

1. The client accesses the explicit proxy, but a HTTP 407 Proxy Authentication Required is returned.
2. As “Negotiate” is set, the client has knowledge of the KRBTGT, it requests a ticket from the KDC with a krb-tgsreq This includes the REALM (HOME.LOCAL) in the reg-body section, and the provided instances SNAME and service (in this case, HTTP/artoo-deetoo.home.local).
3. The KDC responds with a next KRB-TGS-REP.

This ticket is then available on the client.

In the example below, the ticket-granted-service has issued Ticket #2.

#2> Client: glenk @ home.local

Server: HTTP/artoo-deetoo.home.local @ HOME.LOCAL

KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)

Ticket Flags 0x40a00000 -> forwardable renewable pre_authent

Start Time: 12/6/2016 14:59:45 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: RSADSI RC4-HMAC(NT)

4. The conversation between the client and the proxy continues, as the client responds with the Kerberos ticket in the response.

The whole process takes less than a second to complete. The user should be visible as a FSSO logon in the Web UI.

Transparent web-proxy Kerberos authentication

Transparent web-proxy is new to FortiOS 5.6, in which the FortiGate can process level 7 policy matching, even when the explicit web-proxy is not enabled on the client’s browser. The transparent web-proxy policy is set in proxy-policy too. The policy matching rule is the same as the explicit web-proxy.

In the firewall policy level, transparent web-proxy is regarded as a special UTM. The HTTP/HTTPS traffic matches the firewall policy first, then traffic is redirected to the web-proxy daemon. If the trasnparent web-proxy feature is disabled, http-policy options in profile-protocol-options is used to enable transparent web-proxy feature.

IP-based

1. Captive portal and the captive portal port must be configured in transparent web-proxy for support of Kerberos authentication:

config authentication setting set captive-portal <fqdn-name> set captive-portal-port “9998”

end

2. Authentication rule, scheme, and krb-keytab need to be configured for Kerberos authentication (note the active-auth-method scheme referenced in the rule):

config authentication scheme

edit <kerberos-scheme> set method negotiate set negotiate-ntlm <enable> set fsso-guest <disable>

next

end

config authentication rule edit <name> set status <enable> set protocol <http> set srcadrr “all” set ip-based <enable>

set active-auth-method <kerberos-scheme>

next

end

config user krb-keytab edit <name> set principal “HTTP/TESTFGT.TEST.COM@TEST.COM” set ldap-server “ldap”

set keytab <base64-encoding-keytab-data>

next

end

3. Configure LDAP and user group used for authorization:

config user ldap edit “ldap” set server “10.10.1.1” set cnid srt dn set type <regular>

set username “CN=admin,CN=Users,DC=test,DC=com”

set password ENC aW5lIAHkPMf4D+ZCKpGMU3x8Fpq0G+7uIbAvpblbXFA5vLfgb4/oRBx+B6R/v+CMCetP84e+Gdz5zEcM yOd3cjoBoIhFrpYJfXhRs4lSEOHezeVXfxwTSf5VJG+F11G/G5RpaY+AE8bortC8MBe7P2/uGQocFHu4

Ilulp5I6OJvyk6Ei3hDZMjTd8iPp5IkRJZVVjQ== next

end

config user group edit “testgrp” set memeber “ldap” config match edit “1” set server-name “ldap”

set group-name “CN=Domain Users,CN=Users,DC=TEST,DC=com”

next

end

next

end

4. Create proxy-policy, with groups as the authorizing policy-matching element:

config firewall proxy-policy edit 1 set uuid 1bbb891a-9cd2-51e7-42ff-d1fa13cac3da set proxy explicit-web

set dstintf “any” set srcaddr “all” set dstaddr “all” set service “webproxy” set action accept set schedule “always” set groups testgrp

next

end

5. UTM must be enabled in the firewall policy to support the transparent web-proxy:

config firewall policy edit “1” set name “policy1”

set uuid 8a6ceeac-b016-51e6-2b5c-165070d5bf50

set srcintf “mgmt1” set dstintf “mgmt1” set srcaddr “all” set dstaddr “all” set action <accept> set schedule “always” set service “ALL” set utm-status <enable>

set profile-protocol-options “transparent-web-proxy” set ssl-ssh-profile “deep-inspection”

set nat <enable>

next

end

config firewall profile-protocol-options edit “transparent-web-proxy” config http set ports “80 8080” unset options set http-policy enable unset post-lang end …

next

end

Session-based with web-auth cookie

The web-auth-cookie feature is necessary for session-based authentication under transparent web-proxy.

The configuration is the same as for IP-based authentication, except ip-based is disabled in the authentication rule:

config authentication rule edit “kerberos-rules” set status <enable> set protocol <http> set srcadrr “all” set ip-based <disable>

set active-auth-method <kerberos-scheme> next

config authentication setting set captive-portal <fqdn-name> set captive-portal-port “9998” end

Transparent Proxy Concepts

In addition to the Explicit Web Proxy, FortiOS supports a Transparent web proxy. While it does not have as many features as Explicit Web Proxy, the transparent proxy has the advantage that nothing needs to be done on the user’s system to forward supported web traffic over to the proxy. There is no need to reconfigure the browser or publish a PAC file. Everything is transparent to the end user, hence the name. This makes it easier to incorporate new users into a proxy deployment.

You can use the transparent proxy to apply web authentication to HTTP traffic accepted by a firewall policy. In previous versions of FortiOS, web authentication required using the explicit proxy.

Normal FortiOS authentication is IP address based. Users are authenticated according to their IP address and access is allowed or denied based on this IP address. On networks where authentication based on IP address will not work you can use the Transparent Web proxy to apply web authentication that is based on the user’s browser and not on their IP address. This authentication method allows you to identify individual users even if multiple users on your network are connecting to the FortiGate from the same IP address.

More about the transparent proxy

The following changes are incorporated into Transparent proxy, some of which affect Explicit Web Proxy as well.

Flat policies

The split policy feature has been removed. This will make the explicit policy more like the firewall policy.

Authentication

The authentication design is intended to separate authentication from authorization. Authentication has been moved into a new table in the FortiOS. This leaves the authorization as the domain of the explicit proxy policy.

Previously, if authentication was to be used:

1. The policy would be classified as an identity based policy
2. The policy would be split to add the authentication parameters
3. The authentication method would be selected
4. The user/group would be configured Now:

The user/group is configured in the proxy policy

1. A new authentication rule is added
2. This option refers to the authentication scheme
3. The authentication scheme has the details of the authentication method The new authentication work flow for Transparent Proxy:

Toggle the transparent-http-policy match:

Transparent Proxy Concepts

config firewall profile-protocol-options edit <profile ID> config http set http-policy <enable|disable>

If disabled, everything works like before. If enabled, the authentication is triggered differently.

• http-policy work flow:
• For transparent traffic, if there is a regular firewall policy match, when the Layer 7 check option is enabled, traffic will be redirected to WAD for further processing.
• For redirected traffic, layer 7 policy (HTTP policy) will be used to determine how to do security checks.
• If the last matching factor is down to user ID, then it will trigger a new module to handle the L7 policy user authentication.
• Then propagate learned user information back to the system so that it can be used to match traffic for L4 policy.

New Proxy Type

There is a new subcategory of proxy in the proxy policy called Transparent Web. The old Web Proxy is now referred to as Explicit Web Proxy.

• This is set in the firewall policy l It is available when the HTTP policy is enabled in the profile-protocol options for the firewall policy l This proxy type supports OSI layer 7 address matching.
• This proxy type should include a source address as a parameter l Limitations:
• It can be used for HTTPS traffic, if deep scanning is not used l It only supports SNI address matching, i.e. domain names l It does not support header types of address matching l It only supports SSO authentication methods, no active authentication methods.

IP pools support

Proxies are now supported on outgoing IP pools.

SOCKSv5

SOCKSv5 authentication is now supported for explicit proxies.

To configure:

config authentication rule edit <name of rule> set protocol socks end

Forwarding

Proxies support URL redirect/forwarding. This allows a non-proxy forwarding server to be assigned a rule that will redirect web traffic from one URL to another, such as redirecting traffic destined for youtube.com to restrict.youtube.com.

Concepts

l A new option called “Redirect URL” has been added to the policy l Traffic forwarding by VIP is supported

Support for explicit proxy address objects & groups into IPv4 firewall policies

This would allow the selection of web filter policy, SSL inspection policy, and proxy policy based on source IP + destination (address|explicit proxy object|category|group of any of those). This enables things like “do full SSL interception on www.google.com, but not the rest of the Search Engines category”.

Support application service in the proxy based on HTTP requests.

The application service can be configured using the following CLI commands:

config firewall service custom edit <name of service> set explicit-proxy enable set app-service-type <disable|app-id|app-category> set app-category <application category ID, integer> set application <application ID, integer> end

Transparent Proxy Configuration

To implement the Transparent proxy, go to System > Settings and scroll down to Operations Settings and set the inspection mode to Proxy.

Then go to System > Feature Visibility and enable Explicit Proxy.

Then go to Security Profiles > Proxy Options, edit a proxy options profile and under Web Options enable HTTP Policy Redirect.

Then go to Policy & Objects > IPv4 Policy and create or edit a policy that accepts traffic that you want to apply web authentication to. This can be a general policy that accepts many different types of traffic as long as it also accepts the web traffic that you want to apply web authentication to.

Select a Security Profile and select the Proxy Options profile that you enabled HTTP Policy Redirect for.

Configuration

Then go to Policy & Objects > Proxy Policy create a Transparent Proxy policy to accept the traffic that you want to apply web authentication to. Set the Proxy Type to Transparent Web. The incoming interface, outgoing interface, destination address, and schedule should either match or be a subset of the same options defined in the IPv4 policy. Addresses added to the Source must match or be a subset of the source addresses added to the IPv4 policy. You can also add the users to be authenticated by the transparent policy to the source field.

Select other transparent policy options as required.

Transparent Proxy Configuration

CLI changes due to addition of Transparent Proxy

The adding of Transparent Proxy to the existing proxy types has required some changes, removals, moves and additions to the CLI.

Changes:

config firewall explicit-proxy-policy       config firewall proxy-policy Configuration

config firewall proxy-addrgrp

The FortiGate explicit FTP proxy

You can use the FortiGate explicit FTP proxy to enable explicit FTP proxying on one or more FortiGate interfaces. The explicit web and FTP proxies can be operating at the same time on the same or on different FortiGate interfaces.

In most cases you would configure the explicit FTP proxy for users on a network by enabling the explicit FTP proxy on the FortiGate interface connected to that network. Users on the network would connect to and authenticate with the explicit FTP proxy before connecting to an FTP server. In this case the IP address of the explicit FTP proxy is the IP address of the FortiGate interface on which the explicit FTP proxy is enabled.

Enabling the explicit FTP proxy on an interface connected to the Internet is a security risk because anyone on the Internet who finds the proxy could use it to hide their source address.

If the FortiGate unit is operating in Transparent mode, users would configure their browsers to use a proxy server with the FortiGate unit management IP address.

The FTP proxy receives FTP sessions to be proxied at FortiGate interfaces with the explicit FTP proxy enabled.

The FTP proxy uses FortiGate routing to route sessions through the FortiGate unit to a destination interface. Before a session leaves the exiting interface, the explicit FTP proxy changes the source addresses of the session packets to the IP address of the exiting interface. When the FortiGate unit is operating in Transparent mode the explicit web proxy changes the source addresses to the management IP address.

Example explicit FTP proxy topology

To allow anyone to anonymously log into explicit FTP proxy and connect to any FTP server you can set the explicit FTP proxy default firewall proxy action to accept. When you do this, users can log into the explicit FTP proxy with any username and password.

In most cases you would want to use explicit proxy policies to control explicit FTP proxy traffic and apply security features, access control/authentication, and logging. You can do this by keeping the default explicit FTP proxy firewall policy action to deny and then adding explicit FTP proxy policies. In most cases you would also want users to authenticate with the explicit FTP proxy. By default an anonymous FTP login is required. Usually you would add authentication to explicit FTP proxy policies. Users can then authenticate with the explicit FTP proxy according to users or user groups added to the policies. User groups added to explicit FTP proxy policies can use any authentication method supported by FortiOS including the local user database and RADIUS and other remote servers.

How to use                                 to connect to an FTP server                                   The FortiGate explicit         proxy

If you leave the default firewall policy action set to deny and add explicit FTP proxy policies, all connections to the explicit FTP proxy must match an or else they will be dropped. Sessions that are accepted are processed according to the ftp-proxy security policy settings.

You can also change the explicit FTP proxy default firewall policy action to accept and add explicit FTP proxy policies. If you do this, sessions that match explicit FTP proxy policies are processed according to the policy settings. Connections to the explicit FTP proxy that do not match an explicit FTP proxy policy are allowed and the users can authenticate with the proxy anonymously.

There are some limitations to the security features that can be applied to explicit FTP proxy sessions. See The FortiGate explicit FTP proxy on page 351.

You cannot configure IPsec, SSL VPN, or Traffic shaping for explicit FTP proxy traffic. Explicit FTP proxy policies can only include firewall addresses not assigned to a FortiGate unit interface or with interface set to any. (On the web-based manager you must set the interface to Any. In the CLI you must unset the associatedinterface.)

How to use the explicit FTP proxy to connect to an FTP server

To connect to an FTP server using the explicit FTP proxy, users must run an FTP client and connect to the IP address of a FortiGate interface on which the explicit FTP proxy is enabled. This connection attempt must use the configured explicit FTP proxy port number (default 21).

The explicit FTP proxy is not compatible with using a web browser as an FTP client. To use web browsers as FTP clients configure the explicit web proxy to accept FTP sessions.

The following steps occur when a user starts an FTP client to connect to an FTP server using the explicit FTP proxy. Any RFC-compliant FTP client can be used. This example describes using a command-line FTP client. Some FTP clients may require a custom FTP proxy connection script.

1. The user enters a command on the FTP client to connect to the explicit FTP proxy.

For example, if the IP address of the FortiGate interface on which the explicit FTP proxy is enabled is 10.31.101.100, enter:

ftp 10.31.101.100

2. The explicit FTP proxy responds with a welcome message and requests the user’s FTP proxy user name and password and a username and address of the FTP server to connect to: Connected to 10.31.101.100. 220 Welcome to FortiGate FTP proxy Name (10.31.101.100:user):

You can change the message by editing the FTP Explicit Banner Message replacement message.

3. At the prompt the user enters their FTP proxy username and password and a username and address for the FTP server. The FTP server address can be a domain name or numeric IP address. This information is entered using the following syntax:

<proxy-user>:<proxy-password>:<server-user>@<server-address>

For example, if the proxy username and password are p-name and p-pass and a valid username for the FTP server is s-name and the server’s IP address is ftp.example.com the syntax would be:

p-name:p-pass:s-name@ftp.example.com

How to use the explicit FTP proxy to connect to an        server

4. The FTP proxy forwards the connection request, including the user name, to the FTP server.
5. If the user name is valid for the FTP server it responds with a password request prompt.
6. The FTP proxy relays the password request to the FTP client.
7. The user enters the FTP server password and the client sends the password to the FTP proxy.
8. The FTP proxy relays the password to the FTP server.
9. The FTP server sends a login successful message to the FTP proxy.
10. The FTP proxy relays the login successful message to the FTP client.
11. The FTP client starts the FTP session.

All commands entered by the client are relayed by the proxy to the server. Replies from the server are relayed back to the FTP client.

Explicit FTP proxy session

From a simple command line FTP client connecting to an the previous sequence could appear as follows:

Security profiles, threat weight, device identification, and the explicit FTP proxy             The FortiGate explicit         proxy

ftp 10.31.101.100 21 Connected to 10.31.101.100.

220 Welcome to FortiGate FTP proxy

Name (10.31.101.100:user): p-name:p-pass:s-name@ftp.example.com 331 Please specify the password. Password: s-pass 230 Login successful.

Remote system type is UNIX

Using binary mode to transfer files. ftp>

Security profiles, threat weight, device identification, and the explicit FTP proxy

You can apply antivirus, data leak prevention (DLP), and SSL/SSH inspection to explicit FTP proxy sessions. Security profiles are applied by selecting them in an explicit FTP proxy policy or an authentication rule in an FTP proxy security policy.

Traffic accepted by explicit FTP proxy policies contributes to threat weight data.

The explicit FTP proxy is not compatible with device identification.

Explicit FTP proxy options and SSL/SSH inspection

Since the traffic accepted by the explicit FTP proxy is known to be FTP and since the ports are already known by the proxy, the explicit FTP proxy does not use the FTP port proxy options settings.

When adding UTM features to an FTP proxy security policy, you must select a proxy options profile. In most cases you can select the default proxy options profile. You could also create a custom proxy options profile.

The explicit FTP proxy supports the following proxy options:

l Block Oversized File and oversized file limit

The explicit FTP proxy does not support the following protocol options: l Client comforting

Explicit FTP proxy sessions and antivirus

For explicit FTP proxy sessions, the FortiGate unit applies antivirus scanning to FTP file GET and PUT requests. The FortiGate unit starts virus scanning a file in an FTP session when it receives a file in the body of an FTP request.

Flow-based virus scanning is not available for explicit FTP proxy sessions. Even if the FortiGate unit is configured to use flow-based antivirus, explicit FTP proxy sessions use the regular virus database.

Explicit FTP proxy sessions and user limits

FTP clients do not open large numbers of sessions with the explicit FTP proxy. Most sessions stay open for a short while depending on how long a user is connected to an FTP server and how large the file uploads or explicit FTP proxy        Explicit FTP proxy sessions and user limits

downloads are. So unless you have large numbers of FTP users, the explicit FTP proxy should not be adding large numbers of sessions to the session table.

Explicit FTP proxy sessions and user limits are combined with explicit web proxy session and user limits. For information about explicit proxy session and user limits, see Explicit proxy sessions and user limits on page 1.

FTP Proxy Configuration

General explicit FTP proxy configuration steps

You can use the following general steps to configure the explicit FTP proxy.

To enable the explicit FTP proxy – web-based manager:

1. Go to Network > Explicit Proxy > Explicit FTP Proxy Options. Select Enable Explicit FTP Proxy to turn on the explicit FTP proxy.
2. Select Apply.

The Default Firewall Policy Action is set to Deny and requires you to add a explicit FTP proxy policy to allow access to the explicit FTP proxy. This configuration is recommended and is a best practice because you can use policies to control access to the explicit FTP proxy and also apply security features and authentication.

3. Go to Network > Interfaces and select one or more interfaces for which to enable the explicit web proxy. Edit the interface and select Enable Explicit FTP Proxy.

Enabling the explicit FTP proxy on an interface connected to the Internet is a security risk because anyone on the Internet who finds the proxy could use it to hide their source address. If you enable the proxy on such an interface make sure authentication is required to use the proxy.

4. Go to Policy & Objects > Proxy Policyand select Create New and set the Explicit Proxy Type to

You can add multiple explicit FTP proxy policies.

5. Configure the policy as required to accept the traffic that you want to be processed by the explicit FTP proxy.

The source address of the policy should match client source IP addresses. The firewall address selected as the source address cannot be assigned to a FortiGate interface. The Interface field of the firewall address must be blank or it must be set to Any.

The destination address of the policy should match the IP addresses of FTP servers that clients are connecting to. The destination address could be all to allow connections to any FTP server.

If Default Firewall Policy Action is set to Deny, traffic sent to the explicit FTP proxy that is not accepted by an explicit FTP proxy policy is dropped. If Default Firewall Policy Action is set to Allow then all FTP proxy sessions that don’t match a policy are allowed.

For example the following explicit FTP proxy policy allows users on an internal network to access FTP servers on the Internet through the wan1 interface of a FortiGate unit.

FTP Proxy Configuration                                                                       General explicit FTP proxy configuration steps

The following explicit FTP proxy policy requires users on an internal network to authenticate with the FortiGate unit before accessing FTP servers on the Internet through the wan1 interface.

6. Select Create New to add an Authentication Rule and configure the rule as follows:

7. Add security profiles as required and select OK.
8. You can add multiple authentication rules to apply different authentication for different user groups and users and also apply different security profiles and logging settings for different users.
9. Select OK.

To enable the explicit FTP proxy – CLI:

1. Enter the following command to turn on the explicit FTP proxy. This command also changes the explicit FTP proxy port to 2121.

config ftp-proxy explicit set status enable set incoming-port 2121

end

The default explicit FTP proxy configuration has sec-default-action set to deny and requires you to add a security policy to allow access to the explicit FTP proxy.

2. Enter the following command to enable the explicit FTP proxy for the internal interface. config system interface edit internal set explicit-ftp-proxy enable

end end

Restricting the IP address of the explicit FTP proxy                                                                FTP Proxy Configuration

3. Use the following command to add a firewall address that matches the source address of users who connect to the explicit FTP proxy.

config firewall address edit Internal_subnet set type iprange set start-ip 10.31.101.1 set end-ip 10.31.101.255

end

The source address for a ftp-proxy security policy cannot be assigned to a FortiGate unit interface.

4. Use the following command to add an explicit FTP proxy policy that allows all users on the internal subnet to use the explicit FTP proxy for connections through the wan1 interface to the Internet.

config firewall proxy-policy edit 0 set proxy ftp set dstintf wan1 set scraddr Internal_subnet

set dstaddr all set action accept set schedule always

end

5. Use the following command to add an explicit FTP proxy policy that allows authenticated users on the internal subnet to use the explicit FTP proxy for connections through the wan1 interface to the Internet.

config firewall proxy-policy edit 0 set proxy ftp set dstintf wan1 set scraddr Internal_subnet set dstaddr Fortinet-web-sites set action accept set schedule always set groups <User group>

end

end

Restricting the IP address of the explicit FTP proxy

You can use the following command to restrict access to the explicit FTP proxy using only one IP address. The IP address that you specify must be the IP address of an interface that the explicit FTP proxy is enabled on. You might want to use this option if the explicit FTP proxy is enabled on an interface with multiple IP addresses.

For example, to require uses to connect to the IP address 10.31.101.100 to connect to the explicit FTP proxy:

config ftp-proxy explicit set incoming-ip 10.31.101.100 end

FTP Proxy Configuration                                         Restricting the outgoing source IP address of the explicit FTP proxy

Restricting the outgoing source IP address of the explicit FTP proxy

You can use the following command to restrict the source address of outgoing FTP proxy packets to a single IP address. The IP address that you specify must be the IP address of an interface that the explicit FTP proxy is enabled on. You might want to use this option if the explicit FTP proxy is enabled on an interface with multiple IP addresses.

For example, to restrict the outgoing packet source address to 172.20.120.100:

config ftp-proxy explicit set outgoing-ip 172.20.120.100

end

Example users on an internal network connecting to FTP servers on the Internet through the explicit FTP with RADIUS authentication and virus scanning

This example describes how to configure the explicit FTP proxy for the example network shown below. In this example, users on the internal network connect to the explicit FTP proxy through the Internal interface with IP address 10.31.101.100. The explicit web proxy is configured to use port 2121 so to connect to an FTP server on the Internet users must first connect to the explicit FTP proxy using IP address 10.31.101.100 and port 2121.

Example explicit FTP proxy network topology

In this example, explicit FTP proxy users must authenticate with a RADIUS server before getting access to the proxy. To apply authentication, the security policy that accepts explicit FTP proxy traffic includes an identity based policy that applies per session authentication to explicit FTP proxy users and includes a user group with the RADIUS server in it. The identity based policy also applies UTM virus scanning and DLP.

General configuration steps

This section breaks down the configuration for this example into smaller procedures. For best results, follow the procedures in the order given:

1. Enable the explicit FTP proxy and change the FTP port to 2121.
2. Enable the explicit FTP proxy on the internal interface.

Example users on an internal network connecting to FTP servers on the Internet through      explicit               FTP Proxy

FTP with RADIUS authentication and virus scanning                                                                              Configuration

3. Add a RADIUS server and user group for the explicit FTP proxy.
4. Add a user identity security policy for the explicit FTP proxy.
5. Enable antivirus and DLP features for the identity-based policy.

Configuring the explicit FTP proxy – web-based manager

Use the following steps to configure the explicit FTP proxy from FortiGate web-based manager.

To enable and configure the explicit FTP proxy

1. Go to Network > Explicit Proxy > Explicit FTP Proxy Options and change the following settings:

2. Select Apply.

To enable the explicit FTP proxy on the Internal interface

1. Go to Network > Interfaces, edit the Internal interface and select Enable Explicit FTP Proxy.

To add a RADIUS server and user group for the explicit FTP proxy

1. Go to User & Device > RADIUS Servers.
2. Select Create New to add a new RADIUS server:

3. Go to User > User > User Groups and select Create New.

4. Select OK.

FTP Proxy               Example users on an internal network connecting to FTP servers on      Internet through the explicit

Configuration                                                                              FTP with RADIUS authentication and virus scanning

To add a security policy for the explicit FTP proxy

1. Go to Policy & Objects > Addresses and select Create New.
2. Add a firewall address for the internal network:

3. Go to Policy & Objects > Proxy Policyand select Create New.
4. Configure the explicit FTP proxy security policy.

5. Under Configure Authentication Rules select Create New to add an authentication rule:

6. Turn on Antivirus and Web Filter and select the default profiles for both.
7. Select the default proxy options profile.
8. Select OK.
9. Make sure Enable IP Based Authentication is not selected and DefaultAuthentication Method is set to Basic.
10. Select OK.

Configuring the explicit FTP proxy – CLI

Use the following steps to configure the example explicit web proxy configuration from the CLI.

To enable and configure the explicit FTP proxy

1. Enter the following command to enable the explicit FTP proxy and set the TCP port that proxy accepts FTP connections on to 2121.

config ftp-proxy explicit set status enable set incoming-port 2121

Example users on an internal network connecting to FTP servers on the Internet through      explicit               FTP Proxy

FTP with RADIUS authentication and virus scanning                                                                              Configuration

set sec-default-action deny

end

To enable the explicit FTP proxy on the Internal interface

1. Enter the following command to enable the explicit FTP proxy on the internal interface. config system interface edit internal set explicit-ftp-proxy enable

end

To add a RADIUS server and user group for the explicit FTP proxy

1. Enter the following command to add a RADIUS server:

config user radius edit RADIUS_1 set server 10.31.101.200 set secret RADIUS_server_secret

end

2. Enter the following command to add a user group for the RADIUS server.

config user group edit Explicit_proxy_user_group set group-type firewall set member RADIUS_1

end

To add a security policy for the explicit FTP proxy

1. Enter the following command to add a firewall address for the internal subnet: config firewall address edit Internal_subnet set type iprange set start-ip 10.31.101.1 set end-ip 10.31.101.255

end

2. Enter the following command to add the explicit FTP proxy security policy: config firewall proxy-policy edit 0 set proxy ftp set dstintf wan1 set srcaddr Internal_subnet

set dstaddr all set action accept set identity-based enable set ipbased disable set active-auth-method basic set groups <User group> end

FTP Proxy               Example users on an internal network connecting to FTP servers on      Internet through the explicit

Configuration                                                                              FTP with RADIUS authentication and virus scanning

Testing and troubleshooting the configuration

You can use the following steps to verify that the explicit FTP proxy configuration is working as expected. These steps use a command line FTP client.

To test the explicit web proxy configuration

1. From a system on the internal network start an FTP client and enter the following command to connect to the FTP proxy:

ftp 10.31.101.100

The explicit FTP proxy should respond with a message similar to the following:

Connected to 10.31.101.100. 220 Welcome to Floodgate FTP proxy Name (10.31.101.100:user):

2. At the prompt enter a valid username and password for the RADIUS server followed by a user name for an FTP server on the Internet and the address of the FTP server. For example, if a valid username and password on the RADIUS server is ex_name and ex_pass and you attempt to connect to an FTP server at ftp.example.com with user name s_name, enter the following at the prompt:

Name (10.31.101.100:user):ex_name:ex_pass:s_name@ftp.example.com

3. You should be prompted for the password for the account on the FTP server.
4. Enter the password and you should be able to connect to the FTP server.
5. Attempt to explore the FTP server file system and download or upload files.
6. To test UTM functionality, attempt to upload or download an ECAR test file. Or upload or download a text file containing text that would be matched by the DLP sensor.

For eicar test files, go to http://eicar.org.

get test {wad | wccpd} <test_level>

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>

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}

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

SSL-secured-tunnel=no auth-grp= bytes_in=1228 bytes_out=1264

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

peer name=Web_servers id=8 ip=172.20.120.141

SSL-secured-tunnel=no auth-grp= bytes_in=1228 bytes_out=1264

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

peer name=Web_servers id=5 ip=172.20.120.141

SSL-secured-tunnel=no auth-grp= bytes_in=1228 bytes_out=1264

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

peer name=Web_servers id=4 ip=172.20.120.141

SSL-secured-tunnel=no auth-grp= bytes_in=1228 bytes_out=1264

diagnose wad

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

peer name=Web_servers id=1 ip=172.20.120.141

SSL-secured-tunnel=no auth-grp= bytes_in=1228 bytes_out=1264

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

peer name=Web_servers id=2 ip=172.20.120.141

SSL-secured-tunnel=no auth-grp= bytes_in=1228 bytes_out=1264

Tunnels total=10 manual=10 auto=0

Example diagnose wad webcache list

This following command displays the web caching stats for the last 10 minutes of activity. The information displayed is divided into 20 slots and each slot contains stats for 30 seconds:

20 * 30 seconds = 600 seconds = 10 minutes

diagnose wad webcache list 10min web cache history vd=0 period=last 10min

The first 20 slots are for HTTP requests in the last 10 minutes. Each slot of stats has four numbers, which is the total number of HTTP requests, the number of cacheable HTTP requests, the number of HTTP requests that are processed by the web cache (hits), and the number of HTTP requests that are processed without checking the web cache (bypass). There are many reasons that a HTTP request may bypass web cache.

wacs

The following slots are for video requests in the last 10 minutes. Each slot has two numbers for each 30 seconds: total number of video requests, and the number of video requests that are processing using cached data.

video total video hit

———— ————-

0            0

0            0

0            0

0            0

0            0

0            0

0            0

0            0

0            0

0            0

0            0

0            0

0            0

0            0

0            0

The following 20 slots are for traffic details in last 10 minutes. Each slot has four numbers for 30 seconds each.

— LAN —                — WAN —

bytes_in     bytes_out     bytes_in     bytes_out

———— ————- ———— ————-

34360       150261        141086       32347

105408       861863        858501       100670

128359       1365919       1411849     127341

60103        602813        818075      59967

105867       1213192       1463736      97489

154961       1434784       1344911      158667

73967        370275        369847       70626

129327       602834        592399      123676

115719       663446        799445      111262

58151       724993        631721       59989

175681      2092925       1092556      166212

37805        33042        41528        37779

183686       1255118       1114646     172371

106125       904178        807152       81520

66147        473983       543507       66782

170451      1289530      1201639       165540

69196       544559       865370       68446

134142      579605        821430      132113

96895       668037       730633      89872

59576       248734     164002 59448 diagnose wacs

Display diagnostic information for the web cache database daemon (wacs).

diagnose wacs clear diagnose wacs recents diagnose wacs restart diagnose wacs stats

diagnose wadbd

diagnose wadbd

Display diagnostic information for the WAN optimization database daemon (waddb).

diagnose wadbd {check | clear | recents | restart | stats}

diagnose debug application {wad | wccpd} [<debug_level>]

View or set the debug level for displaying WAN optimization and web cache-related daemon debug messages. Include a <debug_level> to change the debug level. Leave the <debug_level> out to display the current debug level. Default debug level is 0.

diagnose debug application wad [<debug_level>] diagnose debug application wccpd [<debug_level>]

test application wad 2200

diagnose test application wad 2200

The debug level 2200 switches the debug to explicit proxy mode. You have to enter this debug level first. After that you have to type the command again with a different debug level to check the different explicit proxy statistics. To list what each debug level shows, follow these steps in any FortiGate device:

1. Enable explicit proxy globally and in one interface, to start the wad process. If the wad process is not running, you cannot list the options.
2. Once the wad process starts, type:

diagnose test application wad 2200 diagnose test application wad ///// Do not type any debug level value to list all the options.

This is the output you will get:

# diagnose test application wad 2200

Set diagnosis process: type=wanopt index=0 pid=114 # diagnose test application wad WAD process 114 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

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

20: display all listeners 21: display TCP port info

22: display SSL stats

23: flush SSL stats

24: display SSL mem stats

70: display av memory usage

71xxxx: set xxxxMiB maximum AV memory (0: set back to default)

72: toggle av memory protection

73: toggle AV conserve mode (for debug purpose)

90: set to test disk failure

91: unset to test disk failure

92: trigger a disk failure event

100: display explicit proxy settings

101: display firewall policies

102: display security profile mapping for regular firewall policy

diagnose test application wad 2200

103: display Web proxy forwarding server and group

104: display DNS stats

105: display proxy redirection scan stats

106: list all used fqdns

107: list all firewall address

110: display current web proxy users

111: flush current web proxy users

112: display current web proxy user summary

113: display WAD fsso state

114: display HTTP digest stats

115: display URL patterns list of cache exemption or forward server

116: toggle dumping URL when daemon crashes

120: display Web Cache stats

121: flush Web Cache stats

122: flush idle Web cache objects

123: display web cache cache sessions

130: display ftpproxy stats

131: clear ftpproxy stats

132: list all current ftpproxy sessions

133: display all catched webfilter profiles

200: display WANopt profiles

201: display all peers

202: display video cache rules (patterns)

203: display all ssl servers

210: toggle disk-based byte-cache

211: toggle memory-based byte-cache

212: toggle cifs read-ahead

221: display tunnel protocol stats

222: flush tunnel protocol stats

223: display http protocol stats

224: flush http protocol stats

225: display cifs protocol stats

226: flush cifs protocol stats

227: display ftp protocol stats

228: flush ftp protocol stats

229: display mapi protocol stats

230: flush mapi protocol stats

231: display tcp protocol stats

232: flush tcp protocol stats

233: display all protocols stats

234: flush all protocols stats

240: display WAD tunnel stats

241: display tunnel compressor state

242: flush tunnel compressor stats

243: display Byte Cache DB state

244: flush Byte Cache DB stats

245: display Web Cache DB state

246: flush Web Cache DB stats

247: display cache state

248: flush cache stats

249: display memory cache state

250: flush memory cache stats

261yxxx: set xxx concurrent Web Cache session for object storage y

262yxxx: set xxxK(32K, 64K,…) unconfirmed write/read size per Web Cache object for object storage y

263yxxxx: set xxxxK maximum ouput buffer size for object storage y

test application wad 2200

264yxx: set lookup lowmark (only if more to define busy status) to be xx for object storage y

265yxxx: set xxxK maximum ouput buffer size for byte storage y

266yxxx: set number of buffered add requests to be xxx for byte storage y

267yxxxx: set number of buffered query requests to be xxxx for byte storage y

268yxxxxx: set number of concurrent query requests to be xxxxx for byte storage y

Only 6 days before I arrive in Vegas for Accelerate 18. Looking forward to catching up with some old friends and meeting some new ones at this years partner conference. I will be posting videos and misc other items from the conference so keep an eye out.

Purpose

FortiView is a comprehensive monitoring system for your network that integrates real-time and historical data into a single view on your FortiGate. It can log and monitor threats to networks, filter data on multiple levels, keep track of administrative activity, and more.

FortiView allows you to use multiple filters within the consoles, enabling you to narrow your view to a specific time

(up to 24 hours in the past), by user ID or local IP address, by application, and many more. For more on FortiView’s filtering options, see Filtering options on page 37

FortiView can be used to investigate traffic activity, such as user uploads/downloads or videos watched on YouTube, on a network-wide, user group, and individual-user level, with information relayed in both text and visual format. FortiView makes it easy to get an actionable picture of your network’s internet activity.

The degree to which information can be logged will depend on which FortiGate unit you have. For more information, see Enabling FortiView on page 9.

Introduction

This document provides the following information for FortiGate-7000 v5.4.5 build 6481:

l Supported Models l What’s New in FortiGate-7000 v5.4.5 build 6481 l Special Notices l Upgrade Information l Product Integration and Support l Resolved Issues l Known Issues

Supported Models

FortiGate-7000 v5.4.5 build 6481 supports all ForGate-7030E, 7040E, and 7060E models and configurations.

What’s New in FortiGate-7000 v5.4.5 build 6481

The following new features have been added to FortiGate-7000 v5.4.5 build 6481 firmware:

M1 and M2 interfaces can use different VLANs for heartbeat traffic (408386)

The M1 and M2 interfaces can be configured to use different VLANs for HA heartbeat traffic.

The following command now configures the VLAN used by the M1 interface (default 999):

config system ha set hbdev-vlan-id 999

end

The following new command configures the VLAN used by the M2 interface (default 1999):

config system ha set hbdev-second-vlan-id 1999

end

GTP load balancing

GTP load balancing is supported for FortiGate-7000 configurations licensed for FortiOS Carrier. You can use the following command to enable GTP load balancing. This command is only available after you have licensed the FortiGate-7000 for FortiOS Carrier.

config load-balance setting set gtp-load-balance enable end

What’s New in FortiGate-7000 v5.4.5 build 6481                                                                                    Introduction

FSSO user authentication is synchronized

FSSO user authentication is synchronized to all FIM and FPM modules. FSSO users are no longer required to reauthenticate when sessions are processed by a different FIM or FPM module.

HA Link failure threshold changes (422264 )

The link failure threshold is now determined based on the all FIM modules in a chassis. This means that the chassis with the fewest active links will become the backup chassis.

FortiGate-7000s running FortiOS v5.4.5 can be configured as dialup IPsec VPN servers

The following shows how to setup a dialup IPsec VPN configuration where the FortiGate-7000 running v5.4.5 acts as a dialup IPsec VPN server.

Configure the phase1, set type to dynamic.

config vpn ipsec phase1-interface edit dialup-server set type dynamic set interface “v0020” set peertype any set psksecret < password>

end

Configure the phase 2, to support dialup IPsec VPN, set the destination subnet to 0.0.0.0 0.0.0.0.

config vpn ipsec phase2-interface edit dialup-server set phase1name dialup-server set src-subnet 4.2.0.0 255.255.0.0 set dst-subnet 0.0.0.0 0.0.0.0

end

To configure the remote FortiGate as a dialup IPsec VPN client

The dialup IPsec VPN client should advertise its local subnet(s) using the phase 2 src-subnet option.

Introduction                                                                                    What’s New in FortiGate-7000 v5.4.5 build 6481

config vpn ipsec phase1-interface edit “to-fgt7k” set interface “v0020” set peertype any set remote-gw 1.2.0.1 set psksecret <password>

end

config vpn ipsec phase2-interface edit “to-fgt7k” set phase1name “to-fgt7k” set src-subnet 4.2.6.0 255.255.255.0 set dst-subnet 4.2.0.0 255.255.0.0

next edit “to-fgt7k-2” set phase1name “to-fgt7k” set src-subnet 4.2.7.0 255.255.255.0 set dst-subnet 4.2.0.0 255.255.0.0 end

Special Notices

This section highlights some of the operational changes that administrators should be aware of for FortiGate7000 5.4.5 build 6481.

Recommended configuration for traffic that cannot be load balanced

The following flow rules are recommended to handle common forms of traffic that cannot be load balanced. These flow rules send GPRS (port 2123), SSL VPN, IPv4 and IPv6 IPsec VPN, ICMP and ICMPv6 traffic to the primary (or master) FPM.

The CLI syntax below just shows the configuration changes. All other options are set to their defaults. For example, the flow rule option that controls the FPM slot that sessions are sent to is forward-slot and in all cases below forward-slot is set to its default setting of master. This setting sends matching sessions to the primary (or master) FPM.

config load-balance flow-rule edit 20 set status enable set ether-type ipv4 set protocol udp set dst-l4port 2123-2123

next edit 21 set status enable set ether-type ip set protocol tcp set dst-l4port 10443-10443 set comment “ssl vpn to the primary FPM”

next edit 22 set status enable set ether-type ipv4 set protocol udp set src-l4port 500-500 set dst-l4port 500-500 set comment “ipv4 ike”

next edit 23 set status enable set ether-type ipv4 set protocol udp set src-l4port 4500-4500 set comment “ipv4 ike-natt src”

next edit 24 set status enable set ether-type ipv4 set protocol udp set dst-l4port 4500-4500 set comment “ipv4 ike-natt dst”

Special Notices                                                   Recommended configuration for traffic that cannot be load balanced

next edit 25 set status enable set ether-type ipv4 set protocol esp set comment “ipv4 esp”

next edit 26 set status enable set ether-type ipv6 set protocol udp set src-l4port 500-500 set dst-l4port 500-500 set comment “ipv6 ike”

next edit 27 set status enable set ether-type ipv6 set protocol udp set src-l4port 4500-4500 set comment “ipv6 ike-natt src”

next edit 28 set status enable set ether-type ipv6 set protocol udp set dst-l4port 4500-4500 set comment “ipv6 ike-natt dst”

next edit 29 set status enable set ether-type ipv6 set protocol esp set comment “ipv6 esp”

next edit 30 set ether-type ipv4 set protocol icmp set comment “icmp”

next edit 31 set status enable set ether-type ipv6 set protocol icmpv6 set comment “icmpv6”

next edit 32 set ether-type ipv6 set protocol 41 end

Upgrade Information

FortiGate-7000 v5.4.5 build 6481supports upgrading from FortiGate-7000 v5.4.3 build 6382.

All of the modules in your FortiGate-7000 chassis run the same firmware image. You can upgrade the firmware by using the management IP address to log into the primary interface module GUI or CLI and perform a firmware upgrade just as you would for any FortiGate product. During the upgrade process, the firmware of all of the modules in the chassis upgrades in one step. Firmware upgrades should be done during a quiet time because traffic is briefly interrupted during the upgrade process.

Upgrading an HA configuration

Even if uninterruptable-upgrade is enabled, upgrading a FortiGate-7000 HA configuration will cause a minor traffic disruption. You should upgrade HA cluster firmware when traffic is low or during a maintenance period.

IPsec VPN issues when upgrading from v5.4.3 to v5.4.5

If your FortiGate-7000 configuration includes IPsec VPNs you should enhance your IPsec VPN Phase 2 configurations as described in this section. If your FortiGate-7000 does not include IPsec VPNs you can proceed with a normal firmware upgrade.

Because the FortiGate-7000 only allows 16-bit to 32-bit routes for remote subnets, you must add one or more destination subnets to your IPsec VPN phase 2 configuration for FortiGate-7000 v5.4.5 using the following command:

config vpn ipsec phase2-interface edit “to_fgt2″So set phase1name <name> set src-subnet <IP> <netmask> set dst-subnet <IP> <netmask>

end Where

src-subnet is the subnet protected by the FortiGate that you are configuring and from which users connect to the destination subnet. Configuring the source subnet is optional but recommended.

dst-subnet is the destination subnet behind the remote IPsec VPN endpoint. Configuring the destination subnet is required.

You can add the source and destination subnets either before or after upgrading to v5.4.5 as these settings are compatible with both v5.4.3 and v5.4.5. However, if you make these changes after upgrading, your IPsec VPNs may not work correctly until these configuration changes are made.

Upgrade Information                                                             IPsec VPN issues when upgrading from v5.4.3 to v5.4.5

Adding source and destination subnets to IPsec VPN phase 2 configurations

In a simple configuration such as the one below with an IPsec VPN between two remote subnets you can just add the subnets to the phase 2 configuration.

Enter the following command to add the source and destination subnets to the FortiGate-7000 IPsec VPN Phase 2 configuration.

config vpn ipsec phase2-interface edit “to_fgt2″So set phase1name “to_fgt2” set src-subnet 172.16.1.0 255.255.255.0 set dst-subnet 172.16.2.0 255.255.255.0

end

In a more complex configuration, such as the one below with a total of 5 subnets you still need to add all of the subnets to the Phase 2 configuration. In this case you can create a firewall address for each subnet and the addresses to address groups and add the address groups to the Phase 2 configuration.

Enter the following commands to create firewall addresses for each subnet.

config firewall address edit “local_subnet_1” set subnet 4.2.1.0 255.255.255.0

next

edit “local_subnet_2” set subnet 4.2.2.0 255.255.255.0

IPsec VPN issues when upgrading from v5.4.3 to v5.4.5                                                             Upgrade Information

next edit “remote_subnet_3”

set subnet 4.2.3.0 255.255.255.0

next edit “remote_subnet_4”

set subnet 4.2.4.0 255.255.255.0

next edit “remote_subnet_5”

set subnet 4.2.5.0 255.255.255.0

end

And then put the five firewall addresses into two firewall address groups.

config firewall addrgrp edit “local_group” set member “local_subnet_1” “local_subnet_2”

next

edit “remote_group” set member “remote_subnet_3” “remote_subnet_4” “remote_subnet_5”

end

Now, use the firewall address groups in the Phase 2 configuration:

config vpn ipsec phase2-interface edit “to-fgt2” set phase1name “to-fgt2” set src-addr-type name set dst-addr-type name set src-name “local_group” set dst-name “remote_group” end

Product Integration and Support

See the Product Integration and Support section of the FortiOS 5.4.5 release notes for product integration and support information for FortiGate-7000 v5.4.5 build 6481.

Also please note the following exceptions for FortiGate-7000 v5.4.5 build 6481:

Minimum recommended FortiManager firmware version : 5.6.1

Minimum recommended FortiAnalyzer firmware version : 5.4.4

FortiGate-7000 v5.4.5 special features and limitations

FortiGate-7000 v5.4.5 has specific behaviors which may differ from FortiOS features. For more information, see the “Special features and limitations for FortiGate-7000 v5.4.5” section of the most recent version of the FortiGate-7000 Handbook chapter available at http://docs.fortinet.com/d/fortigate-7000.

Resolved Issues

The following issues have been fixed in FortiGate-7000 v5.4.5 build 6481. For inquires about a particular bug, please contact Customer Service & Support.

Resolved Issues

Known Issues

The following issues have been identified in FortiGate-7000 v5.4.5 build 6481. For inquires about a particular bug, please contact Customer Service & Support.

Introduction

This document describes what you need to know to get started using a FortiGate-7000 product. Also included are details about CLI commands that are specific to FortiGate-7000 products.

This FortiOS Handbook chapter contains the following sections:

FortiGate-7000 overview provides a quick overview of FortiGate-7000 components.

Getting started with FortiGate-7000 describes how to get started with managing and configuring your FortiGate7000 product.

FortiGate-7000 Load balancing commands describes FortiGate-7000 load balancing CLI commands.

What’s new in for FortiGate-7000 v5.4.5

The following new features have been added to FortiGate-7000 v5.4.5.

M1 and M2 interfaces can use different VLANs for heartbeat traffic (408386)

The M1 and M2 interfaces can be configured to use different VLANs for HA heartbeat traffic.

The following command now configures the VLAN used by the M1 interface (default 999):

config system ha set hbdev-vlan-id 999

end

The following new command configures the VLAN used by the M2 interface (default 1999):

config system ha set hbdev-second-vlan-id 1999

end

GTP load balancing

GTP load balancing is supported for FortiGate-7000 configurations licensed for FortiOS Carrier. You can use the following command to enable GTP load balancing. This command is only available after you have licensed the FortiGate-7000 for FortiOS Carrier.

config load-balance setting set gtp-load-balance enable

end

FSSO user authentication is synchronized

FSSO user authentication is synchronized to all FIM and FPM modules. FSSO users are no longer required to reauthenticate when sessions are processed by a different FIM or FPM module.

What’s new in for FortiGate-7000 v5.4.5                                                                                                Introduction

HA Link failure threshold changes (422264 )

The link failure threshold is now determined based on the all FIM modules in a chassis. This means that the chassis with the fewest active links will become the backup chassis.

FortiGate-7000s running FortiOS v5.4.5 can be configured as dialup IPsec VPN servers

The following shows how to setup a dialup IPsec VPN configuration where the FortiGate-7000 running v5.4.5 acts as a dialup IPsec VPN server.

Configure the phase1, set type to dynamic.

config vpn ipsec phase1-interface edit dialup-server set type dynamic set interface “v0020” set peertype any set psksecret < password>

end

Configure the phase 2, to support dialup IPsec VPN, set the destination subnet to 0.0.0.0 0.0.0.0.

config vpn ipsec phase2-interface edit dialup-server set phase1name dialup-server set src-subnet 4.2.0.0 255.255.0.0 set dst-subnet 0.0.0.0 0.0.0.0

end

To configure the remote FortiGate as a dialup IPsec VPN client

The dialup IPsec VPN client should advertise its local subnet(s) using the phase 2 src-subnet option.

If there are multiple local subnets create a phase 2 for each one. Each phase 2 only advertises one local subnet to the dialup IPsec VPN server. If more than one local subnet is added to the phase 2, only the first one is advertised to the server.

Dialup client configuration:

config vpn ipsec phase1-interface

Introduction                                                                                                What’s new in for FortiGate-7000 v5.4.5

edit “to-fgt7k” set interface “v0020” set peertype any set remote-gw 1.2.0.1 set psksecret <password>

end

config vpn ipsec phase2-interface edit “to-fgt7k” set phase1name “to-fgt7k” set src-subnet 4.2.6.0 255.255.255.0 set dst-subnet 4.2.0.0 255.255.0.0

next edit “to-fgt7k-2” set phase1name “to-fgt7k” set src-subnet 4.2.7.0 255.255.255.0 set dst-subnet 4.2.0.0 255.255.0.0 end

Licenses, Device Registration, and Support                                                                         FortiGate-7000 overview

FortiGate-7000 overview

A FortiGate-7000 product consists of a FortiGate-7000 series chassis (for example, the FortiGate-7040E) with FortiGate-7000 modules installed in the chassis slots. A FortiGate-7040E chassis comes with two interface modules (FIM) to be installed in slots 1 and 2 to provide network connections and session-aware load balancing to two processor modules (FPM) to be installed in slots 3 and 4.

FortiGate-7000 products are sold and licensed as packages that include the chassis as well as the modules to be included in the chassis. When you receive your FortiGate-7000 series product the chassis has to be installed in a rack and the modules installed in the chassis. Interface modules always go in slots 1 and 2 and processor modules in slots 3 and up.

If your FortiGate-7000 product includes two different interfaces modules, for optimal configuration you should install the module with the lower model number in slot 1 and the module with the higher model number in slot 2. For example, if your chassis includes a FIM-7901E and a FIM-7904E, install the FIM-7901E in chassis slot 1 and the FIM-7904E in chassis slot 2. This applies to any combination of two different interface modules.

As an administrator, when you browse to the FortiGate-7000 management IP address you log into the interface module in slot 1 (the primary or master interface module or FIM) to view the status of the FortiGate-7000 and make configuration changes. The FortiOS firmware running on each module has the same configuration and when you make configuration changes to the primary interface module, the configuration changes are synchronized to all modules.

The same FortiOS firmware build runs on each module in the chassis. You can upgrade FortiGate-7000 firmware by logging into the primary interface module and performing a firmware upgrade as you would for any FortiGate. During the upgrade process the firmware of all of the modules in the chassis upgrades in one step. Firmware upgrades should be done during a quiet time because traffic will briefly be interrupted during the upgrade process.

Licenses, Device Registration, and Support

A FortiGate-7000 product is made up of a FortiGate-7000 series chassis, one or two FIM interface modules and two to four FPM processor modules. The entire package is licensed and configured as a single product under the FortiGate-7000 chassis serial number. When you receive a new FortiGate-7000 product you register it on https://support.fortinet.com using the chassis serial number. Use the chassis serial number when requesting support from Fortinet for the product.

All Fortinet licensing, including FortiCare Support, IPS, AntiVirus, Web Filtering, Mobile Malware, FortiClient, FortiCloud, and additional virtual domains (VDOM) is for the entire FortiGate-7000 product and not for individual components.

If an individual component, such as a single interface or processor fails you can RMA and replace just that component.

FortiGate-7060E

The FortiGate-7060E is a 8U 19-inch rackmount 6-slot chassis with a 80Gbps fabric and 1Gbps base backplane designed by Fortinet. The fabric backplane provides network data communication and the base backplane provides management and synch communication among the chassis slots.

FortiGate-7060E front panel

The chassis is managed by two redundant management modules. Each module includes an Ethernet connection as well as two switchable console ports that provide console connections to the modules in the chassis slots. The active management module controls chassis cooling and power management and provides an interface for managing the modules installed in the chassis.

FortiGate-7060E front panel, (example module configuration)

schematic

Power is provided to the chassis using four hot swappable 3+1 redundant 100-240 VAC, 50-60 Hz power supply units (PSUs). You can also optionally add up to six PSUs to provide 3+3 redundancy. The FortiGate-7060E can also be equipped with DC PSUs allowing you to connect the chassis to -48V DC power

The standard configuration of the FortiGate-7060E includes two FIM (interface) modules in chassis slots 1 and 2 and up to four FPM (processing) modules in chassis slots 3 to 6.

FortiGate-7060E schematic

The FortiGate-7060E chassis schematic below shows the communication channels between chassis components including the management modules (MGMT), the FIM modules (called FIM1 and FIM2) and the FPM modules (FPM3, FPM4, FPM5, and FPM6).

By default MGMT2 is the active management module and MGMT1 is inactive. The active management module always has the IPMB address 0x20 and the inactive management module always has the IPMB address 0x22.

The active management module communicates with all modules in the chassis over the base backplane. Each module, including the management modules has a Shelf Management Controller (SMC). These SMCs support Intelligent Platform Management Bus (IPMB) communication between the active management module and the FIM and FPM modules for storing and sharing sensor data that the management module uses to control chassis cooling and power distribution. The base backplane also supports serial communications to allow console access from the management module to all modules, and 1Gbps Ethernet communication for management and heartbeat communication between modules.

FIM1 and FIM2 (IPMB addresses 0x82 and 0x84) are the FIM modules in slots 1 and 2. The interfaces of these modules connect the chassis to data networks and can be used for Ethernet management access to chassis components. The FIM modules include DP2 processors that distribute sessions over the Integrated Switch Fabric FortiGate-7040E

(ISF) to the NP6 processors in the FPM modules. Data sessions are communicated to the FPM modules over the 80Gbps chassis fabric backplane.

FPM03, FPM04, FPM05, and FPM06 (IPMB addresses 0x86, 0x88, 0x8A, and 0x8C) are the FPM processor modules in slots 3 to 6. These worker modules process sessions distributed to them by the FIM modules. FPM modules include NP6 processors to offload sessions from the FPM CPU and CP9 processors that accelerate content processing.

FortiGate-7040E

The FortiGate-7040E is a 6U 19-inch rackmount 4-slot chassis with a 80Gbps fabric and 1Gbps base backplane designed by Fortinet. The fabric backplane provides network data communication and the base backplane provides management and synch communication among the chassis slots.

FortiGate-7040E front panel

The FortiGate-7040E chassis is managed by a single management module that includes an Ethernet connection as well as two switchable console ports that provide console connections to the modules in the chassis slots. The management module controls chassis cooling and power management and provides an interface for managing the modules installed in the chassis. The standard configuration of the FortiGate-7040E includes two FIM (interface) modules in chassis slots 1 and 2 and two FPM (processing) modules in chassis slots 3 and 4.

FortiGate-7040E front panel

FortiGate-7040E schematic

The FortiGate-7040E chassis schematic below shows the communication channels between chassis components including the management module (MGMT), the FIM modules (called FIM1 and FIM2) and the FPM modules (FPM3 and FPM4).

The management module (MGMT, with IPMB address 0x20) communicates with all modules in the chassis over the base backplane. Each module, including the management module includes a Shelf Management Controller (SMC). These SMCs support Intelligent Platform Management Bus (IPMB) communication between the management module and the FIM and FPM modules for storing and sharing sensor data that the management module uses to control chassis cooling and power distribution. The base backplane also supports serial communications to allow console access from the management module to all modules, and 1Gbps Ethernet communication for management and heartbeat communication between modules.

FIM1 and FIM2 (IPMB addresses 0x82 and 0x84) are the FIM modules in slots 1 and 2. The interfaces of these modules connect the chassis to data networks and can be used for Ethernet management access to chassis components. The FIM modules include DP2 processors that distribute sessions over the Integrated Switch Fabric (ISF) to the NP6 processors in the FPM modules. Data sessions are communicated to the FPM modules over the 80Gbps chassis fabric backplane.

FPM3 and FPM4 (IPMB addresses 0x86 and 0x88) are the FPM processor modules in slots 3 and 4. These worker modules process sessions distributed to them by the FIM modules. FPM modules include NP6 processors to offload sessions from the FPM CPU and CP9 processors that accelerate content processing.

FortiGate-7030E

The FortiGate-7030E is a 6U 19-inch rackmount 3-slot chassis with a 80Gbps fabric and 1Gbps base backplane designed by Fortinet. The fabric backplane provides network data communication and the base backplane provides management and synch communication among the chassis slots.

FortiGate-7060E

FortiGate-7030E front panel

The FortiGate-7030E chassis is managed by a single management module that includes an Ethernet connection as well as two switchable console ports that provide console connections to the modules in the chassis slots. The management module controls chassis cooling and power management and provides an interface for managing the modules installed in the chassis. The standard configuration of the FortiGate-7030E includes one FIM (interface) module in chassis slot 1 and two FPM (processing) modules in chassis slots 3 and 4. The front panel also includes a sealed blank panel. Breaking the seal or removing the panel voids your FortiGate-7030E warranty. FortiGate-7030E front panel (example module configuration)

(missing or bad snippet)

FortiGate-7030E schematic

The FortiGate-7030E chassis schematic below shows the communication channels between chassis components including the management module (MGMT), the FIM module (called FIM1) and the FPM modules (FPM3 and FPM4).

The management module (MGMT, with IPMB address 0x20) communicates with all modules in the chassis over the base backplane. Each module, including the management module includes a Shelf Management Controller (SMC). These SMCs support Intelligent Platform Management Bus (IPMB) communication between the management module and the FIM and FPM modules for storing and sharing sensor data that the management module uses to control chassis cooling and power distribution. The base backplane also supports serial communications to allow console access from the management module to all modules, and 1Gbps Ethernet communication for management and heartbeat communication between modules.

FIM1 (IPMB address 0x82) is the FIM module in slot 1. The interfaces of this module connect the chassis to data networks and can be used for Ethernet management access to chassis components. The FIM module include DP2 processors that distribute sessions over the Integrated Switch Fabric (ISF) to the NP6 processors in the FPM modules. Data sessions are communicated to the FPM modules over the 80Gbps chassis fabric backplane.

FPM3 and FPM4 (IPMB addresses 0x86 and 0x88) are the FPM processor modules in slots 3 and 4. These worker modules process sessions distributed to them by the FIM module. FPM modules include NP6 processors to offload sessions from the FPM CPU and CP9 processors that accelerate content processing.

FIM-7901E