Service tag IPs cannot reach the VMs, but normal IPs do work and makes VM reachable.

Thanks for the additional information, @Cesar Romo Rangel (INFOSYS LIMITED) . It helps narrow down the scope.

The behavior now points to the Point-to-Site VPN client routing, rather than the VM’s NSG, NIC, public IP association, or Azure Virtual Network Manager.

The important detail is this route on your workstation:

74.144.0.0/14 → MSFT-AzVPN-Manual

Because the Standard Anycast public IP 74.146.1.20 belongs to that prefix, the Azure VPN Client sends the RDP traffic into the P2S tunnel instead of sending it directly through your local Internet connection.

A public IP attached to a VM NIC is normally reached through its public-facing path. A standard Azure VPN Gateway does not provide Internet transit or NAT for P2S clients. Therefore, traffic to a public IP that is captured by a VPN route can be dropped after entering the tunnel. Microsoft documents that Internet-bound traffic sent through a VPN Gateway is not given Internet connectivity unless a separate supported egress architecture is implemented.

This also explains why:

• IP Flow Verify does not report an NSG denial.
• The VM is reachable from another Azure-hosted desktop.
• The same VM is unreachable only through the MSFT-AzVPN-Manual client route.
• The recommended solution depends on the intended access path:

For administrative access through the VPN, connect to the VM’s private IP address, not its public IP. Confirm that the VM subnet is advertised to the P2S client and that the NSG permits TCP 3389 from the P2S client address pool.

For access through the public IP, remove that public prefix from the P2S advertised routes or add it as an excluded route in the Azure VPN Client profile so it uses the local Internet connection:

<clientconfig>

<excluderoutes>

<route>

<destination>74.144.0.0</destination>

<mask>14</mask>

</route>

</excluderoutes>

</clientconfig>

After changing the profile, reimport or reconnect the Azure VPN Client and confirm with:

route print 74.*

Test-NetConnection 74.146.1.20 -Port 3389

Azure VPN Client supports custom included and excluded routes through its profile configuration.

Therefore, no AVNM security rule should be required here. The route directing 74.144.0.0/14 into the VPN is the item that should be reviewed by the team managing the P2S VPN profile and advertised routes.

Also, exposing RDP directly through a public IP is generally discouraged. Azure Bastion, Just-In-Time VM access, or private-IP access over the VPN would provide a safer administrative path.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

[sent below]

• The Azure region.
  R: West US
• Whether the Standard Anycast Public IP is attached directly to the NIC or to a Load Balancer.
  R: Attached to a NIC
  
• The VPN appliance/vendor (Azure VPN Gateway, Palo Alto, Cisco, etc.).
  R: Azure VPN Client App with the following connection MSFT-AzVPN-Manual
• Whether Network Watcher Connection Troubleshoot or IP Flow Verify reports any blocked traffic.
  R: When I do from IP flow verify using VPN IP it doesn't seem blocked, I did another test from a Microsoft Virtual Desktop in West US (legacy), (maybe this connects due it is a corp type) and the tagged IP was able to connect.

Hello @Cesar Romo Rangel (INFOSYS LIMITED)

Based on your description, this doesn't appear to be an Azure Virtual Network Manager (AVNM) issue by itself. If the VM is reachable using a standard Azure Public IP but becomes unreachable after associating a Standard Anycast Public IP (Service Tagged IP), the first step is to validate whether your VPN path, firewall, or upstream network recognizes and routes traffic to the Anycast address range.

A few areas I'd recommend checking:

• Verify that the NSG still allows inbound TCP 3389 (or your required ports). NSGs generally don't differentiate between a standard public IP and a Standard Anycast Public IP.
• Confirm the effective routes and effective security rules on the VM's NIC to ensure there are no unexpected routing or filtering changes.
• Review your VPN/firewall policies. If your VPN solution or enterprise firewall filters traffic based on Azure public IP prefixes, it may need to allow the Service Tag or the published Azure IP ranges for your region.
• Validate that the Anycast Public IP has been correctly associated with the VM's NIC or Load Balancer frontend (depending on your architecture) and that provisioning completed successfully.

Since connectivity works immediately when reverting to a regular Azure Public IP, this points more toward a routing or policy issue outside the VM rather than an AVNM configuration problem.

If possible, could you share:

• The Azure region.
• Whether the Standard Anycast Public IP is attached directly to the NIC or to a Load Balancer.
• The VPN appliance/vendor (Azure VPN Gateway, Palo Alto, Cisco, etc.).
• Whether Network Watcher Connection Troubleshoot or IP Flow Verify reports any blocked traffic.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.