I'm running a proprietary client/server application on a single instance windows server 2k8R2 azure VM.

The client is very dependent on a connection with the server. However if I spend a couple of minutes without any activity, something on the Azure end forcibly closes the connection (as far as I can tell from the logs). I'm not positive if this is a function of azure itself or windows.

Short of implementing some sort of keepalive functionality (which I can't because the software is proprietary), is there anyway I can extend this timeout?

I've seen several references to changing idletimeout for loadbalanced situations, but this is just a single instance.

thanks in advance!

  • What does your Azure network architecture look like? Does your traffic transit a NAT?
    – EEAA
    Jan 22, 2015 at 23:12
  • I would be surprised if Azure was doing this. Do you have any proof that it's Azure, and not your local network? Jan 22, 2015 at 23:23
  • i have a virtual network with a subnet set aside for static addressing, and a reserved IP for the VM. I have seen this happen at 3 different sites (all different networks) as well as my home internet and it behaves the same
    – NoCarrier
    Jan 22, 2015 at 23:26
  • Have you tested on multiple devices? Also, are you accessing the application using a public endpoint, or privately via an Azure virtual network (ExpressRoute, site-to-site, or point-to-site VPN)? Jan 22, 2015 at 23:51
  • yes, multiple different PCs and a couple of macs, connecting to a public endpoint.
    – NoCarrier
    Jan 23, 2015 at 0:02

2 Answers 2


You're hitting a design feature of the software load balancer in front of your VMs. By default it will close any idle connections after 4 minutes, but you can configure the timeout to be anything between those 4 and 30 minutes:

Configurable Idle Timeout for Azure Load Balancer

However, it is a good practice both on the infrastructure and application side to have some kind of keepalives. It will save you more than a headache in the future.

Edit to add that Azure now supports TCP Reset on Idle Connections

  • 2
    It does not close the connections. Rather, it blackholes packets so as far as the sender is concerned, the connection is still open but ACKs are taking long. Sending RST when the routing information is lost would solve this.
    – GManNickG
    Oct 3, 2017 at 22:16
  • 2
    Ah yes. Another one of those "features" that adds zero value, while also being completely non-standard and not even handling the connection drop gracefully (no connection reset?)
    – Basic
    Feb 26, 2019 at 11:49
  • TCP RST is supported since some time now (and I don't work for Microsoft anymore): docs.microsoft.com/en-gb/azure/load-balancer/… Feb 28, 2019 at 12:51

TCP settings for Azure VMs

Azure VMs communicate with the public Internet by using NAT (Network Address Translation). NAT devices assign a public IP address and port to an Azure VM, allowing that VM to establish a socket for communication with other devices. If packets stop flowing through that socket after a specific time, the NAT device kills the mapping, and the socket is free to be used by other VMs.

This is a common NAT behavior, which can cause communication issues on TCP based applications that expect a socket to be maintained beyond a time-out period. There are two idle timeout settings to consider, for sessions in a established connection state:

inbound through the Azure load balancer. This timeout defaults to 4 minutes, and can be adjusted up to 30 minutes. outbound using SNAT (Source NAT). This timeout is set to 4 minutes, and cannot be adjusted. To ensure connections are not lost beyond the timeout limit, you should make sure either your application keeps the session alive, or you can configure the underlying operating system to do so. The settings to be used are different for Linux and Windows systems, as shown below.

For Linux, you should change the kernel variables below. net.ipv4.tcp_keepalive_time = 120 net.ipv4.tcp_keepalive_intvl = 30 net.ipv4.tcp_keepalive_probes = 8

For Windows, you should change the registry values below. KeepAliveInterval = 30 KeepAliveTime = 120 TcpMaxDataRetransmissions = 8

The settings above ensure a keep alive packet is sent after 2 minutes (120 seconds) of idle time, and then sent every 30 seconds. And if 8 of those packets fail, the session is dropped.

Source: https://github.com/wbuchwalter/azure-content/blob/master/includes/guidance-tcp-session-timeout-include.md

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .