Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Replies 7 replies
  • Subscribers 1 subscriber
  • Views 1330 views
  • Users 0 members are here
Options
Suggested

[9.185] web filtering really slow with UTM behind net (NAT) modem

apijnappels
Last weekend I had to change my modem due to upgrades from my ISP.
Unfortunately the new modem doesn't allow me to put in bridge mode, so I gave the UTM a fixed IP-address on the External WAN interface and entered that IP-address as a DMZ address in the modem.
All IPSEC connections work again, so do my NAT-rules.

It seems however that since the change the webfiltering has become slow to extremely slow.
Some websites take several seconds (4 - 20) before starting to load. 
Some websites take ages to load completely, usually in such a case after almost all the website got shown, the status bar shows google-analytics.com, or google.com or googly-syndicate.com, but also doubleclick.net and some others seem to stall loading these websites for a long time (sometimes over a minute).

It looks like that when a site is loaded and I reload it within a couple of minutes, then the reload is normal (new content shows up almost immediately and also the total loading time of the site is quick). If I wait too long I see the delays again.
Right now the only category I block is nudity. A/V scanning is on (single engine) and my machine is a Intel Core i5 4670 with 8GB of RAM and CPU governor switched to performance (but with ondemand it shows the same behavior).

When I switch off web filtering all delays are gone immediately, but they return as soon as web filtering gets enabled again.

Google (also just search it by entering search words in the browsers address bar) seems to always take a long time when webfiltering is switched on. On other sites I didn't really find same behavior on different visits, however the delays are really annoying.

I'm using the transparent filtering with no authentication and no https scanning
Parents
  • 0
    1)I am aware of the Endpoint time thread and I've got it in my todo to try and reproduce before we open it as a bug.  Lets deal with that in the other thread.

    2) I expect there to be categorization timeouts occasionally as servers rotate.  A background of ~10 a day is fine.  Spiking to >100 is interesting IF we knew that it was a stable system.  But if you lose your internet connection or anything the numbers become meaningless.  I suspect that Dec 9th is just a blip.

    3) It sounds like the IPv6 issue may be resolved but I recommend that if you have any future problems to check your tunnel broker as well.  I have recently had another beta customer get the same timeout message, which could mean there is a code problem in the UTM or if you are both using the same broker a problem on their side.  I'll let you know if I find out more.
Reply
  • 0
    1)I am aware of the Endpoint time thread and I've got it in my todo to try and reproduce before we open it as a bug.  Lets deal with that in the other thread.

    2) I expect there to be categorization timeouts occasionally as servers rotate.  A background of ~10 a day is fine.  Spiking to >100 is interesting IF we knew that it was a stable system.  But if you lose your internet connection or anything the numbers become meaningless.  I suspect that Dec 9th is just a blip.

    3) It sounds like the IPv6 issue may be resolved but I recommend that if you have any future problems to check your tunnel broker as well.  I have recently had another beta customer get the same timeout message, which could mean there is a code problem in the UTM or if you are both using the same broker a problem on their side.  I'll let you know if I find out more.
Children
No Data
Unfiltered HTML