Dante Hears IPv6 Clients but Still Refuses Them
Check both Dante listener address selection and address-family-aware access rules when adding IPv6 clients.
A Dante interface name can expand to both IPv4 and IPv6 addresses. That does not make an existing IPv4-only access rule match IPv6 clients.
This is a common half-finished dual-stack change: the SOCKS listener becomes reachable on an IPv6 address, but the rules still describe only IPv4 source and destination ranges.
Check addresses and rules separately
Dante can use repeated internal entries or an appropriate interface name for listener addresses. The effective addresses depend on what is available on the interface when the service configures them.
Then inspect client and SOCKS rules. An address expression such as 0.0.0.0/0 is IPv4, not a universal spelling for every address family. Dante documents an address-family-neutral form, but do not use a broad form when only a particular client subnet should be permitted.
Keep authentication and destination restrictions alongside the family change. Adding IPv6 should not accidentally remove restrictions that were effective for IPv4 users.
Startup timing can matter too. If an address is assigned after the service starts, check what Dante actually bound rather than assuming that an interface name always includes addresses that appeared later.
Finally, an IPv6 client connection and an IPv6 website connection are separate requirements. The intended client may connect over one family while the proxy reaches a destination over the other. Diagnose the family of the failed connection, not simply whether the machine is called dual stack.