IPv6 works only sometimes? Check DNS, firewall and path MTU

Make the failure measurable first

Record the hostname, time, client network, application and exact error. Then separate the address families: DNS queries for A and AAAA show the published targets, while tools such as curl with -4 or -6 test the same HTTPS request over IPv4 or IPv6. A successful IPv4 test does not prove that the IPv6 path works.

Compare not only success and failure but also duration, response size and reproducibility. If only certain networks, devices or larger transfers are affected, that narrows the investigation considerably.

1. Check A and AAAA targets separately

• Do the published A and AAAA addresses point to the intended platform?
• Do the authoritative name servers and the resolver in use return the same current values, or is an old TTL still in effect?
• Does an AAAA record still point to an old server, proxy or load balancer that is no longer fully operated?
• Does monitoring test both address families explicitly instead of only the first path that succeeds?

2. Check listeners, TLS and firewalls on the IPv6 target

DNS can be correct even when no service listens on the address. On the destination system, check the IPv6 address and route as well as the listener of the web server, reverse proxy or load balancer. Container and proxy configurations can handle IPv4 and IPv6 differently, so test the public address from outside the server network as well.

For HTTPS, the hostname, certificate and Server Name Indication must lead to the same intended service on both paths. Also check the host firewall, upstream network filters and security groups specifically for IPv6. An IPv4 rule does not automatically create an equivalent IPv6 rule.

3. Filter ICMPv6 deliberately, not with a blanket block

ICMPv6 is a fundamental part of IPv6. It includes error messages such as Packet Too Big, which a sender needs to determine the usable path MTU. A blanket block can therefore break connections even when TCP port 443 is allowed through the firewall.

This does not mean forwarding every ICMPv6 message without review. Use explicit rules based on message type and network boundary, follow firewall recommendations, and rate-limit logging of dropped packets. Do not copy old IPv4 filtering rules to IPv6 unchanged.

4. Consider path MTU when small transfers work and large ones fail

IPv6 routers do not fragment packets in transit. If a packet is too large for the next part of the path, the router reports this with an ICMPv6 Packet Too Big message and the sender adjusts the packet size. If these messages are filtered or cannot reach the sender, small requests may work while TLS connections, uploads or downloads stall.

Compare a small request with a larger controlled transfer. Tools such as tracepath can provide clues about the path MTU. Pay particular attention to tunnels, VPNs, overlays and links with a different MTU. Do not lower the MTU globally as a first response: identify the actual bottleneck before correcting the relevant configuration.

5. Test from multiple networks and over both address families

• Test the same host over IPv4 and IPv6 from the office or data-centre network.
• Use a second independent connection, such as a mobile network or an external probe.
• Record the DNS result, source and destination address, port, time and exact error together.
• Capture packets only with proper authorisation and protect payload data and personal information.

Reach the root cause faster with useful evidence

For an escalation to an operator or provider, “IPv6 is broken” and a single screenshot are rarely enough. Useful evidence includes a narrow time window, the affected hostname, resolved A and AAAA addresses, the client network, separate IPv4 and IPv6 results, and whether only larger transfers fail.

If the affected service is operated by NUXOA, send this information without credentials through the designated support or contact channel. This helps determine quickly whether DNS, the destination system, the firewall or the network path needs investigation.