'Fastest response' fails if one connection down

#1

I have 3 connections balanced on ‘Fastest response’ method.

Now one connections runs out of traffic and ISP blocks it. Two remaining connections still work. What ‘Fastest response’ should do? It even does not need any health checks - just put traffic on that one who responds faster.

What ‘Fastest response’ practically do? Hang! Nothing works!

Looks like algorithm’s waiting to have responses from all selected connections until it choses the fastest one. And obviously will wait forever to get response from non-healthy connection. I don’t have any other explanations. Once I manually disconnect problematic connection, everything works again.

#2

Sounds like a bug to me.
Fastest Response should send new requests to any new public IP via all the available WAN interfaces. Whichever connection gets a response back from that IP first is the WAN link that will be used for all future communication with that public IP.

In this situation is the WAN that’s run out of data showing as red or green on the dashboard?

#3

Fastest Response send traffic to WAN with first reply packet (not wait for reply from all selected WAN) and will not send traffic to health check failed WAN.

Did you enabled Health Check on the blocked WAN? Does the ISP intercept your HTTP session and return something (e.g. Quota exceeded)?

#4

Connection stays green probably because default (I guess) health check setting is DNS records. When ISP blocks traffic it probably does not block its own DNS servers. So connection stays green. Now I changed this to Google’s DNS.

The only way I know connection is broken then is by checking WAN Quality page in Status section. There I can see that pings/latency chart is empty.

Still I cannot understand why I’m not getting provider’s ‘quota exceeded’ page if this channel is fastest or requested resource through any other working connection.