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.
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
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.
-
- 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.
-
- 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