This can relate to private dns zones yes. My general recommendation would be to create a private dns zone for each type of private endpoint you use, for exampel private endpoints for storage accounts, and then link those to both the hub vnet and all vnets where that type is in use.
Thank you for the video! I have a question regarding the ruleset link you created. According to Microsoft's documentation: "If you use the ruleset link option and there is a forwarding rule with the inbound endpoint as destination, do not link the forwarding ruleset to the Hub VNet. Linking this type of ruleset to the same VNet where the inbound endpoint is provisioned can result in a DNS resolution loop." Why did you direct your link to the Hub VNet instead of creating the link to the Spoke VNet, which might have been simpler?
I believe my thinking was that by linking it to the hub vNet instead of the spoke vNet, any additional spokes created would not need to have a link to them as well. At least as long as they point to the inbound endpoint for DNS. That way the setup scales better since you have less links. Even though that can lead to DNS resolution loops, that should be limited to queries originating from the onprem vNet and it can be avoided by having the DNS server there (10.0.0.5) always use itself as the primary DNS server. That being said, if in doubt you should follow the documentation. That way you will have an easier time if you ever need to create a support ticket for anything in the setup 😉
Curious if you've tried this with a VNet Gateway using P2S (OpenVPN using Entra for auth)? Does not work for me, I can see the query go out on a capture, but there's no response from the private resolver. If I set up a VM to forward requests to either Azure DNS or the private resolver, that works. Seems like Azure is blocking the response if it tries to go back out through the Gateway. I've had a ticket open for 125 days now and their support can't figure it out.
Hi, I couldn't get it to work on my P2S setup even though I had configured everything perfectly. Decided to move on to other parts of the networking, and I finally got it to work after setting up the firewall in the hub VNet. In the firewall config, I enabled dns application on policies and further in, I enabled DNS proxy. I then changed the DNS server address in my VPN XML config file to the private IP address of the firewall. Now it works perfectly the way it should and I can ping to VMs on my spokes using their FQDNs. It looks like the VPN client cannot access the inbound endpoint for some reason, but if you have another azure resource acting as a DNS proxy, it will work. Azure Firewall is very expensive, so it might be cheaper to set up a cheap VM on your hub VNet to act as an intermediary, but I didn't look into it further.
How are you handling DNS in your environments? Are you using private resolver? A vm in azure? Static records in DNS?
next question 🙂: do we need change on all vnets dns server to inbound address? include the inbound and outbound connected vnets?
Yes, all vnets would need to have DNS pointing to the inbound address. And a way of reaching it of course :)
@@PetterTech which dns server address should be on vnet for inbound?(private resolver)
does this have any relation with private dns zone when we create private endpoint? shall we create a new private dns zone for each endpoint ?
This can relate to private dns zones yes. My general recommendation would be to create a private dns zone for each type of private endpoint you use, for exampel private endpoints for storage accounts, and then link those to both the hub vnet and all vnets where that type is in use.
Thank you for the video! I have a question regarding the ruleset link you created. According to Microsoft's documentation: "If you use the ruleset link option and there is a forwarding rule with the inbound endpoint as destination, do not link the forwarding ruleset to the Hub VNet. Linking this type of ruleset to the same VNet where the inbound endpoint is provisioned can result in a DNS resolution loop."
Why did you direct your link to the Hub VNet instead of creating the link to the Spoke VNet, which might have been simpler?
I believe my thinking was that by linking it to the hub vNet instead of the spoke vNet, any additional spokes created would not need to have a link to them as well. At least as long as they point to the inbound endpoint for DNS.
That way the setup scales better since you have less links. Even though that can lead to DNS resolution loops, that should be limited to queries originating from the onprem vNet and it can be avoided by having the DNS server there (10.0.0.5) always use itself as the primary DNS server.
That being said, if in doubt you should follow the documentation. That way you will have an easier time if you ever need to create a support ticket for anything in the setup 😉
Curious if you've tried this with a VNet Gateway using P2S (OpenVPN using Entra for auth)? Does not work for me, I can see the query go out on a capture, but there's no response from the private resolver. If I set up a VM to forward requests to either Azure DNS or the private resolver, that works. Seems like Azure is blocking the response if it tries to go back out through the Gateway. I've had a ticket open for 125 days now and their support can't figure it out.
I haven't tried it with P2S yet no. I'll have to add it to my list of things to try :)
Hi, I couldn't get it to work on my P2S setup even though I had configured everything perfectly. Decided to move on to other parts of the networking, and I finally got it to work after setting up the firewall in the hub VNet. In the firewall config, I enabled dns application on policies and further in, I enabled DNS proxy. I then changed the DNS server address in my VPN XML config file to the private IP address of the firewall. Now it works perfectly the way it should and I can ping to VMs on my spokes using their FQDNs.
It looks like the VPN client cannot access the inbound endpoint for some reason, but if you have another azure resource acting as a DNS proxy, it will work. Azure Firewall is very expensive, so it might be cheaper to set up a cheap VM on your hub VNet to act as an intermediary, but I didn't look into it further.
You are a really good teacher. Dont stop!
Thank you 👍
Petter, this is really good content
Thank you! Really glad to hear that ❤️
thank, like your content! helps a lot
Glad to hear that!