Yearly Archives: 2017

Explicit proxy firewall address types

Leave a reply

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
  • Host Regex Match – destination address
  • URL Category – destination address (URL filtering)
  • HTTP Method – source address
  • User Agent – source address
  • HTTP Header – source address
  • Advanced (Source) – source address (combines User Agent, HTTP Method, and HTTP Header)
  • Advanced (Destination) – destination address (combines Host Regex Match and URL Category)

The FortiGate explicit web proxy

2 Replies

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

If explicit web proxy options are not visible on the web-based manager, go to System > Feature Select and turn on Explicit Proxy.

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 Preventing the explicit web proxy from changing source addresses on page 2925.

 

For more information about explicit web proxy sessions, see Explicit web proxy sessions and user limits on page 2930.

Pages: 1 2 3

FortiClient WAN optimization over IPsec VPN configuration example

1 Reply

FortiClient WAN optimization over IPsec VPN configuration example

This example shows how to add WAN optimization to a FortiClient IPsec VPN. The IPsec VPN tunnel allows remote FortiClient users to connect to the internal network behind the FortiGate unit.

 

Example FortiClient WAN optimization configuration

To configure the FortiGate unit

Because computers running FortiClient can have IP addresses that change often, it is usually not practical to add FortiClient peers to the FortiGate WAN optimization peer list. Instead, a FortiGate unit that accepts WAN optimization tunnel requests from FortiClient is usually configured to accept any peer. This example does this by adding a WAN optimization authentication group with Peer acceptance set to Accept Any Peer.

In addition this example includes a wanopt to internal policy to allow WAN optimization traffic reach the internal network. Finally passive WAN optimization is added to the ssl.root policy because WAN optimization is accepting traffic from the IPsec VPN tunnel.

1. Go to WAN Opt. & Cache > Authentication Groups and select Create New.

2. Configure the WAN optimization authentication group:

 

Name                                           auth-fc

Authentication Method            Certificate

Certificate                                   Fortinet_Firmware

Peer Acceptance                       Accept Any Peer

3. Select OK.

4. Go to WAN Opt. & Cache > Profiles and select Create New (select the + button).

5. Add a profile for FortiClient WAN optimization sessions:

Name                                           Fclient_Pro

Transparent Mode                    Select

Authentication Group              auth-fc

 

Category                                     Address

Address Name                           Internal-Server-Net

Type                                            IP Range

Subnet / IP Range                     192.168.10.0/24

Interface                                     internal

9. Enter the following CLI command to add an explicit proxy policy to accept WAN optimization tunnel connections.

configure firewall explicit-proxy-policy edit 0

set proxy wanopt

set dstintf internal set srcaddr all

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

next end

 

To set up IPsec VPN to support WAN optimization

1. Go to VPN > IPsec Wizard, enter a Name for the IPsec VPN and select Dialup – FortiClient (Windows, Mac OS, Android).

2. Follow the wizard steps to configure the VPN. No special WAN optimization settings are required.

3. Go to Policy & Objects > IPv4 Policy and edit the policy created by the wizard.

 

This policy has the IPsec VPN interface created by the wizard as the source interface.

4. Turn on WAN Optimization and configure the following settings:

 

Enable WAN Optimization       passive

Passive Option                          default

5. Select OK.

 

To configure FortiClient and start the WAN optimization SSL VPN connection

1. Open FortiClient, configure Advanced settings, and select Enable WAN optimization.

2. Add a new IPsec VPN connection.

 

Set the Server to the WAN1 IP address of the FortiGate unit (172.20.120.30 in this example).

No other settings are required for this example. You can add authentication in the form of a user name and password if required by the FortiGate unit.

3. Start the IPsec VPN tunnel.

 

You should be connected to the IPsec VPN tunnel and traffic in it should be optimized.

FortiClient WAN optimization

Leave a reply

FortiClient WAN optimization

FortiClient WAN optimization supports protocol optimization and byte caching in IPsec VPN and SSL VPN tunnels between FortiClient and a FortiGate unit. To add WAN optimization to FortiClient, configure FortiClient Advanced settings and enable WAN optimization. This setting can then apply WAN optimization to any IPsec or SSL VPN tunnel between FortiClient and FortiGate, if the FortiGate IPsec or SSL VPN configuration also includes WAN optimization.

