I'm setting up a new VPN connection to our on-prem environment that's linked to Azure. While I can connect to most Azure resources without issues, I'm having trouble reaching our Azure SQL Managed Instance (MI), which is on a different virtual network than the GatewaySubnet. I've already established peering between the networks and confirmed that other resources on this network are accessible. However, I can't connect to the MI.
I've checked the network security group (NSG) rules for the MI's virtual network. They explicitly allow traffic from the IPs assigned when connected to our VPN to the MI's subnet, but I'm still getting errors about not finding the service. Oddly enough, devices on the internal network can access the MI, and another VPN service connected to Azure also reaches it just fine.
Using Wireshark, I've seen the correct source IP when sending packets, and the NIC responds appropriately for the SQL MI. When I adjusted the NSG to allow traffic from the source VirtualNetwork to the SQL MI's subnet, connectivity was restored.
I'm curious if the GatewaySubnet modifies source IP information for incoming packets. It seems inconsistent since other traffic is unaffected. Moreover, I find it uncomfortable allowing the source VirtualNetwork in my NSG. I'm trying to understand why an explicit source IP was denied while the VirtualNetwork source was accepted. Any insights would be hugely appreciated!
5 Answers
Are you utilizing BGP? You might need to set a static route in the subnet's route table where your SQL MI instance sits. Also, double-check that the SQL MI's firewall settings aren't blocking connections from all sources. If you're employing Azure Firewall, check the logs to see if traffic is being dropped. Remember that NSGs are non-stateful and only operate at layer 4, so you'll need to configure bi-directional rules. If you're on a hub-and-spoke architecture, the traffic will route through the hub network and then forward to the destinations in the spokes. For proper logging with VPN Gateway and Azure Firewall, enable diagnostic settings and send logs to a log analytics workspace.
I've encountered a similar issue before. It turns out the problem could be that you haven't enabled "Enforce UDR" on the subnet with the SQL Private endpoint. This feature is often disabled by default and can mess with traffic flow. The traffic makes it to the SQL server, but if there's no response due to the lack of UDR being enforced, it'll just drop. By the way, make sure that your VNet peering settings are correct, especially allowing remote peering connections to use your gateway.
You should definitely use the VirtualNetwork service tag for your NSG rules on the subnet where the Azure SQL Managed Instance resides to ensure proper access from the VPN.
Related Questions
How To Get Your Domain Unblocked From Facebook
How To Find A String In a Directory of Files Using Linux