Technical Anshu
Tutorials Blog
🏦 Banking Fix

Banking and UPI Sites Breaking on Dual WAN Sticky Session Fix

After combining two lines, downloads feel great — but the bank logs you out mid-transfer and UPI payments fail at the last step. This is the single most common side effect of load balancing, and it has a clean, standard fix.

✍️ Technical Anshu🪟 Windows 10 / 11⏱️ 8 minute read
🎥 Watch the full process in the video — combining 2 connections with real testing, step-by-step

A bank does not see 'you'. It sees a session arriving from one public IP address. With load balancing, your login request may leave via line 1, and the very next click — the OTP page, the confirm button — via line 2, from a different public IP. To the bank's security system that looks like a hijacked session, so it kills the session instantly. The fix is to make sessions sticky: once a session starts on a line, it stays on that line.

What the bank sees — one user, two identities
1️⃣ Login requestvia WAN1 — IP 103.x.x.14
2️⃣ OTP submitvia WAN2 — IP 49.x.x.201
⛔ Bank responseSession expired for security reasons
✅ With sticky sessionsEvery step stays on WAN1
Banks bind your login to one IP address — a mid-session IP change looks like an attack
1

Turn On Session Persistence (Sticky Sessions)

  1. Open the router's Dual WAN / Load Balance settings
  2. Find the option named Session Persistence, Sticky Sessions, or Source-IP based balancing (names vary by brand)
  3. Enable it — now all sessions from one device to one destination stay on the same WAN for a set time
  4. Save and restart the router if it asks

This one setting fixes most banking, payment and login problems on dual-WAN setups, because a whole visit to one site now keeps a single public IP.

2

Stronger Fix — Pin Banking Traffic to One Line

If a particular bank or payment site still misbehaves, give it a dedicated rule:

  1. In the router, open Policy Routing / Traffic Rules
  2. Create a rule: source = your PC or the billing PC, destination port = 443 (or the bank's domain, if the router supports domain rules), WAN = WAN1 only
  3. Place this rule above the general load-balance rule — order matters
  4. Now every secure session from that PC always leaves through one line, while everything else still load-balances

For a shop, the cleanest version of this idea is: the billing PC always uses one fixed line, and the rest of the network enjoys both.

3

UPI Apps and Payment Gateways on Phones

Phones on the shop or home Wi-Fi suffer the same issue during UPI payments:

  1. The same sticky-session setting protects phones too — it works per device, not per app
  2. If a payment app still fails, pin the phone's IP to one WAN with a policy rule, the same way as the billing PC
  3. As a field test, switch the phone to mobile data for one payment — if it succeeds instantly, your diagnosis is confirmed

Never 'fix' this by disabling the bank's security or using unknown VPN apps for payments — the router rule is the correct layer.

4

Verify the Fix

  1. Open a command prompt and run curl ifconfig.me several times over a few minutes — during one browsing session your public IP should stay stable per destination
  2. Log in to the bank, open two or three pages, and complete a small test action
  3. Ask the family or staff to report any logout for a day before declaring victory

If logouts continue even with persistence on, check whether the router is rebooting or the line itself is flapping — an unstable line changes the story completely.

🔴 Never solve banking failures by turning security off. The problem is your two public IPs, not the bank. Sticky sessions or a one-line rule for banking traffic fixes it properly, in the router, for every device at once.

🎥 Watch the Complete Video Guide

The video shows the dual-line setup these rules belong to — watch how the connections are combined before you add banking rules on top.

▶️ Watch Full Video
❓ Common Questions (FAQ)

Why do I get logged out of net banking after combining two lines?

Your session reaches the bank from two different public IP addresses as the load balancer moves requests between lines. The bank treats an IP change mid-session as a security risk and ends the session. Enabling sticky sessions in the router fixes it.

Does sticky session slow down my combined speed?

Barely. One session was never going to use both lines anyway — that is how load balancing works. Persistence only stops the balancer from moving a live session between lines, which is exactly what you want for logins and payments.

UPI payment fails on Wi-Fi but works on mobile data. Is it the same issue?

Yes, very likely. The payment session is being split across your two lines. Turn on session persistence in the router, or pin your phone to a single WAN with a policy rule, and test the same payment again on Wi-Fi.

This guide is based on the Technical Anshu video on combining 2 LAN connections • Stuck on a step? Ask in the video comments — the community helps there 🙏