Share via

Azure Load Balancer: SourceIP Session Persistence Not Working Across Multiple Ports for FTP Passive Mode

Manakkal. Subash 60 Reputation points
2026-02-09T03:15:24.27+00:00

We have 33 load-balancing rules on an Azure Standard Internal Load Balancer covering ports 21, 22, and 5000 through 5030. Every rule uses SourceIP (2-tuple) session persistence and targets the same backend pool with two pods. Question: Does Azure Load Balancer ensure that traffic from the same client IP always goes to the same backend across all rules, or does each rule keep its own independent session/persistence table? Why this matters to us - In FTP passive mode, two separate TCP connections must land on the same backend. First, the control connection is made to port 21. Then, the client opens a new connection to a different port (for example, 5015) for data transfer. If these two connections are sent to different backends, the data connection fails because only the pod that handled the control connection is aware of the FTP session. What we observed - With a single replica, FTP works consistently. With two replicas, data connections fail about half the time with ECONNREFUSED. Our setup: Azure Standard Internal Load Balancer, AKS pods in a StatefulSet with two replicas, SourceIP persistence on all rules, floating IP enabled on all rules, health probes are healthy, and the path is Client to Corporate Firewall to Azure ILB to Pods. What we have verified: All 33 rules have loadDistribution set to SourceIP, all use the same backend pool, everything works perfectly with a single replica, and all health probes pass on every port. Core question: With SourceIP (2-tuple) persistence, the hash uses (source IP, destination IP). Since the control and data connections share the same source IP and the same destination IP (the ILB frontend), shouldn’t they produce the same hash and be routed to the same backend? Is session persistence enforced per rule, or is it shared across all rules on the same load balancer? Thank you.
Subash Manakkal

Azure Load Balancer
Azure Load Balancer

An Azure service that delivers high availability and network performance to applications.

0 comments
Answer accepted by question author
  1. Venkatesan S 6,350 Reputation points Microsoft External Staff Moderator
    2026-02-09T04:40:30.4433333+00:00

    Hi Manakkal. Subash,

    Thanks for reaching out in Microsoft Q&A forum,

    Does Azure Load Balancer ensure that traffic from the same client IP always goes to the same backend across all rules, or does each rule keep its own independent session/persistence table?

    • Each of those 33 load-balancing rules runs its own independent session persistence table with SourceIP (2-tuple hashing on source IP + destination IP). Even though your FTP control connection on port 21 and data connection on, say, 5015 come from the same client IP to the same ILB frontend IP, they hit different rules, so the LB treats them separately and picks backends independently. With two healthy pods, that's a coin flip per rule: control might land on Pod A, data on Pod B half the time, boomECONNREFUSED because only Pod A knows the FTP session state. Single replica? No split, everything works fine.
    • Why exactly?: The hash is consistent within a single rule for repeat flows from that client on that port, but there's zero sharing across rules no global "this client IP always gets Pod A" mapping, even with the same backend pool. Floating IP helps with direct returns but doesn't bridge rules. Your corporate firewall might add SNAT quirks, but consistent source IP points squarely at per-rule isolation.
    • Quick troubleshooting: Grab NSG flow logs or tcpdump on pods to see exactly which pod each connection hits by port. Test bumping to Default (5-tuple) mode for source-port affinity, though it's still per-rule and resets on new TCP handshakes.
    • For fixes: App Gateway v2 with L7 cookie affinity handles cross-port stickiness way better. Or share FTP state across pods via Redis, proxy everything through one service, or just go SFTP on port 22 (stays in one rule). Standard ILB just isn't built for protocols like passive FTP that jump ports.

    Reference:

    Kindly let us know if the above helps or you need further assistance on this issue.

    Please do not forget to 210246-screenshot-2021-12-10-121802.pngand “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

    1 person found this answer helpful.
    0 comments

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.