getting error -"Manually configure line of sight to private IP address" post migrating Windows server to Azure,do have VPN ipsec enabled but still not able to resolve this error and RDP to the VM

Question

getting error -"Manually configure line of sight to private IP address" post migrating Windows server to Azure,do have VPN ipsec enabled but still not able to resolve this error and RDP to the VM

bagh, sukriti 0

Have migrated a Windows server to Azure VM, unable to RDP using Native RDP-i have a Site to site VPN connection shown as "Connected". There are 2 different subscription1-shared subs having Vnet1 which is peered Vnet2 in Subscription2-Production subs(that has VM as well).Client has DMZ network and trying to establish Site to site connectivity, have whiteslisted VM's public IP range in the checkpoint firewall of client to allow traffic from Azure cloud to On premise firewall.Have followed steps to resolve error ="Manually configure line of sight to private IP address" -1.Network Security Group (NSG) RulesAdd inbound rule: Port: 3389Protocol: TCPSource: Your on-prem IP range or VPN Gateway subnet Action: Allow 2.Ensure routes for on-prem IP ranges exist in the VM’s subnet. -->yes Does anyone know what configuration i am missing ? due to which the error still exists?

Harish Peddapally 1,330 Reputation points Microsoft External Staff Moderator

2025-10-14T06:25:02.13+00:00
Hi bagh, sukriti,

Welcome to Microsoft Q&A and thank you for posting your query here!

The error "Manually configure line of sight to private IP address" after migrating a Windows server to Azure and connecting via a Site-to-Site VPN generally means one or more steps are missing in network path configuration, even when the VPN connection status is "Connected". This is common when VMs are in peered VNets across subscriptions or when complex NSG/routing/firewall factors exist.

Additional Configuration Checks:

VNet Peering Configuration: Ensure that "Allow forwarded traffic" and "Allow gateway transit" are enabled on both VNet peering connections. Without these, VPN gateway traffic won't route between peered VNets and the VM's subnet, blocking RDP from on-premises.

Route Tables (UDR): Check if there are custom route tables (UDR) on the VM subnet that could inadvertently block or override routes to the on-premises network.

Client-side Routing: Verify that your on-premises and Azure-side route tables explicitly route the on-prem IP ranges to the Azure VPN gateway and that return traffic isn't using an Internet breakout path.

Firewall and Network Security Groups: Confirm no Azure Firewall, NVA, or additional NSG/ASG rules are inadvertently blocking TCP/3389 or broader traffic between the VM subnet and on-premises. Sometimes additional default-deny rules get applied after migration.

VM Network Interface Troubleshooting: Use Azure’s "IP flow verify" tool to confirm that packets from your on-prem IP to the VM’s private IP over 3389 are permitted. This is available in the Networking section of the VM in the portal.

Suggested Steps:

Double-check VNet peering settings and confirm gateway transit and forwarded traffic are enabled.

Review all custom route tables and remove or update any conflicting routes.

Perform "IP flow verify" using the Azure portal for the affected VM to confirm connectivity.

Temporarily remove any custom NSG or firewall rules to isolate the issue, then re-add rules gradually.

If the VM itself migrated with a new private IP or NIC, revalidate local firewall/Windows Defender rules inside the VM.

Most often, missing gateway transit in VNet peering or overlooked custom UDRs are the culprits in multi-subscription topologies where traffic is passed across peered VNets.

For full troubleshooting, see these Microsoft docs

https://free.blessedness.top/en-us/azure/virtual-machines/windows/connect-rdp

https://free.blessedness.top/en-us/troubleshoot/azure/virtual-machines/windows/troubleshoot-rdp-connection

https://free.blessedness.top/en-us/troubleshoot/azure/virtual-machines/windows/troubleshoot-rdp-nsg-problem

Please do let me know if you have any questions on this.

Thanks,

Harish.
bagh, sukriti 0 Reputation points

2025-10-14T07:20:39.9433333+00:00

[@Harish Peddapally ]thanks for replying, looks like it is Vnet peering which is causing issue in UDR. The hybrid plan is - to use both Azure firewall with Site-to-site VPN , but my issue here is the firewall is in different vnet in Firewall subs=subs1 , the VPN gateway and VPN gateway is in Shared subscription=subs2 and the actual VM is in Extranet-prod subscription=subs3. I have peered subs 2 and subs3 for Site to site which is working fine but in Route table when i have added IP range of firewall vnet for routing traffic - the vnet peering never got successful as - extranet-prod has peering where Enable forward traffic is set for forwarding traffic to Gateway, so i cannot peer it with firewall for forward traffic.so i am stuck here - as i would need Peering1 - between subs2 and subs3 for site to site and subs1(firewall vnet) and subs3(VM vnet). Microsoft doc says - Option B: Keep Firewall in Separate VNet • Peer Firewall VNet with Shared VNet (hub). • Configure UDRs in Extranet-Prod to point to firewall IP via Shared VNet. • Shared VNet must allow forwarded traffic and act as transit. • This requires: o Allow forwarded traffic on Shared ↔ Firewall peering. o NVA/firewall routing in Shared VNet to forward packets to Firewall VNet. • Essentially, Shared VNet becomes the transit router. But this Option B doesnt work neither direct peering to firewall works. Not sure why CAF model complicates the peering - mine is a small project and Microsoft suggested CAF but it complicated everything. Any suggestions would be appreciated.
Harish Peddapally 1,330 Reputation points Microsoft External Staff Moderator

