web proxy slow again

it's tortise for everything...i would not resort to shuttering it if it was only a few sites.  If you read my previous threads I have throughly researched this.  Pings do not say how loaded the cff servers are..sometimes the pings are ok but it's still glacial in response...this means the cff servers are having issues.  Sometimes(but not often) the pings are bad right at the gateway to the US cff servers..most of the time it's just the cff servers responding very very slowly.  It wouldn't be so bad if when you disabled all content filter options it actually stopped routing things to the cff servers..but it still does..this means folks have to shutdown the proxy totally rendering the a/v useless as well.

We need to figure out what is unique in the setup that causes this- your experience is not universal.

I have seen occasional issues, and some sites simply timeout when they do not proxy well (often without any clues of you use the HTTPS proxy).  But universal timeouts indicate something we can fix.

Without digging through all of your forum posts, the most common causes of slow proxies I have seen in support cases have been:

Slow or misconfigured DNS.
Host or network definitions bound to interfaces.
Use of DNS hostnames or DNS groups in IPS configurations (can trigger IPS restarts, delaying all traffic).
Upstream proxies interfering with the traffic.

One thing which may be informative is to run a frequent series of traceroutes to the CFF servers (with name resolution disabled to speed things up and remove outside influences).  This will give you an idea of baseline performance for each hop, and help identifiy exactly where the issues lie.

Have you contacted support on this?

I apologize if you've covered all of this before.

Hi Jack, this is the second time I have heard of slow browsing when the host/network definition is bound to an interface. Could you elaborate a little more on that because I have a bad habit of doing that for the external hosts. Why exactly is it bad and why do we even have that option if it adversely effects astaro.

Regards
Bill.

Edit: By the way nice tip on that grc dns benchmark tool. I have been using it for a while and it opens your eyes to the servers that you think are fast, that are really not that fast under all circumstances. Specially open dns etc which are super fast for cached requests but not that great for uncached queries (atleast for me).

Hi Bill

I wish I could give a specific answer, but it varies by situation.  Binding to an Interface "pins" the traffic to the interface, this can interfere with NAT and routing depending on the configuration.  Common issues include adding a hop to traffic, causing addresses to hit (or miss) PF rules, or overriding NAT rules and causing traffic to drop or not return to the correct Interface.

Binding to interfaces can be useful for things like the Internet definition, but can also do some unexpected (and unpleasant) things

Jack, I always thought of networking binding as a security setting. Like you said internet 0.0.0.0/0 definition is bound to external by default and you can't change it. To me it means that internet traffic should only come from external interface period.

The same can be said about other interfaces. For example my servers in the dmz should only be able to send the traffic via dmz and if there is no specific packet filter rule, that traffic should be dropped and shouldn't look for any other route on any interface. 

I have changed my bindings to "ANY" to see if I notice any improvements in speed, but I don't have a gazillion packet filter rules and my nat  rules are pretty straight forward. I just feel that I am doing something wrong when for example I bind open dns on "ANY" interface. I think it should be bound to EXTERNAL only[:S]

You've got the idea Bill, it can be a powerful tool for controlling your environment.

But like most tools, it can also do some damage, and sometimes in unexpected ways.

Binding to an interface seems to be easiest to implement safely as a target-  as in a PF rule allowing an internal network to access the Internet will work well.  If the bound definition is a source, that is usually where things are likely to get "interesting".

Binding to an interface seems to be easiest to implement safely as a target-  as in a PF rule allowing an internal network to access the Internet will work well.  If the bound definition is a source, that is usually where things are likely to get "interesting".

Aha... now its making some sense. Only thing is that astaro would be confused about ip spoofing if it doesn't know where to expect a certain packet from. I guess that is the trade off ??? in this situation.

Use of DNS hostnames or DNS groups in IPS configurations (can trigger IPS restarts, delaying all traffic).

Jack, I have an Intrusion Protection exception for a DNS host (a Web Bank site that generates false positives). So it can slow down the web surfing? [:O]

We need to figure out what is unique in the setup that causes this- your experience is not universal.

I have seen occasional issues, and some sites simply timeout when they do not proxy well (often without any clues of you use the HTTPS proxy).  But universal timeouts indicate something we can fix.

Without digging through all of your forum posts, the most common causes of slow proxies I have seen in support cases have been:

Slow or misconfigured DNS.
Host or network definitions bound to interfaces.
Use of DNS hostnames or DNS groups in IPS configurations (can trigger IPS restarts, delaying all traffic).
Upstream proxies interfering with the traffic.

One thing which may be informative is to run a frequent series of traceroutes to the CFF servers (with name resolution disabled to speed things up and remove outside influences).  This will give you an idea of baseline performance for each hop, and help identifiy exactly where the issues lie.

Have you contacted support on this?

I apologize if you've covered all of this before.

yes...however it's far from non-universal i'm just one of the few making noises about it.  I've hit it on BOTH installs i had going.  It's not a regular e3vent..and I have documented pings and tracerts that show connectivity is fine until i get to the cff servers in previous threads.

We need to figure out what is unique in the setup that causes this- your experience is not universal.

I have seen occasional issues, and some sites simply timeout when they do not proxy well (often without any clues of you use the HTTPS proxy).  But universal timeouts indicate something we can fix.

Without digging through all of your forum posts, the most common causes of slow proxies I have seen in support cases have been:

Slow or misconfigured DNS.
Host or network definitions bound to interfaces.
Use of DNS hostnames or DNS groups in IPS configurations (can trigger IPS restarts, delaying all traffic).
Upstream proxies interfering with the traffic.

One thing which may be informative is to run a frequent series of traceroutes to the CFF servers (with name resolution disabled to speed things up and remove outside influences).  This will give you an idea of baseline performance for each hop, and help identifiy exactly where the issues lie.

Have you contacted support on this?

I apologize if you've covered all of this before.

yes...however it's far from non-universal i'm just one of the few making noises about it.  I've hit it on BOTH installs i had going.  It's not a regular e3vent..and I have documented pings and tracerts that show connectivity is fine until i get to the cff servers in previous threads.