Mumble IPv6 vs IPv4 reachability (why it works on one and not the other)

What this looks like

• Connecting via IP address works, but connecting via hostname fails.
• Some users connect fine, others can’t (often depending on ISP / network).
• The client “tries” quickly and fails without obvious logs on the server.

1) Check what DNS is returning (A vs AAAA)

If your hostname has both an A record (IPv4) and an AAAA record (IPv6), some clients will prefer IPv6. If your server isn’t reachable over IPv6, those clients will fail.

# From your local machine:

dig +short mumble.yourdomain.com A
# IPv4

dig +short mumble.yourdomain.com AAAA
# IPv6

If you don’t intend to support IPv6 for this service, the simplest fix is: remove the AAAA record. If you do intend to support it, keep going.

2) Confirm the server actually has IPv6

On the server:

ip -6 addr show

# Optional sanity check: is IPv6 disabled?
cat /proc/sys/net/ipv6/conf/all/disable_ipv6

If there is no global IPv6 address (or IPv6 is disabled), but you publish an AAAA record, you’ve created a guaranteed failure for some clients.

3) Confirm Mumble is listening on IPv6 (and IPv4)

A server can be reachable on IPv4 while not listening on IPv6 at all. Verify what it’s actually bound to.

# UDP is the important one for Mumble (default 64738)
ss -lunp | grep -E ':64738\b' || true

# If you also want TCP fallback:
ss -ltnp | grep -E ':64738\b' || true

You’re looking for bindings on 0.0.0.0:64738 (IPv4) and/or [::]:64738 (IPv6).

4) Firewall: open UDP 64738 for IPv6 as well

This is where most “IPv6 only fails” incidents live. You opened 64738/udp on the provider firewall (IPv4), or in UFW (IPv4), but IPv6 is still blocked.

UFW

sudo ufw status verbose

# Allow Mumble (UDP)
sudo ufw allow 64738/udp

# Optional TCP fallback
sudo ufw allow 64738/tcp

Note: UFW can have IPv6 disabled in /etc/default/ufw. If IPV6=no, your UFW rules will not apply to IPv6.

Provider firewall

Many providers treat IPv6 firewall rules as separate objects/settings. If you publish an AAAA record, ensure inbound UDP 64738 is allowed to the server’s IPv6 address.

5) Quick mitigation vs correct fix

If you want a fast restore for users and you don’t need IPv6 right now:

• Remove the AAAA record for the Mumble hostname (keep the A record).
• Wait for DNS to propagate (respect TTL).

If you want the correct long-term fix:

• Ensure the VPS has working IPv6 routing.
• Ensure Mumble listens on IPv6 ([::]).
• Open inbound UDP 64738 on IPv6 (provider firewall + host firewall).

6) Proof: verify from an external host

From a machine that has IPv6 connectivity:

# Does the hostname resolve to IPv6?
dig +short mumble.yourdomain.com AAAA

# Can you reach the server over IPv6 at all?
ping -6 -c 3 mumble.yourdomain.com

Some networks block or degrade IPv6/UDP in weird ways. If it works from one network but not another, focus on DNS and firewall first.