NSG is allowing traffic but i still see a network timeout

Michael Storry 25 Reputation points
2025-04-24T14:55:59.1233333+00:00

I have a VNET with a couple of subnets in. I am attempting connectivity between Windows servers.

I have an App server in subnet A attempting to connect to a database server in Subnet B. The NSG rules appear correct.

When I run the IP Flow Verify tool it says that access is allowed too.

I have setup NSG Flow logs into a LAW, and the queries here show that the traffic is Allowed.

I have disabled the Windows Firewall on both servers, but still the connection fails.

The error message I get is failed due to Timeout.

I have a MGMT server in subnet C which can connect successfully to the Database server, so I know it is possible.

What else is there that I could check?

Azure Virtual Network
Azure Virtual Network
An Azure networking service that is used to provision private networks and optionally to connect to on-premises datacenters.
2,720 questions
{count} votes

Accepted answer
  1. Shravan Addagatla 690 Reputation points Microsoft External Staff
    2025-04-24T16:25:05.75+00:00

    Hello Michael Storry

    I understand that you are experiencing a connectivity timeout issue when attempting to connect your App server to your Database server, even though the NSG rules seem properly configured and there are no Windows Firewall blocks on the traffic.

    Here are a few things you can check:

    1. Although you mentioned that the NSG rules seem correct, double-check if there are any NSG rules on VM NIC or Subnet level that might be blocking specific ports or IP ranges. So, please make sure that the rules are set to allow incoming and outgoing traffic specifically for the ports being used by your applications.
    2. Use connection troubleshoot and test the traffic from App server in subnet A to a database server in Subnet B and check for the reasons.
    3. If you’re using any virtual appliances or additional routing mechanisms (like UDRs), ensure that they’re not affecting the connectivity. Check if the routing is correct and that no extra elements are blocking or redirecting traffic incorrectly.
    4. If you're using hostnames instead of IP addresses, it's possible that DNS resolution could be causing the timeout. Verify that your servers can resolve the necessary names correctly.
    5. Ensure the connection string used in the App server is accurate and that it specifies the right credentials, server name, port number, etc.

    Since you mentioned that the MGMT server in subnet C can connect to the Database server without issues, it might be helpful to check if there are any differences in configuration, such as security policies or environment variables, between the App server and the MGMT server.

    If still issue persists, please share the below details over private messages for further troubleshooting.

    • What is the source and destination Ips/VNets for both working and non-working scenarios?
    • What ports are being used for the connection between the App server and the Database server?
    • Have you checked for any additional firewalls or security appliances in your network path
    • Please share the screenshots of NIC effective routes of app and database server.
    • Are both servers within the same VNET or different VNets? If they are in different VNets, please make sure VNets are peered.
    • Have you tried accessing the Database server from the App server using its IP address or its hostname? and please share the ping or Test-Net Connection results?
    • Are there any application-specific logs on the App server that indicate more information about the timeout?

    Please add a comment below if you have any further questions.

    If the above information was helpful. Please click "Accept" the answer as original posters help the community find answers faster by identifying the correct answer. 

    0 comments No comments

0 additional answers

Sort by: Most helpful

Your answer

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