2025-10-16T02:02:13.0233333+00:00

Hi bagh, sukriti,

Greetings for the day, i hope you are doing great!

Just checking to see if you have a chance to check my previous response and helped, do let me know if you have any further questions on this.

Thanks,

Harish.

1 answer

Your answer

bagh, sukriti 0 Reputation points

2025-10-14T07:20:39.9433333+00:00

[@Harish Peddapally ]thanks for replying, looks like it is Vnet peering which is causing issue in UDR. The hybrid plan is - to use both Azure firewall with Site-to-site VPN , but my issue here is the firewall is in different vnet in Firewall subs=subs1 , the VPN gateway and VPN gateway is in Shared subscription=subs2 and the actual VM is in Extranet-prod subscription=subs3. I have peered subs 2 and subs3 for Site to site which is working fine but in Route table when i have added IP range of firewall vnet for routing traffic - the vnet peering never got successful as - extranet-prod has peering where Enable forward traffic is set for forwarding traffic to Gateway, so i cannot peer it with firewall for forward traffic.so i am stuck here - as i would need Peering1 - between subs2 and subs3 for site to site and subs1(firewall vnet) and subs3(VM vnet). Microsoft doc says - Option B: Keep Firewall in Separate VNet • Peer Firewall VNet with Shared VNet (hub). • Configure UDRs in Extranet-Prod to point to firewall IP via Shared VNet. • Shared VNet must allow forwarded traffic and act as transit. • This requires: o Allow forwarded traffic on Shared ↔ Firewall peering. o NVA/firewall routing in Shared VNet to forward packets to Firewall VNet. • Essentially, Shared VNet becomes the transit router. But this Option B doesnt work neither direct peering to firewall works. Not sure why CAF model complicates the peering - mine is a small project and Microsoft suggested CAF but it complicated everything. Any suggestions would be appreciated.
Harish Peddapally 1,330 Reputation points Microsoft External Staff Moderator

2025-10-16T02:02:13.0233333+00:00

Hi bagh, sukriti,

Greetings for the day, i hope you are doing great!

Just checking to see if you have a chance to check my previous response and helped, do let me know if you have any further questions on this.

Thanks,

Harish.

Answer 1

Hi bagh, sukriti,

Good day, i hope you are doing well!

Thank you for providing detailed information about your hybrid network setup across multiple subscriptions and VNets. This kind of multi-subscription, multi-hub architecture with Azure Firewall, VPN Gateway, and VNet peering can indeed become complex, especially when working with transit routing and gateway transit settings.

You are correct that the Azure CAF (Cloud Adoption Framework) guidance encourages this hub-and-spoke model, but it can feel complex for smaller projects depending on how routes and peering are configured.

Here are some important pointers and suggestions based on your scenario:

For the hub (Shared subscription VNet where VPN gateway resides), you must enable Allow gateway transit and Allow forwarded traffic on peering links both to the Firewall VNet (subs1) and the VM VNet (subs3). The hub VNet becomes the transit point and gateway.

On the spoke VNets (Firewall VNet in subs1 and VM VNet in subs3), you must enable Use remote gateway on their peering connections back to the hub (subs2). Note you cannot enable Use remote gateway on more than one peering from the same spoke.

This means that if the Firewall VNet also needs gateway transit, it has to peer with the hub and use the remote gateway, and the VM VNet peers and uses the remote gateway. The hub routes traffic between firewall and VM subnets and forwards on-prem traffic via the VPN gateway.
UDRs (user-defined routes) on the VM subnet should point traffic to the firewall's private IP in the firewall VNet, and the firewall routes to the VPN gateway subnet in the hub VNet, creating a traffic flow path.

The error and peering failure you have when adding the firewall VNet IP ranges to the VM subnet's route table might be due to missing or conflicting peering settings in the hub, or because route propagation and custom UDRs overlap or conflict.

Azure currently does not support multiple remote gateways on a single VNet peer, so you cannot have two VNets both enabling remote gateway via peering to the same hub.

Recommendations:

Verify the peering on the hub VNet (subs2) to both the firewall VNet and VM VNet with Allow forwarded traffic and Allow gateway transit enabled.
Ensure each spoke VNet (firewall VNet and VM VNet) peering back to the hub has Use remote gateway enabled.
Carefully plan UDRs to avoid route conflicts. Use UDRs on the VM subnet pointing to the firewall private IP, and on firewall subnet pointing traffic to VPN gateway.
If you face conflicts in direct peering, consider using a firewall or NVA in the hub subnet to centralize routing and simplify the topology.
You may want to review Microsoft’s official guidance for such hybrid, hub-and-spoke configurations, particularly:

I understand this can be tough with CAF's recommended model, but with the right combination of peering flags and route setups, you should achieve the desired connectivity.

Please let me know if you need help or additional clarifications.

If the information resolved your issue, kindly consider accepting the answer — it will help others who might be facing similar challenges.

Thanks,

Harish.

Share via

getting error -"Manually configure line of sight to private IP address" post migrating Windows server to Azure,do have VPN ipsec enabled but still not able to resolve this error and RDP to the VM

1 answer

Your answer