When FortiClient with WAN optimization enabled attempts to connect a server-side FortiGate unit, FortiClient automatically detects if WAN optimization has been added to the FortiGate tunnel configuration. If WAN optimization is detected and FortiClient can successfully negotiate with the FortiGate unit, WAN optimization starts.

 

FortiClient WAN optimization topology

Example reverse proxy web caching and SSL offloading for an Internet web server using a static one-to-one virtual IP

1 Reply

Example reverse proxy web caching and SSL offloading for an Internet web server using a static one-to-one virtual IP

This section describes configuring SSL offloading for a reverse proxy web caching configuration using a static one-to-one firewall virtual IP (VIP). While the static one-to-one configuration described in this example is valid, its also common to change the destination port of the unencrypted HTTPS traffic to a commonly used HTTP port such as 8080 using a port forwarding virtual IP.

 

Network topology and assumptions

In this configuration, clients on the Internet use HTTP and HTTPS to browse to a web server that is behind a FortiGate unit. A policy added to the FortiGate unit forwards the HTTP traffic to the web server. The policy also offloads HTTPS decryption and encryption from the web server so the web server only sees HTTP traffic.

The FortiGate unit also caches HTTP and HTTPS pages from the web server so when users access cached pages the web server does not see the traffic. Replies to HTTPS sessions are encrypted by the FortiGate unit before returning to the clients.

In this configuration, the FortiGate unit is operating as a web cache in reverse proxy mode. Reverse proxy caches can be placed directly in front of a web server. Web caching on the FortiGate unit reduces the number of requests that the web server must handle, therefore leaving it free to process new requests that it has not serviced before.

 

Using a reverse proxy configuration:

  • avoids the capital expense of additional web servers by increasing the capacity of existing servers
  • serves more requests for static content from web servers
  • serves more requests for dynamic content from web servers
  • reduces operating expenses including the cost of bandwidth required to serve content
  • accelerates the response time of web servers and of page download times to end users.

 

When planning a reverse proxy implementation, the web server’s content should be written so that it is “cache aware” to take full advantage of the reverse proxy cache.

In reverse proxy mode, the FortiGate unit functions more like a web server for clients on the Internet. Replicated content is delivered from the proxy cache to the external client without exposing the web server or the private network residing safely behind the firewall.

In this example, the site URL translates to IP address 192.168.10.1, which is the port2 IP address of the FortiGate unit. The port2 interface is connected to the Internet.

This example assumes that all HTTP traffic uses port 80 and all HTTPS traffic uses port 443.

The FortiGate unit includes the web server CA and an SSL server configuration for IP address 172.10.20.30 and port to 443. The name of the file containing the CA is Rev_Proxy_Cert_1.crt.

The destination address of incoming HTTP and HTTPS sessions is translated to the IP address of the web server using a static one-to-one virtual IP that performs destination address translation (DNAT) for the HTTP packets. The DNAT translates the destination address of the packets from 192.168.10.1 to 172.10.20.30 but does not change the destination port number.

When the SSL server on the FortiGate unit decrypts the HTTPS packets their destination port is changed to port 80.

Reverse proxy web caching and SSL offloading for an Internet web server using static one-to-one virtual IPs

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. Configure the FortiGate unit as a reverse proxy web cache server.

2. Configure the FortiGate unit for SSL offloading of HTTPS traffic.

3. Add an SSL server to offload SSL encryption and decryption for the web server.

Also note that if you perform any additional actions between procedures, your configuration may have different results.

 

Configuration steps – web-based manager

 

To configure the FortiGate unit as a reverse proxy web cache server

1. Go to Policy & Objects > Virtual IPs and select Create New to add a static NAT virtual IP that translates destination IP addresses from 192.168.10.1 to 172.10.20.30 (and does not translate destination ports):

 

VIP Type                                     IPv4 VIP

Name                                           Reverse_proxy_VIP

Interface                                     port2

Type                                            Static NAT

Source Address Filter              Do not select.

