Network connectivity

Matthew Edinger 0 Reputation points
2025-04-28T13:28:15.81+00:00

Hello,

I tried to open a ticket in the portal about this however it wont let me. It just gives me suggestions but wont move forward with opening a ticket. We had to move our development Vm to a different Subscription and had to give it a new IPV4 address. We have peered it to another subscription that runs all of our infrastructure and set up a route table and still cant connect to it. We need to be able to ping the IP for the Azure FortiGate but we are also having a DNS issue. Our Azure engineer is out and we just lack some knowledge in Azure Networking and we were hoping to open a ticket and work with Microsoft on the issue but again it literally wont let us.

Azure Virtual Network
Azure Virtual Network
An Azure networking service that is used to provision private networks and optionally to connect to on-premises datacenters.
2,720 questions
{count} votes

2 answers

Sort by: Most helpful
  1. UJTyagi-MSFT 930 Reputation points Microsoft Employee
    2025-04-29T05:13:04.72+00:00

    Hi @Matthew Edinger

    Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

    Thanks for raising the issue, I am sorry that you were not able to raise a portal ticket. I have shared with you the URL which will help you to go through the steps to raise a support ticket.

    There is a demo video also on the page which you can follow through.

    https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request

    If you are following all the steps as given in the above link and still not able to create the ticket, kindly check if you have right access on the subscription

    https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request#azure-role-based-access-control

    I see the technical details you have provided about the issue are not sufficient to understand the underlying issue.

    Meanwhile I would need following details to help you on the issue:

    • As i understood from your explanation that you moved a development VM to a different subscription however kindly confirm if you redeploy the VM to new Vnet in new subscription too. As once VM is deployed even though you can move it to another subscription you cannot change its virtual network without redeploying the VM. In a Nutshell subscription change does not mean the virtual network settings of the VM was changes unless it is redeployed/recreated to another virtual network in new subscription.
    • For network perspective kindly focus on Virtual network connectivity rather than subscription as subscription is used for billing, ownership and cost purposes.
    • Kindly confirm When you say you changed the ip address of the VM does that mean you assigned a new static ip address from the same subnet on same Nic assuming the Virtual network was not changed during the movement.
    • Since you mentioned the VM Vnet is peered with another vnet which holds all your all-other infrastructure resources, Kindly check the Vnet peering status between the vnets between the subscriptions, First ensure the peering is in Fully Synchronized and in connected state.
    • User's image
    • If Vnet peering is in connected and in Sync state, kindly check the route table enforced on the development VM subnet has right route with next hop to FortiGate Firewall to reach other resources in the peered Vnet in another subscription. and the Remote Vnet resource subnet also has a route table towards FortiGate Firewall for reverse traffic to ensure the symmetry
    • Kindly ensure that on FortiGate Firewall you have traffic allowed for the resource's prefixes in the peered virtual network.
    • Kindly note ICMP is not the right way to troubleshoot the connectivity over the cloud , rather use
    •   telnet <destination-ip> <remote-port> to test the connectivity.
      
    • Check the DNS settings on Azure Virtual Network and confirm the settings.
    • User's image
    • Azure provides name resolution by default for VMs within the same VNet which is known as azure provided name resolution. Using this you can only resolve the dns for the resources within the vnet only.
    • https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances?tabs=redhat#azure-provided-name-resolution
    • For peered VNets, you need to use Azure Private DNS zones or configure your own DNS servers to forward queries between VNets. Refer this
    • https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances?tabs=redhat
    • Based on the above links kindly advise what DNS solution you are using for your peered virtual networks.
    • If you are using Custom DNS servers, you have to ensure that you have DNS entry for your remote vnet resources.
    • Kindly revert back with the details if you wish to carry on this thread, otherwise if you were able to create a support ticket with the help of the shared link above and wish to work with support engineer on the raised ticket, kindly accept the answer.
    • If you need any help with the above points kindly revert back.

    If the below answer addressed your query, please don’t forget to click "Accept the answer" and Up-Vote for the same, which might be beneficial to other community members reading this thread. And, if you have any further query do let us know.

    Thanks,

    Ujjawal Tyagi

    0 comments No comments

  2. Shravan Addagatla 690 Reputation points Microsoft External Staff
    2025-05-02T08:50:28.4933333+00:00

    Hi @Matthew Edinger

    I'm glad that you were able to resolve your issue and thank you for posting your solution so that others experiencing the same thing can easily reference this!

    Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others ", I'll repost your solution in case you'd like to "Accept " the answer.

    Issue: Cannot connect to the VM in different VNet that are peered.

    Solution: Conflict with the private IPs. Re-created the VM and a new VNet, which resolved the issue.

    If you have any other questions or are still running into more issues, please let me know.

    Thank you again for your time and patience throughout this issue.

    Please remember to "Accept Answer", so that others in the community facing similar issues can easily find the solution.

    0 comments No comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.