I am unable to access the Apple App Store via laptop or iOS device when connected to speed fusion, I get the “Cannot Connect to App Store”. Has anyone seen this?
MAX-BR2 PRO
Firmware 8.3.0 build 5229
WAN 1
CELL1
CELL2
1 Like
Yes, that issue is easily reproducible. We have a lengthy lists of entities which will either not accept connections via SF (or from Fusion Hubs in data centers) or will accept them but then require the user to play the Captcha game. Our strong suspicion is that the destination hosts looks at the ASN from which you are coming and if it does not like it your traffic goes into a black hole. You may get an error message (“forbidden” is common) or you may get nothing at all. In the case of Apple, one can make it their web site via SFC but FW updates will fail, for example.
I’ll mention that one way we have resolved this is to place a good Peplink router in a location with good WAN(s) – not a data center – and essentially use it as a hub or concentrator. So, the other side will see the traffic coming from a “regular” ISP rather a location they consider suspicious. Or, simply use outbound policy to route your traffic to Apple via one (or more) of the WANs rather than SF.
1 Like
You wrote “Or, simply use outbound policy to route your traffic to Apple via one (or more) of the WANs rather than SF.”
Can you give an explicit example of a policy to do this? I have tried overcoming not being able to access a few sites, for example, Lowes search, over SF Protect by adding an outbound policy to route domain=lowes.com to my fixed WAN (T-Mobile 5G) rather than my SF bonded connection (bonding T-Mobile 5G + Verizon LTEA cat-12). I asked about his earlier this evening at Peplink | Pepwave - Forum
thanks!
greg
Well, I’ll tell you what we do … For known “problem sites” (and, yes, Lowes is one of them) we dimply direct traffic destined for the known “problem server” to another WAN or tunnel. Here’s an example from one of our clients. They send most traffic out via a SFC tunnel. However, they found this would “break” delta.com. So, this is the rule that "fixes “delta”:
In this case the traffic will go via Spectrum (cable internet) and if that WAN is not healthy, it will be directed to the Transit (cellular.)
What I suspect you may be “missing” is this: Once a connection fails the paranoid checks on the other end you are not likely to succeed with making a connection to that site by via any WAN until you erase the cookies from your browser. I think Lowes is one of those, and I know two financial institutions and several other e-commerce sites that behave that way.
1 Like
Thanks Rick for both the outbound policy example and the cookie comment. I had just gotten this to work myself (I had tried something similarly using Enforced algorithm forcing specific WAN usage (avoiding SpeedFusion) for domain lowes.com, but I had placed that rule below the “SpeedFusion VPN” (fixed positional) rule. After moving my rule up above the "SpeedFusion VPN (fixed positional) rule, raising my rules priority, I was able to get to Lowes without the errors.
It would be great to have a list of sites that need to avoid using SpeedFusion VPNs. I am building such a list one by one right now.
thanks
greg
OK, good. One must remember that OBP rules are interpreted from the top down. As soon s one rule “fires” all subsequent rules are ignored. Glad it’s working and you got past another over-active sales prevention department. ;<)