Issue adding Virtual Network to Azure SQL

Jeff Fazio 31 Reputation points
2023-05-15T16:15:28.1233333+00:00

I am adding VirtualNetworks that will be allowed to connect to a Azure SQL instance. I have added 7 without any problem but when I try to add this one, I am getting an error. I have already added Microsoft.SQL to the Subnet.

Failed to update vnet rules for server: SQLServer. ErrorCode: 500 ErrorMessage: Gateway authentication failed for 'Microsoft.Sql'. Diagnostic information

Azure SQL Database
{count} votes

1 answer

Sort by: Most helpful
  1. ShaktiSingh-MSFT 14,186 Reputation points Microsoft Employee
    2023-05-16T08:48:01.36+00:00

    Hi
    Jeff Fazio
    •,

    Welcome to Microsoft Q&A forum and thanks for using Azure services.

    As I understand, you are facing issue in adding Virtual Network to Azure SQL Managed Instance.

    Please correct me if my understanding is different to what you meant.

    Regarding this error, Failed to update vnet rules for server: SQLServer. ErrorCode: 500 ErrorMessage: Gateway authentication failed for 'Microsoft.Sql'. Diagnostic information, I would suggest you to check below points:

    1). Make sure there are no other resource types present inside the subnet other than Azure SQL Managed Instance.

    Currently we do not support placing a managed instance in a subnet that already contains other resource types.

    2). The subnet in which SQL Managed Instance is deployed must have the following characteristics:

    • Dedicated subnet: The subnet SQL Managed Instance uses can be delegated only to the SQL Managed Instance service. The subnet can't be a gateway subnet, and you can deploy only SQL Managed Instance resources in the subnet.
    • Subnet delegation: The SQL Managed Instance subnet must be delegated to the Microsoft.Sql/managedInstances resource provider.
    • Network security group: A network security group must be associated with the SQL Managed Instance subnet. You can use a network security group to control access to the SQL Managed Instance data endpoint by filtering traffic on port 1433 and ports 11000-11999 when SQL Managed Instance is configured for redirect connections. The service automatically provisions rules and keeps them current as required to allow uninterrupted flow of management traffic.
    • Route table: A route table must be associated with the SQL Managed Instance subnet. You can add entries to the route table to route traffic that has on-premises private IP address ranges as a destination through the virtual network gateway or virtual network appliance. The service automatically provisions entries and keeps them current as required to allow uninterrupted flow of management traffic.
    • Sufficient IP addresses: The SQL Managed Instance subnet must have at least 32 IP addresses. For more information, see Determine the size of the subnet for SQL Managed Instance. You can deploy managed instances in the existing network after you configure it to satisfy the networking requirements for SQL Managed Instance. Otherwise, create a new network and subnet.
    • Allowed by Azure policies: If you use Azure Policy to prevent resource creation or modification in a scope that includes a SQL Managed Instance subnet or virtual network, your policies must not prevent SQL Managed Instance from managing its internal resources. The following resources need to be excluded from policy deny effects for normal operation:
    • Resources of type Microsoft.Network/serviceEndpointPolicies, when resource name begins with \_e41f87a2\_
    • All resources of type Microsoft.Network/networkIntentPolicies
    • All resources of type Microsoft.Network/virtualNetworks/subnets/contextualServiceEndpointPolicies
    • Locks on virtual network: Locks on the dedicated subnet's virtual network, its parent resource group, or subscription, might occasionally interfere with SQL Managed Instance management and maintenance operations. Take special care when you use resource locks.
    • Replication traffic: Replication traffic for auto-failover groups between two managed instances should be direct and not routed through a hub network.
    • Custom DNS server: If the virtual network is configured to use a custom DNS server, the DNS server must be able to resolve public DNS records. Using features like Azure AD authentication might require resolving more fully qualified domain names (FQDNs). For more information, see Resolving private DNS names in Azure SQL Managed Instance.

    3). If trying for Global virtual network peering: Virtual network peering connectivity across Azure regions doesn't work for instances of SQL Managed Instance that are placed in subnets that were created before September 9, 2020.

    Check the number 8th Instance if created before above mentioned date.

    4). You can create a managed instance only in virtual networks created through the Azure Resource Manager deployment model. Azure virtual networks created through the classic deployment model are not supported. Calculate subnet size by following the guidelines in the Determine the size of subnet for SQL Managed Instance article. You can't resize the subnet after you deploy the resources inside.

    After the managed instance is created, you can move the instance to another subnet inside the same Vnet or across vNets, but moving the instance or VNet to another resource group or subscription is not supported.

    You should determine the size of the subnet for SQL Managed Instance before you deploy the first instance. You can't resize the subnet after you put the resources inside.

    If you plan to use an existing virtual network, you need to modify that network configuration to accommodate SQL Managed Instance. For more information, see Modify an existing virtual network for SQL Managed Instance.

    After a managed instance is created, moving the managed instance or virtual network to another resource group or subscription is not supported.

    You can move the instance to another subnet inside the same Vnet or a different Vnet.

    5). Though it's possible to deploy managed instances to a subnet with a number of IP addresses that's less than the output of the subnet formula, always consider using bigger subnets instead. Using a bigger subnet can help avoid future issues stemming from a lack of IP addresses, such as the inability to create additional instances within the subnet or scale existing instances.

    Hope this information helps.

    If the answer did not help, please add more context/follow-up question for it, and we will help you out. Else, if the answer helped, please click 'Accept answer' so that it can help others in the community looking for help on similar topics.

    Thank you.

    0 comments No comments