IP issues with Azure Kubernetes Service Load Balancer over UDP

Marvin Schirrmacher 1 Reputation point

My company is using an Azure Kubernetes Service. We have an internal load balancer in place which should handle UDP communication through a VPN connection:

apiVersion: v1  
kind: Service  
  name: middleware-5683  
    app: middleware  
    env: test  
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"  
  type: LoadBalancer  
  sessionAffinity: None  
  externalTrafficPolicy: Local  
    - name: middleware-5683  
      port: 5683  
      targetPort: 5683  
      protocol: UDP  
    app: middleware  

Regarding this documentation, we currently have option 4 in place, which is labeled "second worst" (why?).

We have a bunch of devices sending messages to the load balancer. These devices receive responses originated from the load balancer IP (, if they send messages in short intervals. This is the behaviour we expect.

When they pause sending, for about a minute or longer, they suddenly start to receive responses from private backend servers (IPs unequal to

[00:02:12.631,286] <dbg> at_cmd.socket_thread_fn: Listening on socket  
[00:02:12.805,114] <dbg> udp_receive: checking for reply from [**]  
[00:05:09.279,113] <dbg> at_cmd.socket_thread_fn: Listening on socket  
[00:05:09.452,972] <dbg> udp_receive: checking for reply from [**]  

Why can this happen? We stumbled across a feature which is called "Floating IP", but the documentation could't help us in this case.

Azure Kubernetes Service (AKS)
Azure Kubernetes Service (AKS)
An Azure service that provides serverless Kubernetes, an integrated continuous integration and continuous delivery experience, and enterprise-grade security and governance.
1,555 questions
Azure Load Balancer
Azure Load Balancer
An Azure service that delivers high availability and network performance to applications.
335 questions
0 comments No comments
{count} votes

1 answer

Sort by: Most helpful
  1. TravisCragg-MSFT 5,656 Reputation points Microsoft Employee

    For your option 4 and why it is the "second worst":

    SNAT Exhaustion. If your application does not have a high load, this is not a concern for you. If it does, you should be able to configure outbound rules for your Azure Load Balancer to resolve this. The doc you linked applies to outbound internet connections, so it is not fully applicable in your scenario.

    The documentation goes into detail about Public load balancer outbound communication, but does not discuss what happens for internal load balancer outbound communication.

    If you need to clearly define the addresses that the responses are sent from, your best bet is through an outbound rule.

    0 comments No comments