External IP Address/Range     192.168.10.1

Mapped IP Address/Range      172.10.20.30

Port Forwarding                        Do not select.

2. Select OK.

3. Go to Policy & Objects > IPv4 Policy and select Create New to add a port2 to port1 security policy that accepts HTTP and HTTPS traffic from the Internet.

 

Do not select security profiles. Set the destination address to the virtual IP. You do not have to enable NAT.

 

Incoming Interface                   port2

Source Address                        all

Outgoing Interface                   port1

Destination Address                 Reverse_proxy_VIP

Schedule                                    always

Service                                       HTTP HTTPS

Action                                         ACCEPT

4. Turn on Web Cache.

5. Select OK.

6. From the CLI enter the following command to add HTTPS web caching to the security policy

 

Assume the index number of the policy is 5.

config firewall policy edit 5

set webcache-https ssl-server end

 

To configure the FortiGate unit to offload SSL encryption and cache HTTPS content

1. Go to System > Certificates and select Import to import the web server’s CA.

 

For Type, select Local Certificate. Select the Browse button to locate the file (example file name: Rev_Proxy_ Cert_1.crt).

 

The certificate key size must be 1024 or 2048 bits. 4096-bit keys are not supported.

2. Select OK to import the certificate.

3. From the CLI, enter the following command to add the SSL server and to add the server’s certificate to the SSL server.

 

The SSL server ip must match the destination address of the SSL traffic after being translated by the virtual IP (172.10.20.30) and the SSL server port must match the destination port of the SSL traffic (443). The SSL server operates in half mode since it performs a single-step conversion (HTTPS to HTTP or HTTP to HTTPS).

config wanopt ssl-server edit rev_proxy_server set ip 172.10.20.30

set port 443

set ssl-mode half

set ssl-cert Rev_Proxy_Cert_1

end

 

Configuration steps – CLI

 

To configure the FortiGate unit as a reverse proxy web cache server

1. Enter the following command to add a static NAT virtual IP that translates destination IP addresses from

192.168.10.1 to 172.10.20.30 (and does not translate destination ports):

config firewall vip

edit Reverse_proxy_VIP set extintf port2 set type static-nat

set extip 192.168.10.1

set mappedip 172.10.20.30 end

2. Enter the following command to add a port2 to port1 security policy that accepts HTTP and HTTPS traffic from the

Internet. Enable web caching and HTTPS web caching.

 

Do not select security profiles. Set the destination address to the virtual IP. You do not have to enable NAT.

config firewall policy edit 0

set srcintf port2 set srcaddr all set dstintf port1

set dstaddr Reverse_proxy_VIP

set schedule always

set service HTTP HTTPS

set action accept set webcache enable

set webcache-https ssl-server end

 

To add an SSL server to offload SSL encryption and decryption for the web server

1. Place a copy of the web server’s CA (file name Rev_Proxy_Cert_1.crt) in the root folder of a TFTP server.

2. Enter the following command to import the web server’s CA from a TFTP server. The IP address of the TFTP server is 10.31.101.30:

execute vpn certificate local import tftp Rev_Proxy_Cert_1.crt 10.31.101.30

The certificate key size must be 1024 or 2048 bits. 4096-bit keys are not supported.

3. From the CLI, enter the following command to add the SSL server.

 

The SSL server ip must match the destination address of the SSL traffic after being translated by the virtual IP (172.10.20.30) and the SSL server port must match the destination port of the SSL traffic (443). The SSL server operates in half mode since it performs a single-step conversion (HTTPS to HTTP or HTTP to HTTPS).

config wanopt ssl-server edit rev_proxy_server set ip 172.10.20.30

set port 443

set ssl-mode half

set ssl-cert Rev_Proxy_Cert_1 end

4. Configure other ssl-server settings that you may require for your configuration.

Monitoring Web caching performance

Leave a reply

Monitoring Web caching performance

The web cache monitor shows the percentage of web cache requests that retrieved content from the cache (hits) and the percentage that did not receive content from the cache (misses). A higher the number of hits usually indicates that the web cache is being more effective at reducing WAN traffic.

