Google error


#1

Hello,

We are having an issue that seems to be caused by the peplink (load balancer). When we try to watch videos stored in google drive, sometimes we get the error : “An Error Occurred, Please try again later.”

When we only use one connection on the peplink, it works fine. When we load balance over 2 connections, that’s when the error occurs. Thoughts.:confused:


#2

As long as you have the default outbound HTTPS Persistence rule in place you will not have this issue. Did you remove it or modify it?


#3


Hi Tim, We are behind a firewall which delivers 1 ip to the load balancer


#4

I’m not sure I follow you, in your OP you mentioned having two connections? Can you post a basic network diagram?


#5

Did you ever manage to solve this problem? We are having a similar problem where all google services (google.com, analytics, drive, etc) are largely inaccessible (even calls to google analytics from other sites) unless we add an outbound rule to Enforce all “google.*” traffic to one of the WAN connections (the only one with a fixed public IP incidentally – when we tried enforcing the connection to either of the other two WAN connections it does not work).

We are using Google’s public DNS servers for all of our connections, but I cannot see how that would cause a problem.

Similar to you, all our users sit behind a firewall which is then connected to the Balance One Core.

Thanks


#6
  1. Do you have 3 WAN links?

  2. These are correct?

  • Enforced google services to public IP WAN (e.g. WAN1) only - Work fine.
  • Enforced google services to private IP WAN (e.g. WAN2) only - Failed.
  • Enforced google services to private IP WAN (e.g. WAN3) only - Failed.
  1. Please share the screenshot of your Outbound Polices (Network > Outbound Policy > Rules)

#7
  1. When I had written that post we had 3 WAN links. However, we have now added a 4th with a fixed IP and reconfigured one of the original 3 with a fixed IP, but there has been no improvement.

  2. Yes, that is correct, but it also fails with public IPs on WAN 2-4 as of this morning’s tests.

3a. The below screenshot is the config that does not work.



(some unrelated rules were masked for confidentiality)

3b. If the “YouTube” and “Google” rules at the top are enabled, then we do not have a problem connecting to ALL Google related services (analytics, drive, youtube, etc). However, our internet speeds are still slow and it seems like the bandwidth is not being distributed equally – the bulk of it is going to one WAN interface (at more than 2x each of the others, even though they are all 4G-LTE and one is LTE-A).

Again, I would like to emphasize that the users are behind a firewall, so it is:

users > switches > firewall > peplink balance one core > 4 WAN connections

Thanks again!


#8

Hi,

Base on the description given above, look like the issue is more like the HTTPS connections persistence rules that need to keep in-order to make sure the remote servers doesn’t reject the connections.

Can you please change the **HTTPS Persistence ** rule as the below screenshot and let us know the test results for Google & Youtube.


Regarding to the bandwidth is not distributed equally issue, can you disable the NAT for the firewall & configure route between the firewall & Balance One core ? This will give visibility for Balance On Core & load-balance the HTTPS session base on the clients source IP.

Thank You


#9

I did the following:

  1. Disabled the NAT on the firewall appliance --> The Balance One Core now sees a range of IPs for all clients instead of just the one (firewall). However, each client still appears to have the same MAC address (the firewall’s).
  2. Updated the HTTPS Persistence rule (and the HTTP Persistence rule that we had) to be based on source instead of destination --> this is not make much of a difference, some services work well on some client machines but not others. In addition to Google, we also seem to see the same problem with http://www.apple.com for some clients (as well as some other sites at random). Again, adding an Enforced rule solves it every time.
  3. We bypassed the firewall appliance and internal switches and connected directly to the LAN port of the Balance One Core and still saw the same problems being reported.

Any other ideas?

Thanks.


#10

I also just saw this post [https://forum.peplink.com/threads/6034-ISP-DNS-Redirect-to-Cache-causes-Google-in-accessible?p=24027&viewfull=1#post24027] and have disabled the DNS Proxy setting. I will be testing further to determine if it has improved the reliability and performance. In the meantime, let me know if you have any other suggestions. Also, please confirm that the Persistence by Source will work reliably if the Clients all have unique IPs but the same MAC address.

Thanks.


#11

Hi,

Base on the outbound policy given in the previous post, you don’t have any outbound policy defined using MAC address thus your concerns whether “clients all have unique IPs but the same MAC address” should not be a issue here.

HTTPS persistent is well tested & confirm working for websites/connections that need to maintain the connection persistence for multiple WAN environment. In my network environment, we had 3 internet connections with the HTTPS persistence outbound policy, this is working fine for all the google drive connection. May i know the issue happen randomly ? or do you have the steps to reproduce the google access issue when run in multiple WANs ? If yes, please provide the steps and we will try to reproduce it.

Please confirm the following:

  1. PC Direct connect to WAN1 - do you have issue browse to the mention website/google drive ?
  2. PC Direct connect to WAN2 - do you have issue browse to the mention website/google drive ?
  3. PC Direct connect to WAN3 - do you have issue browse to the mention website/google drive ?
  4. PC Direct connect to WAN3 - do you have issue browse to the mention website/google drive ?

We have cases whereby 1 or 2 of the WANs is blocking the websites, thus this cause the Persistence HTTPS not working properly. If you having this issue, you need to have the outbound policy not to forward the dedicated websites/connections to the problem WANs.

I would suggest you to open a support ticket here for the support team to further check. This could be related to WAN disconnection, bandwidth congestion or any other issue cause the google connections is broken.

Thank You


#12

If we define an Outbound Rule (such as we have right now for HTTPS Persistence) where:

  1. Source and Destination are both “Any” (since the source is Any and the Balance One Core sees a unique IP per client but only one MAC for all (of the internal firewall), I want to make certain that the persistence will be handled correctly)
  2. Algorithm is defined as “Persistence”
  3. Persistence Mode is defined as “By Source”

Given my comment and concern about #1 above, should the setting of Source be changed to “IP Address = *” instead or should it work fine the way it is?

Thank you.

Hi,

The default HTTPS persistence rule should work fine.


Make sure there is no custom outbound policy that overwrite the HTTPS persistence rule.

Thank You


#13

Hi adeebag ,

Sorry, i may accidentally edited your post. Do let us know the test result for the Google Drive connections with the HTTPS Persistence rule and if you have the step to reproduce the disconnection issue do let us know.

I’m using google driver as well with load balance 3 WAN connections and so far no issue found.

Thank You


#14

It seems like we are still having DNS related problems that are effecting the performance and reliability with our 4 WAN / 4 ISP scenario.

Although disabling the DNS Proxy & Cache on the Peplink showed a significant improvement initially, we now see that some of our client machines are experiencing extreme slowness when trying to access various websites. If these users Flush their local DNS cache, the speed and reliability return to normal.

Therefore, we see that the DNS info is being cached locally and that, while the fetched info might initially be suitable for the outbound rule (persistence by source across 4 WANs), the cached DNS info outlasts the outbound rule “persistence” and therefore makes the performance very unreliable over time.

I would appreciate receiving any recommendations. I will also be opening a support ticket.

Thanks.


#15

Hi,

We will followup with you using support ticket. Just worry it may cause by external factors for example cellular WAN disconnection, DNS resolve issue for certain WAN and others.

Thank You