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.

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.

Category	Address
Name	Internal_subnet
Type	IP Range
Subnet / IP Range	10.31.101.1 – 10.31.101.255
Interface	any*

*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

Category	Address
Name	Fortinet-web-sites
Type	URL Pattern (Explicit Proxy)
URL Pattern	fortinet.com
Interface	any

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.

Explicit Proxy Type	Web
Source Address	Internal_subnet
Outgoing Interface	wan1
Destination Address	Fortinet-web-sites
Schedule	always
Action	ACCEPT

12. Set the Disclaimer Options

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

choices are:

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.
By User	The disclaimer will be displayed when a new user logs on.

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

 

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:

true-client-ip		Support HTTP header True-Client-IP.
x-real-ip		Support HTTP header X-Real-IP.
x-forwarded-for		Support HTTP header X-Forwarded-For.

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

 

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

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.

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 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.

Example caching HTTP sessions on port 80 and HTTPS sessions on port 443 using WCCP

This example configuration is the same as that described in Example caching HTTP sessions on port 80 and

HTTPS sessions on port 443 using WCCP on page 295 except that WCCP now also cached HTTPS traffic on port 443. To cache HTTP and HTTPS traffic the WCCP service group must have a service ID in the range 51 to 255 and you must specify port 80 and 443 and protocol 6 in the service group configuration of the WCCP client.

Also the security policy on the WCCP_srv that accepts sessions from the internal network to be cached must accept HTTP and HTTPS sessions.

 

Example caching HTTP sessions on port 80 and HTTPS sessions on port 443 using WCCP

Configuring the WCCP server (WCCP_srv)

Use the following steps to configure WCCP_srv as the WCCP server for the example network. The example steps only describe the WCCP-related configuration.

To configure WCCP_srv as a WCCP server

1. Add a port2 to port1 security policy that accepts HTTP traffic on port 80 and HTTPS traffic on port 443 and is configured for WCCP:

config firewall policy edit 0 set srtintf port2 set dstintf port1 set srcaddr all set dstaddr all set action accept set schedule always set service HTTP HTTPS set wccp enable set nat enable

end

2. Add another port2 to port1 security policy to allow all other traffic to connect to the Internet.

config firewall policy edit 0 set srtintf port2 set dstintf port1 set srcaddr all set dstaddr all set action accept set schedule always set service ANY

set nat enable

end

3. Move this policy below the WCCP policy in the port2 to port1 policy list.
4. Enable WCCP on the port5 interface.

config system interface edit port5 set wccp enable

end

5. Add a WCCP service group with service ID 90 (can be any number between 51 and 255).

config system wccp edit 90 set router-id 10.51.101.100 set server-list 10.51.101.0 255.255.255.0

end

6. Add a firewall address and security policy to allow the WCCP_client to connect to the internet.

config firewall address edit WCCP_client_addr set subnet 10.51.101.10

Example caching HTTP sessions on port 80 and HTTPS sessions on port 443

end

config firewall policy edit 0 set srtintf port5 set dstintf port1 set srcaddr WCCP_client_addr

set dstaddr all set action accept set schedule always set service ANY set nat enable end

Configuring the WCCP client (WCCP_client)

Use the following steps to configure WCCP_client as the WCCP client for the example network. The example steps only describe the WCCP-related configuration.

To configure WCCP_client as a WCCP client

1. Configure WCCP_client to operate as a WCCP client. config system settings set wccp-cache-engine enable

end

You cannot enter the wccp-cache-engine enable command if you have already added a WCCP service group. When you enter this command an interface named w.<vdom_name> is added to the FortiGate configuration (for example w.root). All traffic redirected from a WCCP router is considered to be received at this interface of the FortiGate unit operating as a WCCP client. A default route to this interface with lowest priority is added.

2. Enable WCCP on the port1 interface.

config system interface edit port1 set wccp enable

end

3. Add a WCCP service group with service ID 90. This service group also specifies to cache sessions on ports 80 and 443 (for HTTP and HTTPS) and protocol number 6.

config system wccp edit 90 set cache-id 10.51.101.10 set router-list 10.51.101.100

ports 80 443 set protocol 6 end

packet flow