The web cache monitor also shows a graph of web traffic on the WAN and LAN. A lower WAN line on the graph indicates the web cache is reducing traffic on the WAN. The web cache monitor also displays the total number of web requests processed by the web cache.

To view the web cache monitor, go to Monitor > Cache Monitor.

 

Web cache monitor

Pages: 1 2

Forwarding URLs to forwarding servers and exempting web sites from web caching

Leave a reply

Forwarding URLs to forwarding servers and exempting web sites from web caching

You can go to Network > Explicit Proxy and use the URL match list to forward URL patterns to forwarding servers and create a list of URLs that are exempt from web caching.

 

Forwarding URLs and URL patterns to forwarding servers

As part of configuring the explicit web proxy you can configure proxy chaining by adding web proxy forwarding servers. See “Proxy chaining (web proxy forwarding servers) “.

You can then use the URL match list to always forward explicit web proxy traffic destined for configured URLs or URL patterns to one of these forwarding servers. For example, you might want to forward all traffic for a specific country to a proxy server located in that country.

To forward traffic destined for a URL to a forwarding server that you have already added, go to Network > Explicit Proxy and select Create New. Add a name for the URL match entry and enter the URL or URL pattern. You can use wildcards such as * and ? and you can use a numeric IP address. Select Forward to Server and select a web proxy forwarding server from the list.

You can also exempt the URL or URL pattern from web caching.

Use the following command to forward all .ca traffic to a proxy server and all .com traffic to another proxy server.

config web-proxy url-match edit “com”

set forward-server “server-commercial” set url-pattern “com”

next

edit “ca”

set forward-server “server-canada” set url-pattern “ca”

next

edit “www.google.ca”

set cache-exemption enable

set url-pattern “www.google.ca” next

end

 

Exempting web sites from web caching

You may want to exempt some URLs from web caching for a number of reasons. For example, if your users access websites that are not compatible with FortiGate web caching you can add the URLs of these web sites to the web caching exempt list. You can add URLs and numeric IP addresses to the web cache exempt list.

You can also add URLs to the web cache exempt list by going to Network > Explicit Proxy and selecting Create New. Add a URL pattern to be exempt and select Exempt from Cache.

You can also add URLs and addresses to be exempt from the CLI. Enter the following command to add www.example.com to the web cache exempt list.

config web-proxy url-match

set cache-exemption enable

set url-pattern www.example.com end

Changing web cache settings

Leave a reply

Changing web cache settings

In most cases, the default settings for the WAN optimization web cache are acceptable. However, you may want to change them to improve performance or optimize the cache for your configuration. To change these settings, go to WAN Opt. & Cache > Settings.

From the FortiGate CLI, you can use the config wanopt webcache command to change these WAN optimization web cache settings.

For more information about many of these web cache settings, see RFC 2616.

 

Always revalidate

Select to always revalidate requested cached objects with content on the server before serving them to the client.

 

Max cache object size

Set the maximum size of objects (files) that are cached. The default size is 512000 KB and the range is 1 to 4294967 KB. This setting determines the maximum object size to store in the web cache. Objects that are larger than this size are still delivered to the client but are not stored in the FortiGate web cache.

For most web traffic the default maximum cache object size is recommended. However, since web caching can also cache larger objects such as Windows updates, Mac OS updates, iOS updates or other updates delivered using HTTP you might want to increase the object size to make sure these updates are cached. Caching these updates can save a lot of Internet bandwidth and improve performance when major updates are released by these vendors.

 

Negative response duration

Set how long in minutes that the FortiGate unit caches error responses from web servers. If error responses are cached, then subsequent requests to the web cache from users will receive the error responses regardless of the actual object status.

The default is 0, meaning error responses are not cached. The content server might send a client error code (4xx HTTP response) or a server error code (5xx HTTP response) as a response to some requests. If the web cache is configured to cache these negative responses, it returns that response in subsequent requests for that page or image for the specified number of minutes.

 

Fresh factor

Set the fresh factor as a percentage. The default is 100, and the range is 1 to 100%. For cached objects that do not have an expiry time, the web cache periodically checks the server to see if the objects have expired. The higher the Fresh Factor the less often the checks occur.

