[Azure] Public IPv6 ICMPv6 packetloss

CS 5 Reputation points
2026-05-17T22:18:16.36+00:00

The issue

I have an issue with ICMPv6 packets send to an Azure Public IPv6.

I tested it with a Standard Load Balancer with a Public IPv6 address, and also with an Ubuntu VM with a public IPv6 address.

It's not responding in time to about 2/3 of the ping packets send to it.

This only happens when pinging it from the internet.

When I ping it from a VM from inside an Azure VNET, there is no packet loss.

Is this something I can solve myself? Or is this something Microsoft needs to fix in Azure?

For clarification: Contrary to IPv4, ICMP is crucial for IPv6 to function properly.

As this is a documented feature, I expect it to work like described:

https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-test-frontend-reachability?tabs=windows-outside%2Cping%2Cwindowsvm

https://techcommunity.microsoft.com/blog/itopstalkblog/wired-for-hybrid---whats-new-in-azure-networking---june-2023-edition/3866658

Using a public IPv4 address is not possible with our usecase.

To reproduce

Create a VM with Ubuntu 24.04

  1. Basics tab
    1. Create new Resource group
    2. Enter VM name
    3. Availability options: No infrastructure redundancy required
    4. Image: Ubuntu Server 24.04 LTS - x64 Gen2
    5. VM architecture: x64
    6. Size: Any, but Standard_B2ats_v2 will do fine
    7. Authentication type: Password or SSH key
    8. Enter username and password or SSH key name
  2. Disks tab: Leave all default
  3. Networking tab
    1. Virtual network: Create new
    2. Enter VNET name
      1. Leave other settings default
    3. Public IP: None
    4. NIC network security group: None
  4. Review + Create: Create

After the VM is created, go to the new created VNET and create an IPv6 address space on the subnet

  1. Go to Settings -> Address space
  2. Click Add address space -> Add IPv6 address space
    1. Click Save
  3. Go to Settings -> Subnets
    1. Click the subnet name
    2. If "Include an IPv6 address space" can be checked, check it. If it is greyed out, click cancel and wait a minute and try again
    3. Click: Add

Go to the new Network Interface of the VM and add a private IPv6 address

  1. Go to Settings -> IP configurations
    1. Click Add
    2. Enter a Name
    3. IP version: IPv6
    4. Click Add

Create a standard, regional Load Balancer with an inbound NAT-rule to the VM. (without a NAT or LB rule, all pings will fail)

  1. Basics tab
    1. Select the created resource group
    2. Enter a name
    3. SKU: Standard
    4. Type: Public
    5. Tier: Regional
  2. Front End IP configuration tab
    1. Click Add a frontend IP configuration
      1. Enter a name
      2. IP version: IPv6
      3. Public IP-Address: Create new
        1. Enter a name
        2. Availability zone: No Zone
        3. Click Save
      4. Click Save
    2. Click 2x Next to go to the Inbound rules tab
  3. Inbound rules tab
    1. Click Add an inbound NAT rule
      1. Enter a name
      2. Target virtual machine: a VM with a private IPv6 address
      3. Network IP configuration: a private IPv6 address
      4. Frontend IP address: The to be created public IPv6 address
      5. Frontend port: 22
      6. Backend port: 22
      7. Click Save
    2. Click Review + Create
  4. Review + Create tab
    1. Click Create

No go to the new Load Balancer and copy it's public IPv6

On your local PC: ping the IPv6 address continuesly. ( ping -t on Windows)

See the following happening:

PS C:\Users\<USERNAME> ping <LB-PUBLIC-IPv6-ADDRESS> -t

Pinging <LB-PUBLIC-IPv6-ADDRESS> with 32 bytes of data:
Request timed out.
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=2474ms            <----------------
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=2000ms            <----------------
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=9ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=9ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=9ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=9ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=2473ms            <----------------
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=7ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=7ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=10ms
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=9ms
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=479ms            <----------------
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=7ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=9ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=7ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Reply from <LB-PUBLIC-IPv6-ADDRESS>: time=8ms
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for <LB-PUBLIC-IPv6-ADDRESS>:
    Packets: Sent = 4777, Received = 1801, Lost = 2976 (62% loss),
Approximate round trip times in milli-seconds:
    Minimum = 7ms, Maximum = 2983ms, Average = 69ms

