Access to web slow using protection policies

[#1]

We have a 620B running v4.0,build0194,100121 (MR1 Patch 3). We have several policy rules that related to HTTP/HTTPS but the perspection is that the rule that has a protection profile attached to it results in slower web access. The protection profile is only for logging web activity but as we' re in the process of gradually migrating all users through an Identity Based policy utilising a protection profile I am concerned I will be have lots of people complaining about slow web access. I have checked the troubleshooting and all checks indicate the problem isn' t related to accessing the Fortiguard service but has anyone else experienced a slow down in web access after applying protection profiles. Cheers

[ede_pfau]

Hi, a protection profile holds all the settings that really have an impact on ressources, load and latency. Namely AV scanning, IPS, logging, web filtering. Please post your pp (from the CLI:

 show firewall profile-protocol-options
 show firewall policy <policyID in question>
 

[#3]

Hi I' ve stripped the PP so that it is only web logging but perhaps you can spot something I' ve missed. Thanks PHT-FortiGate-62~ # sho firewall profile ' web logging' config firewall profile edit " web logging" config log set log-web-content enable set log-web-ftgd-err enable set log-web-url enable end set ftp no-content-summary splice set http bannedword fortiguard-wf no-content-summary rangeblock urlfilter set https fortiguard-wf no-content-summary urlfilter set imap no-content-summary set imaps no-content-summary set pop3 no-content-summary set pop3s no-content-summary set smtp no-content-summary splice set smtps no-content-summary splice set smtp-spamaction pass set pop3-spamaction pass set imap-spamaction pass set imap-spamtagtype subject set smtps-spamaction pass set pop3s-spamaction pass set imaps-spamaction pass unset nntp config app-recognition edit " http" set port 80 next edit " https" set port 443 next edit " smtp" set port 25 next edit " pop3" set port 110 next edit " imap" set port 143 next edit " nntp" set port 119 next edit " ftp" set port 21 next edit " smtps" set port 465 next edit " pop3s" set port 995 next edit " imaps" set port 993 next end unset im set comment " All traffic but with web logging" unset http-post-lang set ftgd-wf-options error-allow strict-blocking set ftgd-wf-https-options error-allow strict-blocking next end PHT-FortiGate-62~ # sho firewall policy 13  config firewall policy edit 13 set srcintf " Inside_Vlan217" set dstintf " Outside_Vlan217" set srcaddr " Cumberland Dental" " PHT LAN" set dstaddr " All" set action accept set schedule " always" set service " Web Services" set profile-status enable set profile " web logging" next end

[Jshaw]

what DNS servers are you using on the Fortigate? I find that if you change them from the defaults to something like google' s or your ISP' s it will perform the lookup' s faster which when using the fortiguard webfilter is HUGE.

[rwpatterson]

I had a similar issue that was plaguing me for months. Turns out a firmware upgrade took care of the ' bug' . I left v4.0.4 and upped to v4.1.8. Even the ' unfiltered' protection profile would bring traffic in the policy to a screeching slowdown... So far, it' s aces. Bob

[#6]

Thanks for the advice folks, at least this gives me something to work with.

[#7]

The issue is certainly related to turning on Fortiguard Web Filtering. If I use the Unfiltered profile and log and allow all traffic web access is fine. As soon as I enable ' Fortiguard Web Filtering' the web slows down. I' ve tried changing the DNS to google DNS but this doesn' t seem to make a difference.

[ede_pfau]

IMHO as long as you have the Fortiguard Web Filter (reputation based) active you will have to cope with latency. For a web page with a lot of URLs to resolve this might make the impression that access is " slow" . Recently I had to benchmark my DNS as I read about faster and slower nameservers on the net. Usually I use my ISP' s DNS, and that turned out to be the right choice. I never use the default (Fortinet) DNS. Here is the link to a very helpful DNS benchmark program by Gibson Research: http://www.grc.com/dns/benchmark.htm It' s Windows based; for Linux you can use the " dig" command. What about DNS caching? on PCs and servers, that is built-in. On a FG I would assume it is used but right now I cannot confirm this. That should help a lot when viewing web pages (resolving " google-analytics.com" for the 1000th time) although it probably doesn' t help much with WF (as these requests are more or less unique). WF itself uses caching too.

[#9]

Being a large NHS organisation we have our own DNS servers which are configured on the FG. Having run the Benchmark tool (thanks for that) it verifys that our local DNS are alive, responding to queries, are faster than public alternatives and are reliable. Therefore I' m assuming name resolution maybe isn' t the issue but it is related to the Fortiguard service. The FG 620B is not showing any signs of stress (8% CPU and 18% Memory Usage). Does the FG query the Fortiguard service for url lookups? As our National NHS network blocks access to the Fortiguard service I' ve had to route that traffic out a skinny internet pipe and if I ping from the FG the Fortiguard Servers 208.91.112.194 and 216.156.209.26, the response time is approx 150ms. I suspect this could be the problem? Thanks for your advice.

[ede_pfau]

I sure bet it is. And probably the 150 ms cost you more than the (small) bandwidth. Reading that you are in a large organisation I keep wondering why you had to bypass the Fortiguard requests. Bypassing in itself is questionable, if necessary, but if you run a Fortigate you just need access to the services that come with it. Am I glad that I govern in my tiny office... Yes, the WF has to query the Fortiguard servers for each URL' s reputation/classification. You can even configure it so that it blocks access to pages that are not categorized yet. This is intensive traffic and most likely slows down web page buildup. The only option I see for you at the moment is to drop WF to avoid the latency toll, until you' ve found a better way to handle these requests. Fortiguard services do work in many networks, small or large.