For example, if you set the Max TTL value and Default TTL to 7200 minutes (5 days) and set the Fresh Factor to 20, the web cache check the cached objects 5 times before they expire, but if you set the Fresh Factor to 100, the web cache will check once.

 

Max TTL

The maximum amount of time (Time to Live) an object can stay in the web cache without the cache checking to see if it has expired on the server. The default is 7200 minutes (120 hours or 5 days) and the range is 1 to 5256000 minutes (5256000 minutes in a year).

 

Min TTL

The minimum amount of time an object can stay in the web cache before the web cache checks to see if it has expired on the server. The default is 5 minutes and the range is 1 to 5256000 minutes (5256000 minutes in a year).

 

Default TTL

The default expiry time for objects that do not have an expiry time set by the web server. The default expiry time is 1440 minutes (24 hours) and the range is 1 to 5256000 minutes (5256000 minutes in a year).

 

Proxy FQDN

The fully qualified domain name (FQDN) for the proxy server. This is the domain name to enter into browsers to access the proxy server. This field is for information only can be changed from the explicit web proxy configuration.

 

Max HTTP request length

The maximum length of an HTTP request that can be cached. Larger requests will be rejected. This field is for information only can be changed from the explicit web proxy configuration.

 

Max HTTP message length

The maximum length of an HTTP message that can be cached. Larger messages will be rejected. This field is for information only can be changed from the explicit web proxy configuration.

 

Ignore

Select the following options to ignore some web caching features.

 

If-modified–since     By default, if the time specified by the if-modified-since (IMS) header in the client’s conditional request is greater than the last modified time of the object in the cache, it is a strong indication that the copy in the cache is stale. If so, HTTP does a conditional GET to the Overlay Caching Scheme (OCS), based on the last modified time of the cached object. Enable ignoring if-modified-since to override this behavior.

 

HTTP 1.1 con- ditionals

HTTP 1.1 provides additional controls to the client over the behavior of caches toward stale objects. Depending on various cache-control headers, the FortiGate unit can be forced to consult the OCS before serving the object from the cache. For more inform- ation about the behavior of cache-control header values, see RFC 2616.Enable ignor- ing HTTP 1.1 Conditionals to override this behavior.

 

Pragma–no–cache    Typically, if a client sends an HTTP GET request with a pragma no-cache (PNC) or cache-control no-cache header, a cache must consult the OCS before serving the con- tent. This means that the FortiGate unit always re-fetches the entire object from the OCS, even if the cached copy of the object is fresh.Because of this behavior, PNC requests can degrade performance and increase server-side bandwidth utilization. However, if you enable ignoring Pragma-no-cache, then the PNC header from the cli- ent request is ignored. The FortiGate unit treats the request as if the PNC header is not present.

 

IE Reload

Some versions of Internet Explorer issue Accept / header instead of Pragma no-cache header when you select Refresh. When an Accept header has only the / value, the FortiGate unit treats it as a PNC header if it is a type-N object. Enable ignoring IE reload to cause the FortiGate unit to ignore the PNC interpretation of the Accept / header.

 

Cache Expired Objects

Applies only to type-1 objects. When this option is selected, expired type-1 objects are cached (if all other conditions make the object cacheable).

 

Revalidated Pragma-no-cache

The pragma-no-cache (PNC) header in a client’s request can affect how efficiently the FortiGate unit uses bandwidth. If you do not want to completely ignore PNC in client requests (which you can do by selecting to ignore Pragma-no-cache, above), you can nonetheless lower the impact on bandwidth usage by selecting Revalidate Pragma-no-cache.

When you select Revalidate Pragma-no-cache, a client’s non-conditional PNC-GET request results in a conditional GET request sent to the OCS if the object is already in the cache. This gives the OCS a chance to return the 304 Not Modified response, which consumes less server-side bandwidth, because the OCS has not been forced to otherwise return full content.

By default, Revalidate Pragma-no-cache is disabled and is not affected by changes in the top-level profile.

Most download managers make byte-range requests with a PNC header. To serve such requests from the cache, you should also configure byte-range support when you configure the Revalidate pragma-no-cache option.