I have an access problem between two resources located in the same virtual network.
Concretely, I have a VM with an SQL instance on the SubNet "Data" inside the VNet "Common".
I have another VM with a Reporting Service instance on the "Front" SubNet, also inside the "Common" VNet.
The two VMs are therefore under the same VNet but under two different SubNets.
When I try to connect to the SQL database from the Reporting instance, I get an error message telling me that it cannot be accessed.
I solved the problem by adding, by hand, a rule in the NSG of my SubNet "Data" to allow communications from the IP of the "Reporting" VM on the SQL port.
And as soon as I do that, it works. I can connect to the SQL database which is on the SubNet "Data" from the Reporting of the SubNet "Front".
But what I don't understand is that my SubNet "Data" already contains an inbound rule on its NSG that allows all inbound connections (on all ports) if the call is from the virtual network. It is a rule present by default (called AllowVnetInBound).
Normally, I shouldn't have to add a specific rule for my VM Reporting. Especially since my VM has a dynamic IP, so this solution is not viable.
What am I missing?
Why the rule "AllowVnetInBound" which takes as source "VirtualNetwork" not enough?
Edit :
This is the NSG inbound rules for "Data" SubNet. I have outlined in green the rule that I must add for the communication to work. Without this rule, communication does not work.
By default, the VM in subnet "Data" should be able to communicate to the VM in subnet "Front" as both the subnets are in the same Virtual Network. We do not need to create any additional inbound or outbound rules
Sometimes, even though the VMs are in same virtual network, they might not be able to communicate to each other because of the firewall settings inside the VMs
So, the firewall needs to be turned off inside both the VMs so that both the VMs will be able to communicate to each other
Once the firewall inside both the VMs is turned off, you would be able to connect to the SQL database from the Reporting Instance
Is there any other custom lower priority rules above the default "AllowVnetInbound" rule?
This kind of scenario typically happens when you have added a lower priority custom rule on top of the default rule (like "AllowVnetInbound"), which logically would be blocking the default rule.
If this does not answer your question, please share a screenshot of the NSG rules in the earlier state before you set up the custom rule manually.
If this answers your questions, please mark the explanation as accepted.
subnets within one virtual network can communicate with each other without any extra configuration
Related
We have our application and database in different VNETs in different subscription.
Also we have different environments (Pre-Production and Production).
Currently the database for PROD and PRE-PROD is in different subnet but same VNET.
I see we can have peering at VNET level.
We want the peering between the application and database at subnet level so that PRE-PROD application should not be able to connect to PROD database and vice-versa.
From Microsoft documentation:
Azure routes traffic between all subnets within a virtual network, by default. You can create your own routes to override Azure's default routing.
https://learn.microsoft.com/en-us/azure/virtual-network/tutorial-create-route-table-portal
You would want to look at network segmentation patterns. You can achieve basic microsegmentation by using Network Security Groups in Azure.
Based on your question, I assume you want to allow traffic only from one subnet into another subnet (over a peered network though, but that does not matter much) - and maybe even only allow one database port to be accessed from your application subnet - and lock everything else down.
This approach is described here: https://learn.microsoft.com/en-us/azure/architecture/framework/security/design-network-segmentation
You would want to create one NSG per subnet, make a rule to block all inbound traffic and then allow only traffic that is required. Note that NSG's are stateful, so you do not need to specify outbound rules for your traffic. Also make sure you apply the rules in the right order from top to bottom. The rule with the lowest id is applied first.
I know NSG can easily do that, but for some reason I can not use NSG, is there any other alternative can do the same? Firewall within VM might also work, but it's better to control that in Azure level, so I don't have to login to the VM so config that.
You can use Application Security Group (ASG). ASGs are used within a NSG to apply a network security rule to a specific VM or a group of VMs.
You can start here https://learn.microsoft.com/en-us/azure/virtual-network/application-security-groups
I'm trying to understand the Network Security Groups and Application Security Groups. What I'm trying to achieve is I have a basic set up as below.
In my vnet, I have 2 subnets which are front-end and back-end and I have 2 NSGs that each subnet is assigned to.
Let's say I decided to allow RDP requests on my "back-end" subnet only for requests coming from the "front-end" subnet and deny any other RDP requests coming from other subnets.
I know that if I create ASGs and assign the FrontEnd VM and BackEnd VM an application security group then I can create a rule on NSG which is to allow RDP request from one ASG to the other ASG to achieve this but if you have dozens of VMs in a subnet then you wouldn't want to waste time to assign an ASG to every VM.
Is there a way to define a rule on a subnet that allows specific requests coming from other subnets?
create a rule and set the source to VirtualNetwork that will allow anyone from inside the Virtual Network (and peered ones) to send that type of traffic. If you want subnet granularity - you'd have to use subnet IP address ranges to allow\deny specific traffic patterns. You might also want to override the default rule to allow anything inside the virtual network
I have two vnets setup in azure, one in UK South and one in UK West. I have a single VM setup in each region and attached to the respective vnet.
I have peered the two vnets, using the peerings option in the blades on the azure portal. However I am still unable to ping one VM from the the other.
I have NOT setup any Gateways as I understand this is not needed and I can see form the Effective Routes on the Network Interface for each VM that the VNetGlobalPeering has been established
Has anyone managed to get this working? Or can someone point me the the direction of what I am doing wrong?
You dont need a gateway for this to work. what you need is to peer them and check the Configure virtual network access settings checkbox and configure your OS level firewall rules to allow the traffic.
Also, make sure NSG are not explicitly blocking that traffic
ps. you can follow this: https://learn.microsoft.com/en-us/azure/virtual-network/tutorial-connect-virtual-networks-portal
VM1 needs to talk to VM2 on port 4567 (In Azure). Both VMS are on the same subnet. Can I just create an inbound rule on the NSG attached to both Vms that says open port 4567? Will this work?
Or do I also need to log onto both VM's and configure the firewall rules?
What is the proper way to configure this? in terms of best practice.
Yes, you have to, because NSG doesnt talk to your VM to alter settings on it. NSG is an Azure level firewall.
There are subnet or network interface level NSG in Azure with ARM model. Usually we just use the subnet level NSG that will take effect on all the VMs in the same subnet. If the VMs in the same subnet, by default, the traffic from VMs can pass though the NSG each other as there is an AllowVnetInBound rule.
Windows firewall is another firewall inside the VMs. You can configure it or not configure it. Suggest to configure it for more security. If you want to open port 4567 from VM1 talk to VM2, you only need to open it in VM firewall rule if you have configured it.
Ref: Azure Network Security Groups (NSG) – Best Practices and Lessons Learned