The next check is whether Ubuntu has acquired the NIC’s private IPv6 address and an IPv6 route; Azure maps the public IPv6 address to that private address, so sshd listening on [::]:22 alone does not confirm that the guest IPv6 network is operational.
1. Verify IPv6 inside Ubuntu
Run these commands through the existing console session:
ip -6 address show
ip -6 route show
ip -6 route get [IP Address]
ping -6 -c 4 [IP Address]
Expected results:
- The primary interface has a global/private IPv6 address from the VNet subnet, not only an address beginning with
fe80::.
- An IPv6 route is selected for the external destination.
- The source address in
ip -6 route get is the interface’s Azure-assigned private IPv6 address.
Do not expect Ubuntu to display [IP Address]; Azure public IP addresses are shown in the portal, while the operating system sees the NIC’s private IPv6 address. An address beginning with fe80:: is link-local and cannot receive internet traffic. ^1^
If no global IPv6 address appears, verify VM → Networking → network interface → IP configurations contains an IPv6 configuration with:
- IP version: IPv6
- A private IPv6 allocation
- The displayed public IPv6 resource associated with that same configuration
That is the required NIC arrangement for an existing dual-stack VM. ^2^
Some Linux images do not enable DHCPv6 by default. For Ubuntu 17.10 or later, Microsoft documents enabling dhcp6: true in a cloud-init network override. Editing network configuration can remove network access, so retain console access and back up the current files first. ^3^
Create /etc/cloud/cloud.cfg.d/91-azure-network.cfg—note the documented directory is cloud.cfg.d:
network:
version: 2
ethernets:
eth0:
dhcp4: true
dhcp6: true
match:
driver: hv_netvsc
set-name: eth0
Also add this line to /etc/dhcp/dhclient.conf:
timeout 10;
Reboot, then repeat ip -6 address show. If the interface is not named eth0, do not apply the sample unchanged; identify the Azure interface with ip link and adapt the configuration carefully.
3. If Ubuntu has its private IPv6 address, test the Azure packet path
Because the screenshot already shows a temporary TCP/22 allow rule and sshd listening on IPv6, do not add another NSG rule. Instead, identify whether Azure sees the connection:
- Open Azure portal → Network Watcher → IP flow verify.
- Select the VM.
- Set:
- Direction: Inbound
- Protocol: TCP
- Local IP: the VM’s private IPv6, not its public IPv6
- Local port:
22
- Remote IP: the client’s current public IPv6
- Remote port: for example,
60000
- Select Check.
IP flow verify accepts IPv4 or IPv6 addresses and reports the exact security rule allowing or denying the packet. ^4^
4. Rule out the client’s IPv6 path
From the client, run:
ssh -6 -vvv username@[IP Address]
Also test from a different native-IPv6 connection, such as another ISP or mobile network. If another network works, the original client network, router, VPN, proxy, or organizational edge is blocking or lacks a usable IPv6 route. Microsoft’s SSH isolation guidance recommends testing from a directly connected internet source to distinguish an Azure/VM problem from an edge-network restriction. ^6^
A timeout before any SSH banner normally points to the network path or guest firewall rather than keys or credentials, so resetting SSH credentials is not indicated at this stage.
References
- Conceptual planning for IPv6 networking
- Add a dual-stack network to an existing virtual machine
- Configure DHCPv6 for Linux VMs
- What is Azure Network Watcher?
- Troubleshoot SSH connectivity blocked by network security group misconfiguration in Azure
- Detailed SSH troubleshooting steps for issues connecting to a Linux VM in Azure