Weight WAN load balancing to match link capacity

I rarely start dual-WAN tuning with “set both weights to 1.”

I start with:

• What’s the purpose?
• What did we buy on each link?
• Who feels pain at peak — and on which pipe?
• What should “fair” mean if it means capacity, not session count?

Equal weights look fair in the UI. On unequal links they are not fair in practice. pfSense-style load balancing splits connections, not megabits. So a ~250 Mbps link and a ~100 Mbps link at weight 1 / 1 still send about half of new sessions down the thinner pipe.

Context

The easy path

Turn on load balancing, leave weights equal, trust the green status.

Example I use

• Primary ~250 Mbps
• Secondary ~100 Mbps
• Equal weights → about 50% / 50% of new sessions
• Capacity share → about 71% / 29% of the bandwidth you paid for

What I watch for

At peak, the slower link is full while the faster link still has room — and the firewall still says load balancing is on.

How I look at the system

new sessions split by weight
        →  1:1 sends ~half to the thin link
        →  thin link fills first
        →  users feel it; the checkbox still looks fine

The purpose is usable capacity at peak, not a pretty 50/50 graph.

What I proposed

Weight the gateways to rated capacity. Keep both in tier 1. Confirm with real daytime traffic.

250 : 100  ≈  5 : 2

gateway A weight = 5   (~71% of new sessions)
gateway B weight = 2   (~29% of new sessions)
tier               = 1 / 1   (active-active)
sticky             = off     (when you want sessions to rebalance)

What has to agree

• Weights 5 and 2 — session share follows capacity share.
• Same tier — both links work in active-active, not only as backup.
• LAN rule uses the gateway group — otherwise the weights do nothing.
• A soak under daytime load — policy is a guess until the graph matches.

Why not failover only?

You paid for two links. Failover leaves the second idle until an outage. Capacity-aware balancing is how both earn their keep — if the graph proves it.

Limits I stay honest about

Connection-based load balancing has a ceiling. I do not oversell it.

• It will not split one large download across both WANs.
• With sticky sessions off, some apps may ask users to sign in again after a path change — acceptable when the goal is rebalance, but expect it.
• Chasing a “perfect” ratio past 5:2 is usually waste — match the purchase, then stop.
• Saving weights without watching graphs is not verification.

The bar: weights match capacity, health stays clean, graph lands near the ratio.

What “done” means

Not “weights saved.”

Under real daytime load:

• Graphs near ~71% / ~29%, not 50/50
• Slower link not pegged while the primary still has headroom
• Gateway health: stable RTT, no sustained packet loss

If the graph matches the pipes you bought, load balancing did its job — usable capacity, not cosmetic fairness.