I left it running for a couple of hours and got a 62% loss. Notice the long response times it sometimes takes when it starts replying again.(Suffixed by <----------------)

Azure Load Balancer
Azure Load Balancer

An Azure service that delivers high availability and network performance to applications.

0 comments

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. CS 5 Reputation points
    2026-05-18T14:50:00.4566667+00:00

    It seems that my Intel AC 7265 Network Card has an issue with IPv6 and turning it off and on fixed it. After a few minutes the problem comes back and is solved by re-enabling it.

    Thanks for assisting!

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments
  2. Thanmayi Godithi 11,825 Reputation points Microsoft External Staff Moderator
    2026-05-18T01:49:36.64+00:00

    Hi CS,

    Based on your additional testing, this appears to be isolated from VM/NSG/SSH configuration and more likely related to the Azure public IPv6 path.

    To further validate and narrow down the source of packet loss, could you please confirm:

    • Whether the behaviour is consistent across different external networks/ISPs (for example, broadband vs mobile hotspot)
    • If the same behaviour occurs when testing from a different Azure region
    • Whether TCP connectivity over IPv6 (port 22) also shows instability, or if the issue is specific to ICMPv6
    • If the packet loss pattern is consistent for both VM public IPv6 and Load Balancer public IPv6

    Additionally, as part of standard connectivity troubleshooting (to analyse latency and identify where probes fail along the path), could you run:

    traceroute -6 <public-ipv6-address>

    Kindly let us know the above details.

    Was this answer helpful?

    0 comments

  3. AI answer

    2026-05-17T22:28:54.7+00:00

    ICMPv6 packet loss to an Azure public IPv6 endpoint in this scenario is a platform-side behavior, not something that can be tuned or fixed from the VM or load balancer configuration.

    Key points from the documented behavior and limitations:

    1. Standard Public Load Balancer ICMP behavior
      • Standard Public Load Balancer frontends support ICMP echo (ping) for IPv4 and IPv6 and handle ICMP at the load balancer itself; probes are not forwarded to backend instances.
      • ICMP is allowed by default and cannot be disabled on Standard Public Load Balancers, but:
        • ICMP packets larger than 64 bytes are dropped, which can manifest as timeouts when using larger payloads.
        • Outbound ICMP from a Standard Load Balancer is not supported.
      • For public load balancers, the expected ping responses depend on backend health probe state (for IPv4 documented explicitly). When at least one backend is probed UP, echo replies are expected; otherwise, timeouts or unreachable responses occur.
    2. IPv6-specific limitations
      • ICMPv6 is not supported in Network Security Groups (NSGs). This means NSGs cannot explicitly control or troubleshoot ICMPv6 flows in the same way as IPv4.
      • When using dual stack with a load balancer, IPv6 health probes require an active NSG to function; otherwise, probes for IPv6 do not work. This indicates that IPv6 load-balancing and health behavior is more constrained than IPv4.
    3. What can be changed by configuration
      • From inside the VNet, successful pings indicate that the VM’s IPv6 configuration and internal routing are working.
      • For public reachability, the main configurable elements are:
        • Ensuring the Standard Public Load Balancer is used (not Global or Gateway, which do not support ICMP ping).
        • Ensuring backend instances are healthy and reachable on the probed ports so that the load balancer marks them UP.
        • Ensuring NSGs do not block required traffic for probes and data (for IPv4) and that an NSG is present for dual-stack load balancers so IPv6 probes can function.
      • There is no configuration option to adjust ICMPv6 handling, rate, or prioritization at the Azure edge or within the load balancer for public IPv6.
    4. Conclusion for this scenario
      • Given that:
        • ICMP handling for public load balancers is implemented at the load balancer and not on the VM.
        • ICMPv6 is not controllable via NSGs and has specific platform limitations.
        • The issue appears only from the internet and not inside the VNet.
      • This behavior cannot be resolved by changing VM, NSG, or load balancer configuration alone. It is a platform/network behavior that requires investigation and remediation by Microsoft.

    The appropriate next step is to open a support case with Microsoft Azure Support, providing:

    • The affected public IPv6 address.
    • The region and resource IDs of the load balancer and VM.
    • Sample ping logs and timestamps from external tests.

    This allows Microsoft to check for regional or platform-side IPv6/ICMP handling issues on the Azure edge or load balancer service.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

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