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 '15 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? – Trevor Sullivan Jan 22 '15 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 '15 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)? – Trevor Sullivan Jan 22 '15 at 23:51
  • yes, multiple different PCs and a couple of macs, connecting to a public endpoint. – NoCarrier Jan 23 '15 at 0:02
up vote 6 down vote accepted

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.

  • 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 '17 at 22:16

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/Microsoft/azure-docs/blob/master/includes/guidance-tcp-session-timeout-include.md

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.