Transparent mode makes speed terrible!

I'll attach the logs seen while accessing a random site www.coolstuffinc.com), with and without manually configuring the proxy address (both in transaparent mode).

If we configure it manually it takes 5 seconds to load the website but if we do not specify the proxy and just let the transparent proxy do it's magic, it takes 30 seconds!

As described in similar posts I added the google analytics IPs to the transparent skiplist but it made no difference in any case.

Guillerone, when you configure the browser for the proxy, the proxy responds as if it were in Standard mode as that's what the client expects.

The difference between Transparent and Standard is often caused by a DNS misconfiguration.  In Standard, the UTM does the DNS lookup.  In Transparent, the client does the lookup.  Try DNS Best Practice and see if that solves your issue.

Cheers - Bob

Maybe I'm wrong but with transparent and no browser config does DNS come into it as the UTM intercepts traffic?  

I use transparent and no browser config and it's pretty fast.

You're right, Ross - Transparent shouldn't slow him down.  Since it does, I suspect that he has a DNS configuration problem that causes the browser to do lookups in the Root Name Servers.

Cheers - Bob

Thanks both for replying.

Bob- I guessed the UTM responded in standard mode if I typed the proxy manually, I just mentioned it so you saw the difference in speed. Thanks though.

Let me reply based on the points of the post you suggested:
1. Was ok.
2. "Use forwarders assigned by ISP" was not checked. As forwarders we had google's and the internal servers. Should internal servers be excluded? (not according to the docs). Also, we don´t use availability group here as we just put both. I think that shouldn´t make a difference, right?.
3. Haven´t seen this before, but added "168.192.in-addr.arpa" to point to our internal servers as we have many subnets (192.168.10.0, 192.168.11.0...). Showing the hostnames instead of the IPs was something desirable too.
4. Was ok.
5. Done. Only had our internal servers.
6. Done. Before we did not have the Astaro IP here, just the Google IPs so this shouldn't make a difference either (just optimizing).

To be honest I don´t see how this can make a difference in our case. Our DNS configuration should have used Google DNSs and not fallback to the root name servers.

Thanks again.

Should internal servers be excluded? ...  Also, we don´t use availability group here as we just put both.

Yes, excluded.  I don't remember the reason for the Availability Group, but that suggestion produced a resounding endorsement from Sophos Support.  Any luck now?

Cheers - Bob
PS Found it: host not found errors

You're right, Ross - Transparent shouldn't slow him down.  Since it does, I suspect that he has a DNS configuration problem that causes the browser to do lookups in the Root Name Servers.  Cheers - Bob

  

Ok cool understand what you meant now. [:)]

If we remove the internal DNS server from the forwarders list, won´t it have problems with name resolution through VPN?
In our VPN we have specified the UTM as the primary DNS server and an internal server as the secondary, although we could put both internals if that works.

For the availability group I created one with OpenDNS IPs and Google's (in that order), with PING monitoring on 30 seconds interval and 5 of timeout. Also "always resolve" is unchecked. Would that be correct?
If OpenDNS was down, wouldn´t that make the availability group only notice after 30" of downtime? That sounds risky.

Right now is working great but there is also nobody in the office until Tuesday so load problems could not be applying now.

Thanks again.

If we remove the internal DNS server from the forwarders list, won´t it have problems with name resolution through VPN?

No, not if you configure it in Request Routing.

PING monitoring on 30 seconds interval and 5 of timeout. Also "always resolve" is unchecked.

I've always left this with the default 60/5/checked.  Read the Help or Manual to understand why.

Cheers - Bob

No, not if you configure it in Request Routing.


I've always left this with the default 60/5/checked.  Read the Help or Manual to understand why.

Cheers - Bob

There's nothing wrong to use default (60/5). This simply means, that every 60s will be checked, and after 5 fails it will switch to next living DNS in list. This can take up to 5 mins in that case...

For that reason I personally use 15/3, which will fail over to next DNS within 45 secs. without putting unnecessary pressure due checks on the public DNS servers (if thousands of people start sending udp checks or especially pings to public DNS servers in one second intervals, they may generate noticeable load on the servers....some kind of DDoS attack in a way ;o))

Technically both will do the same.

And the "always keep resolved" means, that all servers (even the inactive ones in the list) will be always checked, so if top DNS fails, it does not have to check first, which of the following servers is alive, which may allow a faster failover.