How to Restrict On-Premises Access to Specific Endpoints in a Hub-and-Spoke VNet Architecture with Site-to-Site VPN?

Question

Hi,

I have a question related to this topic: How to Allow and Restrict Resources in Site-to-Site VPN.

Description:

I have a VNet with a VPN Gateway set up, which acts as a hub and has peerings with three other VNets that host my production, testing, and development resources. Within each of these VNets, there are specific endpoints that the on-premises device should have access to:

• Production: 10.100.1.2
• Testing: 10.100.2.2
• Development: 10.100.3.2

According to the first topic, I should modify the NSG rules in all three VNets. However, I found another topic: Site-to-Site VPN Subjects to NSG, which suggests that once traffic enters the Azure network via the VPN gateway in the hub VNet, it is treated as originating from within the Azure network itself. Consequently, my NSG rules would not work as intended, and the on-premises device would have access to all my resources.

What is the proper way to address this issue?

Answer 1

@11-4688

Thank you for reaching out.

I understand you have question about restricting access to your Azure Resources from your on-prem which is connected Azure using S2S VPN.

I think the NSG rules should work in this scenario. From the 2nd post Site-to-Site VPN Subjects to NSG the NSG rules did not work because the customer there used Virtual Network Service tag which includes the on-prem private network as well. You can use the IP address spaces in the NSG to apply the required restrictions. As shown in the example below.

Assuming your on-prem private network is 172.16.0.0/24 then you can set up inbound NSG rule as below

Where Priority 110 allow the communication from on-prem( Source IP 172.16.0.0/24) if the destination IP address is 10.100.1.2, 10.100.2.2, 10.100.3.2

Another Priority 200 deny the communication from On-prem ( Source IP 172.16.0.0/24) where destination is any IP address.

As NSG Rules are processed in priority order, with lower numbers processed before higher numbers, because lower numbers have higher priority. Once traffic matches a rule, processing stops. As a result, any rules that exist with lower priorities (higher numbers) that have the same attributes as rules with higher priorities aren't processed.

In the example above when rule with priority 110 allows communication rule with priority 200 is not processed and the request is allowed.

A few points to consider here:

• Network security groups (NSGs) on the Azure VPN gateway subnet are not supported. Associating a network security group to this subnet might cause your virtual network gateway (VPN and ExpressRoute gateways) to stop functioning as expected.
• If you can use following tools to troubleshoot any NSG related connectivity issue:
• IP flow verify : It's a quick and simple tool to diagnose connectivity issues to or from other Azure resources, the internet and on-premises environment.
• NSG flow logs: It's vital to monitor, manage, and know your own network so that you can protect and optimize it. You need to know the current state of the network, who's connecting, and where users are connecting from.

Hope this helps! Please share screenshot of the NSG rules if the connectivity issue still persists. Thank you!

---

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.