How VPN-based load balancing gave my multisite network inconsistent session IDs and the session affinity change that made logins stable again

Everything was working fine—until we scaled up. What started as a simple multisite network turned into a swirling vortex of support tickets, confused users, and mysterious logouts. We were using VPN-based load balancing to distribute traffic across sites. And that’s where everything got weird.

TLDR: Our VPN-based load balancing setup randomly distributed user sessions to different sites, causing inconsistent session IDs and unexpected logouts. Logins became unstable, and users were frustrated. The solution? Implementing session affinity (also called sticky sessions) so users stayed on the same server after they logged in. Stability returned, support tickets vanished, and our Friday nights were peaceful again.

Let’s start at the beginning

We had multiple sites across different regions. Each site had its own servers, databases, and identical codebases. Through a VPN mesh, traffic was balanced between these locations. It looked like a dream setup—at least on paper.

Here’s what we were aiming for:

• Geographical redundancy
• Faster response times for users
• High availability in case a site went down
• Efficient use of global resources

We used a central load balancer connected through VPN to our regional sites. It distributed traffic using a round-robin method. Essentially, every new request could go to any regional node. That seemed fine. Until… it wasn’t.

Then things got messy

Users started complaining they couldn’t stay logged in. One moment they were browsing fine, the next they were sent back to the login screen. Refreshing helped sometimes, but only temporarily. And clearing cookies didn’t fix it.

Our error logs weren’t very helpful either. There were lots of “invalid session ID” messages scattered all over the place. That was our first clue.

What we eventually realized was this:

Closing one TCP session didn’t mean the next one would reach the same server. Our round-robin load balancer blindly shuffled requests—even from the same user—to different sites. Those sites had no shared session data. So if a user got bounced to another site, bam! Their session was gone.

And that led to this endless loop of:

1. Log in on Site A
2. Next request goes to Site B
3. Site B doesn’t know the session → kicks user out
4. User logs in again (this time possibly on Site C)
5. And the cycle repeats…

It was like musical chairs, but with login sessions.

Why session replication didn’t help

We considered syncing session data between nodes. Maybe using Redis or another shared store. That would make every server aware of every session, right?

Theoretically, yes. But practically? Not so much.

Our servers were in different regions. Network latency became a major issue. And syncing session data in real-time across continents wasn’t exactly… speedy. We tried it. It made load times crawl, and things broke even more.

Then there’s this issue: don’t forget time zones, daylight savings, and misconfigured clocks. Sessions caused invalidation dramas we didn’t expect. In short—replicating sessions in real time across VPNs is not trivial.

The eureka moment: Session Affinity

We needed a better strategy—something closer to the user’s experience.

Enter: Session Affinity (also known as sticky sessions 🔒).

This approach ensures that once a user’s request hits one server, all their follow-ups go to the same server. Same backend, same session data, no confusion.

No bouncing = no breakage.

It was surprisingly easy to implement. Most load balancers support it. We enabled IP-based affinity, configured session persistence timers, and crossed our fingers.

And… it worked.

How did we enable it?

Here’s a simplified version of what we changed in our load balancer config:

  session_affinity: enabled
  affinity_type: client_ip
  affinity_timeout: 300s

That means:

• All requests from the same client IP hit the same server
• The session will “stick” there for 5 minutes of inactivity
• If the client disconnects and reconnects within that time, the load balancer remembers where to send them

No shared session store needed. No complicated replication. Just predictable routing.

But wait—what about scale?

That’s a good question! Sticky sessions don’t scale as well in massively distributed systems. But we were okay with that trade-off.

Each site could handle its own local traffic efficiently. Sticky sessions only mattered for logged-in users. For public, non-authenticated views, we let the traffic distribute freely.

In fact, our new setup looked something like this:

• Unauthenticated users: load-balanced across all regions
• Authenticated users: session affinity keeps them “stuck” to one site

This preserved speed and balance for casual visitors but gave a stable experience to logged-in users.

Bonus trick: Geo DNS redirection

To further improve things, we added Geo DNS logic. That way, users were initially routed to the nearest site based on their IP.

Why? So that even sticky sessions would land users on their geographically optimal region the first time around. This gave them better performance from the start. Then session affinity kept them there.

Lessons learned

Looking back, the main mistake was thinking all load balancing is created equal. What works for stateless APIs doesn’t always work for sessions—and definitely not with logins.

Here are a few takeaways:

• Think about state: Are your web sessions stateful or not? That determines your approach.
• Session replication sounds cool, but can be messy. Especially across regions.
• Session affinity can be the simplest fix when you’re running multipoint VPNs.

What changed for us?

After the switch to session affinity, the login issues vanished. Users stayed signed in. Support tickets dropped to zero. And our team could focus on building features instead of debugging why Susan from Chicago was logged out for the 7th time.

It was magical. Simple tweaks, big difference.

Final thoughts

Infrastructure problems can sneak up on you—especially when things scale. VPN-based load balancing sounded smart, but in practice, it broke what matters most: user trust.

Sticky sessions restored that trust. And just like that, our network was peaceful again.

So if your users are mysteriously bouncing out of sessions, and you’ve got multiple points of entry into your system, ask yourself:

Am I sending them on a different path every time?

If the answer is yes—stick ‘em. They’ll thank you.