In the old days, only “important” traffic was using HTTPS, so setting an outbound policy of with a Peristence rule for TCP / Port 443 made sense: the “important” traffic would stay on a single WAN, and other day to day traffic would be distrubted across WANs.
These days, the vast majority of traffic is on HTTPS.
I’m finding that my HTTPS Persistence Outbound rule is causing many of my client machines to get “stuck” on a single WAN, which effectively reduces the ability to load balance incoming traffic.
I have two WANS:
WAN 1 has 20mpbs upload and 20mbps download (symmetrical fiber)
WAN 2 has 20mbps upload and 400mbps download (cable modem)
My current Outbound Policy:
HTTPS_Persistence (all TCP traffic on port 443)
Default: Weighted balance 10:10
Can anyone suggest a better setup? Basically I’d like to make sure that WAN2 is used for big file downloads. Currently it’s almost never used, most traffic seems to be going in/out on WAN1.
The specific test I’m doing is trying to download a 9GB macOS installer, and it keeps failing, so I keep re-downloading it. Every single time it’s coming in on WAN1. I would expect that my Weighted Balance rule of 10:10 would round-robin it, but it seems like the Persistence rule is overriding it.
Related questions:
Just how “peristent” is the “persistence” rule? Once it starts, does it ever go away?
Do people feel the need for the “persistence” rule any longer? Are there still many websites that don’t funciton properly with it turned off?
The persistence rule is still used and the persistence mode can be modified to “by destination” instead of " by source" for this scenario to help load balance.
By default (source) the algorithm keeps the same user on the same WAN for HTTPs, however changing to destination will help balance HTTPs traffic with only a few users on the LAN.
As @Ron_Case mentioned you can change the HTTPS persistent rule to “by destination”. We have had tried to switch the rule’s default to “by destination” internally, but we found that some “secure” site was not happy about that and even denied access. This happens with:
computer A visits a web site that resolved domain to IP x, via WAN 1 (by the HTTPS persistence rule).
once we have visited the web site and maybe went through the login process, it redirects you to IP y.
Now computer A tries to get to IP y, and since the rule is now by destination, outbound policy would choose to use WAN 2 for visiting IP y.
access is denied, because they are seeing us coming from a different WAN (source IP changed)
So to provide maximum compatibility with those “secure” site, we have to stick with “by source”, unfortunately.
Of course if your HTTPS web site don’t have this “secure” behavior, changing the rule to “by destination” is definitely better.
Agreed. With the popularity of mobile devices, and their constant switching between local Wi-Fi and the cellular networks, most sites that use HTTPS don’t have an issue with the client’s source IP changing any more. However, I do still occasionally run into issues, often government portals are where I see this still happening. In my case, I just create a priority rule targeting the domain for those very rare exceptions.