Protecting a Mumble Server from DDoS Attacks

A Mumble server is the leanest way to let a group talk without relying on somebody else's service: open source, self hosted, a single port, no license file and no account anywhere. That simplicity has a flip side that almost nobody knows about. On port 64738 UDP the server answers a twelve byte request that requires no login at all with twenty four bytes of server details. The source address of that request can be forged at will. Anyone who leaves that answer switched on is running a reflector that strangers point at strangers.

This guide explains how a Mumble server is built, which attack types actually hit it, which lines in the configuration file do something, and where every measure on the server itself ends. The commands are written for Debian 12, Debian 13, Ubuntu 22.04 LTS and Ubuntu 24.04 LTS. Wherever root is required, it is stated. Every setting named here comes from the configuration file shipped with the Mumble server, not from a forum post.

Why a Mumble server gets attacked

A Mumble server becomes a target for three reasons, and none of them has anything to do with the size of the project.

First, real-time voice is unforgiving. Nobody notices a website with two percent packet loss, because TCP simply sends the missing segments again. Voice has no retransmission: a lost packet is a gap in the audio, and everyone in the channel hears it immediately. So an attack does not have to saturate your line in order to make it unusable. Two percent loss is enough.

Second, the voice path is connectionless. Mumble carries voice over UDP. There is no handshake before the first packet arrives, and the source address can be written freely into every packet. Your server has to look at every incoming packet before it can drop it. The attacker needs neither access nor a password, only the IP address and the port number. What happens on a technical level is described in the article What is a DDoS attack?.

Third, the server volunteers information about itself. This is the point that sets Mumble apart from most voice services, and it gets a section of its own further down. In short: without any login, the server reveals its version, the number of connected users, the user limit and the bandwidth allowed per user. It is meant as a convenience feature and it works as an invitation.

Mumble, Murmur and mumble-server: which name applies right now

The client has always been called Mumble. The server part was called Murmur for a long time, the program murmurd, the configuration file murmur.ini. Since the rename, the server part is simply called Mumble Server, the program is mumble-server and the configuration file is mumble-server.ini. Both spellings are in circulation, because older stable Linux releases still ship the old variant.

The names of the settings inside the file are not affected by the rename. allowping, bandwidth, users and serverpassword are spelled the same way in both variants. What changed is the file name, the program name and the location. The service name is mumble-server in both cases, which is why systemctl restart mumble-server works on all four systems covered here.

The ports this is really about

Mumble is pleasantly compact here: a single port, 64738, carries the entire service, over TCP and UDP at the same time. The comment line in the configuration file says so literally: "Port to bind TCP and UDP sockets to."

The most important line of this table: the only things that have to be reachable from the internet are 64738/TCP and 64738/UDP, nothing else. The Ice interface does not belong on the network, and by default it is not there. Check it anyway, see below.

Why both protocols have to be open

The division of labor is clean. TCP carries the control channel, UDP carries the voice. The TCP connection handles the TLS handshake, the login, the channel tree, the permissions, the text chat and file transfers. It is established when you connect and stays up for the whole session. UDP carries the voice packets, encrypted and without acknowledgments, because a late acknowledgment is worthless for speech.

If 64738/UDP is blocked, the server is not dead, it is slow. The Mumble client notices that nothing comes back over UDP and then pushes the voice through the TCP control connection that is already established. The client makes that decision after a waiting period in the order of twenty seconds after the encryption is set up, if not a single UDP packet could be decrypted correctly by then. It only switches back to UDP once several UDP packets arrive again in both directions.

The result of that fallback is audible. Voice over TCP means acknowledgments, retransmission of lost segments and congestion control. A single lost segment holds up the ones behind it until it has been repeated. A brief crackle turns into a noticeable delay that grows to several hundred milliseconds on a poor path. Anyone who walls off UDP to get rid of an attack trades an outage for permanently bad audio. That is acceptable for half an hour in an emergency and it is not a solution.

The ping answer on 64738 UDP: the vector almost nobody knows

This is the core of this article. A Mumble server answers an unencrypted request on its UDP port, requiring no login whatsoever, with a record about itself. The purpose is harmless: the connect dialog of the client is supposed to show how many people are online and how fast the server answers, before you connect. To do that the client sends a tiny packet and measures how long the answer takes.

The comment line in the configuration file spells out the consequence without hedging. It states that setting this option to true exposes the current user count, the maximum user count and the server's maximum bandwidth per client to unauthenticated users, and that in the Mumble client this information is shown in the connect dialog. The default value is true.

What goes out in 12 bytes and comes back in 24

Both packets have a fixed size. That makes the arithmetic simple and verifiable.

Those eight bytes of transaction number are the reason the whole thing works: the server returns them unchanged so that the client can match the answer to its request and compute the round trip time. To the server the number is meaningless. It checks nothing, it remembers nothing, it simply answers to the address written in the packet.

Newer Mumble versions moved the UDP protocol to a more modern format. The old pair of 12 and 24 bytes is still understood and answered for compatibility, and that backward compatibility is explicitly present in the source. So the protocol change does not take the attack surface away from you.

The amplification factor, calculated honestly

The Bandwidth Amplification Factor, or BAF, is the ratio between the payload of the answer and the payload of the request. For Mumble that is 24 divided by 12, so a factor of 2. Counting the complete IPv4 packet, 20 bytes of IP header and 8 bytes of UDP header are added on both sides: 40 bytes out, 52 bytes back, a factor of 1.3.

That puts Mumble at the bottom end of the scale. The industry reference is advisory TA14-017A from US-CERT and CISA, and the numbers in it are of a different order entirely. For comparison, the foreign values come from that advisory, the value for Mumble from the arithmetic above:

Anyone who concludes from this that the issue is harmless is measuring the wrong quantity. Mumble is not a bandwidth amplifier, it is a packet rate reflector. That difference has consequences.

Do the math. An attacker with an uplink of 1 Gbps puts around 1.49 million packets per second on the wire when the packets are as small as possible. Every one of those requests produces exactly one answer packet from an open Mumble server. So around 1.49 million packets per second arrive at the victim, spread across as many source addresses as the attacker found Mumble servers. Counted in bits that is barely more than the attacker sent himself. Counted in packets it is everything he was able to send.

Packet rate is the quantity that network cards, state tables and firewalls fail at first, not bandwidth. On top of that comes the real payoff for the attacker: the traffic arrives at the victim from genuine, operated servers with clean IP addresses. A block list by source address then locks out uninvolved Mumble operators by the dozen, and the attacker himself stays invisible.

Why this also hurts the reflector itself

This is not only about other people. Every ping request you answer costs your own server a system call, one outbound packet and a share of your outbound packet rate. If your server gets pulled into a reflection campaign, it will spend hours sending packets to a victim you have never heard of. Three things follow: your own audio quality suffers because the network card is busy, your provider sees a conspicuous outbound packet stream, and your IP address ends up on lists that are hard to get off again.

And there is a convenient property of reflection that is worth knowing, because it makes the defense easy: when your server is being abused as a reflector, every forged request carries the same source address, namely the victim's. A rate limit per source address is therefore very effective against your server being abused as a reflector, while it achieves almost nothing against an attack on your server, because there the source address is rerolled in every packet. Same rule, two completely different levels of effectiveness.

What allowping=false does and what it costs you

The setting is called allowping and lives in the server's configuration file. The default value is true. Set it to false:

allowping=false

Then restart the service:

systemctl restart mumble-server

What it does: the server no longer answers the unencrypted ping request. The query runs into nothing, no packet goes back, and your server is no longer available as a reflector.

What it costs: in the connect dialog of the Mumble client the fields stay empty. No latency, no user count, no user limit, no bandwidth figure. Anyone who has your server bookmarked can no longer see whether somebody is online and has to connect in order to find out. If your server is listed in the public registry, the entry there looks empty and dead.

That makes the tradeoff easy to state honestly. For a closed circle that coordinates elsewhere anyway, the loss is zero and the gain is real. For an open server that wants to attract new people through the registry, the empty display is a genuine drawback. In that case leave allowping on and limit the rate of ping requests in the packet filter instead, as shown further down.

One side effect you should verify once after the change: the setting touches the same ping mechanism the client uses to detect its UDP path. Authenticated clients send their latency measurement encrypted over the established session, and those packets are answered after decryption, which means independently of allowping. Check it in production anyway: talk with two people in a channel and look in the client to see whether the connection is still listed as a UDP connection. Five minutes of verification are cheaper than a week of bad audio that nobody connects to a configuration change.

The other attack types against a Mumble server

The ping answer is the peculiarity, but it is not the only attack surface. Three further patterns hit a Mumble server regularly.

UDP flood straight at 64738

The crudest case: as many UDP packets of arbitrary content as possible aimed at the voice port. The server has to accept every one of them, look up the source address in its table of known clients, and if it is not there, check whether the packet is a ping request. Only then can it drop it. Each of those steps is cheap, but none of them is free, and the bill gets multiplied by the packet rate.

The effect sets in long before the CPU is saturated. As soon as the incoming packet rate saturates the processing chain, the kernel drops packets without regard for their content, and the voice packets of your own people are among them. In the channel that does not sound like delay, it sounds like dropouts: chopped syllables, robot voice, sudden silence on a connection that is still up.

Connection flood against the TCP port

The second case targets 64738/TCP and is considerably more frugal. Every connection to the control channel starts with a full TLS handshake. The attacker barely has to compute anything if he aborts the handshake after the first step, but your server has already done its part by then.

This is the asymmetric classic: one packet from the attacker, one key operation on your side. A single machine on an ordinary connection can keep a Mumble server busy with this without ever getting close to a bandwidth limit. Mumble ships a brake against exactly this pattern, described further down.

Login flood and why the certificate exchange costs CPU time

The most expensive case is the login flood. Mumble always secures the control channel with TLS, and the client identifies itself with a certificate of its own that it generates on first start. For the server, every connection means: negotiate the handshake, present its own certificate, receive and check the peer certificate, derive session keys. Those are asymmetric cryptographic operations, and they are orders of magnitude more expensive than dropping a UDP packet.

For registered users the password check is added on top. The server derives passwords deliberately expensively, using PBKDF2 with a number of iterations that it benchmarks itself by default. That is exactly right against working through stolen password lists, and during a login flood it works against you: every attempt with a wrong password costs you the full derivation. The configuration file offers a setting that overrides the automatic benchmark. Do not touch that value. Lowering it to absorb an attack weakens exactly the part that protects your users' passwords.

The correct answer to a login flood is the connection brake in front of it, not weaker cryptography behind it.

Slot exhaustion: when the server is full although nobody is talking

The fourth case needs no forged source address at all. The users setting limits the number of simultaneous clients, 100 by default. As long as no server password is set, anyone who knows the address can connect. A hundred connections from a script, and your own people get told the server is full. That costs the attacker almost nothing and cannot be prevented without a server password.

How to tell it is an attack

Dropouts instead of delay

The most reliable distinction is your ear. An overloaded application or a crowded server sounds like delay: the voice arrives late, but complete. A network attack sounds like dropouts: syllables are missing, the voice turns metallic, there is silence in the middle of a sentence, and two seconds later it continues as if nothing had happened. The reason is the missing retransmission mechanism of UDP.

A second observation narrows it down further: if the latency shown in the client stays normal while packet loss rises, the cause is not server load. A computationally overloaded server answers late. A saturated line does not answer at all.

The four measurements on the server

Guessing does not help, measuring does. These four values settle the question in two minutes.

First: what is actually listening. As root:

ss -lnup
ss -lntp

You should see the Mumble server in both listings, on port 64738 each time. Depending on the version the process is named mumble-server or murmurd. If you also see 0.0.0.0:6502 instead of 127.0.0.1:6502, your Ice remote control interface is reachable from the entire internet, and that is a bigger problem of its own than any ping.

Second: the packet rate of the network card.

ip -s link show eth0

Run it twice ten seconds apart and divide the difference in received packets by ten. If that value climbs far above the normal figure while hardly anyone is connected, it is an attack. If it stays unremarkable, the cause lies with the service or the operating system. The systematic distinction is described in the article Detecting a DDoS attack on your server.

Third: a sample of the incoming traffic.

tcpdump -ni eth0 udp port 64738 -c 20

This is where a ping flood shows up immediately, because tcpdump prints the payload size. Lines reading UDP, length 12 from one and the same address mean somebody is querying your server. Lines reading UDP, length 12 from many different addresses mean somebody is using your server as a reflector and those addresses are the victims. For the TCP side, the same exercise:

tcpdump -ni eth0 'tcp port 64738 and tcp[tcpflags] & tcp-syn != 0' -c 20

Fourth: the server log. On Debian and Ubuntu it lives here:

tail -n 100 /var/log/mumble-server/mumble-server.log

It holds connection attempts, rejected logins and the automatically applied bans. A long chain of connection attempts from the same address once per second is unambiguous. Keep in mind that the configuration file has a setting which randomizes IP addresses in the log. If it is switched on, you will no longer see usable addresses there and have to fall back to tcpdump for diagnosis.

What you can do on the server itself

The following eight steps cost nothing. They help against ping abuse, connection floods and smaller UDP floods from a handful of sources. Where they stop is stated honestly two sections further down.

1. Find out which configuration file you are actually looking at

This is the step where most evenings are lost: you edit a file the running service does not read. The location changed with the rename, and the stable Linux releases follow at their own pace.

Rather than guessing, have the answer handed to you. As root:

ls -l /etc/mumble-server.ini /etc/mumble/mumble-server.ini
systemctl status mumble-server --no-pager

The second line prints the full command line of the running process, including the switch that hands over the configuration file. That is the file that counts, and no other. If you run your own build and find none of the files, look at the command line in your own unit file; how to write one is shown in the guide Creating a systemd service.

A note on the syntax of the file itself: comments start with a semicolon, not with a hash. A setting you want to activate therefore needs one semicolon fewer at the start of the line. Values without a semicolon are in effect, commented lines only show you the default.

2. Switch allowping off, or limit the ping rate

The single most important step in this article, argued in detail above. In the configuration file:

allowping=false

Then restart the service and verify that the answer really stays away. You can do that from a second machine without any extra tooling:

nc -u -w 2 your-server-address 64738 < /dev/null

Simpler and more meaningful is a look at the connect dialog of the Mumble client: if there is no latency and no user count after the change, it worked.

3. Set bandwidth and users to realistic values

Two lines that belong together, because together they define the ceiling of your server.

bandwidth=72000
users=25

bandwidth is the maximum bandwidth in bits per second at which a single client is allowed to send speech. Older variants ship 72000 here, newer ones 558000. 558000 bits per second per user is absurdly much for a voice channel, that is headroom for special cases and not the actual requirement. For intelligible speech, 40000 to 72000 bits per second are comfortably enough. The value is a ceiling and not a reservation, but it is also the value the server reports to the outside in its ping answer, and it is the basis for the worst case: 100 users times 558000 bits comes to 55.8 Mbps of inbound speech alone, which the server then distributes to everyone else.

users is the number of simultaneous clients, 100 by default. Set it to what your group actually needs plus a little room. A limit of 25 instead of 100 makes slot exhaustion four times cheaper to fend off and at the same time caps the number of voice streams your server has to replicate in the worst case. If you have ten people, you do not need a hundred seats.

4. Set a server password and drop out of the public registry

A server password is the only measure in this list that handles slot exhaustion and login floods at the same time, because both require a successful login.

serverpassword=YourLongPasswordHere

There is a side effect you need to know about, because it is often mistaken for a bug: a server password set on the server automatically removes it from the public server registry. The comment line in the configuration file states it explicitly: to enable public server registration the server password must be blank. That is not a bug, it is the rule of the registry service.

If you want to switch the listing off independently of that, leave the setting for the registration password empty or commented out. Without that password no registration takes place. Watch out for one subtlety that gets mixed up regularly: the setting for the registration name serves a second purpose on its own. If only that one is set, it merely renames the root channel without registering the server anywhere. Only the registration password together with the remaining register settings actually triggers the listing.

Be honest with yourself here: withdrawing from the registry removes one convenient way of finding your address, but it does not hide it. A scan across the address range finds an open port 64738 anyway, within minutes. Anonymity is not a protection strategy, a password is.

5. Leave only the two ports open that are needed

A firewall with a default rule of "drop everything inbound" is the foundation. Watch the order of the commands, otherwise you lock yourself out. The full procedure including the escape route is described in the guide Setting up the UFW firewall without locking yourself out. For a Mumble server the result looks like this:

ufw allow 22/tcp
ufw allow 64738/tcp
ufw allow 64738/udp
ufw default deny incoming
ufw default allow outgoing
ufw enable

Both lines for 64738 are needed. Opening TCP only forces every client permanently onto the slow path through the control connection, and nobody understands why the server sounds so bad. That mistake shows up more often than any real trace of an attack.

6. Rate limiting with nftables, separately for TCP and UDP

On all four systems named above, the packet filter works with nftables under the hood. Because TCP and UDP on the same port have completely different load profiles, they need separate rules. Create a table of your own so that an existing UFW configuration stays untouched:

table inet mumble {
    chain input {
        type filter hook input priority filter; policy accept;

        tcp dport 64738 ct state new meter mumble_conn { ip saddr limit rate over 6/minute burst 12 packets } counter drop

        udp dport 64738 meter mumble_udp { ip saddr limit rate over 300/second burst 600 packets } counter drop
    }
}

Save this as /etc/nftables.d/mumble.nft, create the directory beforehand if it does not exist, and load it as root:

nft -f /etc/nftables.d/mumble.nft
nft list table inet mumble

You undo it with nft delete table inet mumble. After a reboot the table is gone, unless the file is included from /etc/nftables.conf.

For a sense of scale on the values chosen here: with the usual setting, a speaking client packs 20 milliseconds of audio into one packet, which is 50 packets per second, plus one latency measurement per second. So 300 packets per second per source address leaves plenty of room for several people behind one shared connection. On the TCP side a normal client opens exactly one connection and keeps it; six connection attempts per minute cover even stubborn reconnecting after a network change.

If you want to leave allowping switched on because your server should stay in the registry, add a tighter rule for the ping packets only. They are recognizable by their fixed total length, which is 40 bytes on IPv4:

udp dport 64738 meta length 40 meter mumble_ping { ip saddr limit rate over 2/second burst 5 packets } counter drop

On IPv6 the value is 60 instead of 40, because the IPv6 header is 40 bytes long instead of 20. This rule is a heuristic over the packet length and not an understanding of the protocol. So after loading it, check with nft list table inet mumble whether the counter climbs while nobody is attacking. If it does, the value is too low or the length check is hitting real traffic, and you take the rule out again. allowping=false remains the clean route, the length rule is the compromise.

And now the honest assessment: against a distributed attack on your server, a rate limit per source address barely helps, because the attacker forges a new source address in every packet. Against the abuse of your server as a reflector it works very well, because there every request carries the same forged source address. Same rules, very different value.

7. Configure the built-in brake against connection floods

Mumble ships a rough brake of its own against connection floods. It counts connection attempts per address within a time window and then bans that address for a fixed duration. The ban applies across all virtual servers of an instance, shows up in no ban list, and can only be ended early by restarting the server process. Three settings control it:

autobanAttempts=10
autobanTimeframe=120
autobanTime=300

Read out: ten connection attempts within 120 seconds lead to a ban of 300 seconds. Those are the defaults, and they are deliberately generous so that a properly working client does not trip them. Against an attack from a single address you may go considerably tighter, for instance five attempts in 60 seconds with a ban of 1800 seconds. The brake can be disabled by setting either of the first two values to 0; do not do that.

There is a fourth setting that regularly causes trouble. By default, successful connections count toward that window as well. If several people sit behind the same connection and reconnect at the same time after a server restart, the server locks all of them out together. The configuration file provides a setting that makes only failed attempts count:

autobanSuccessfulConnections=false

That combination is the right one for most groups: count tightly, but only count what actually failed. One point of clarification: the brake only applies to connections, that is, to the TCP side. It does nothing against a UDP flood or against ping abuse. Steps 2 and 6 are responsible for those.

8. Keep the Ice interface in the house

Mumble can be controlled remotely through an interface called Ice, which bots, statistics scripts and web panels use. By default it is bound to 127.0.0.1 on port 6502 and therefore reachable locally only. That is the right setting and you should not change it.

Two things remain to be done anyway. Check with ss -lntp that it really says 127.0.0.1:6502 and not 0.0.0.0:6502. And set the two secrets for read and write access that the configuration file provides for; without them, any process on the server can use the interface. If a bot needs the interface from another machine, connect the two machines through a private network or a VPN instead of putting the port on the internet. An open Ice interface is not a DDoS problem, it is a takeover problem, and that is worse.

Mumble and TeamSpeak compared

TeamSpeak is the obvious alternative, and the comparison is worth making on the merits, because the two services are vulnerable in entirely different places. The TeamSpeak values come from the article Protecting a TeamSpeak 3 server from DDoS attacks, and setting such a server up is covered in Installing a TeamSpeak 3 server.

The two sentences the comparison boils down to: with TeamSpeak the most dangerous attack surface is a separate TCP port you can close without losing anything. With Mumble it is an answer on the very UDP port the service cannot do without, and switching it off costs a visible convenience feature. That does not make Mumble worse, it only moves the place where hardening is required.

Where these measures stop

All eight steps have one thing in common: they only take effect once the packet is already there. Against individual troublemakers, ping abuse and small floods that is entirely sufficient. Against a volumetric attack it is not, and for a reason that has nothing to do with your configuration.

Do the math: an uplink with 1 Gbps carries around 125 megabytes per second and, with the smallest packets, about 1.49 million packets per second. At 10 Gbps that comes to around 14.9 million packets per second. That is the hard ceiling of the line, no matter what runs on the server and how good your nftables rules are.

What matters is where that traffic piles up: not on your network card, but on the line in front of it. Once that stretch is full, the voice packets of your people are lost right there, before your server ever gets to see them. A firewall rule in the operating system cannot relieve a line that ends before the operating system. That is not a question of skill, it is a question of order.

On top of that comes processing time. Even if your kernel could drop millions of packets per second, every one of those decisions costs CPU. A voice server that is busy throwing packets away sounds just as broken as one that no longer answers at all. The general form of this problem is described in the article How to protect your server from DDoS attacks.

Past that limit only one thing helps: the malicious traffic has to be dropped before it enters your line. By definition that can only happen in the network in front of it, not on your server.

What KernelHost puts up against it

Tier 1: the always-on protection included with every server

On every KernelHost server, DDoS filtering runs permanently, at no extra charge and without you having to switch on, order or configure anything. It is built in two layers:

• Layer 1: 17 Tbps of mitigation capacity in the global scrubbing network. Volumetric attacks are cleaned up close to their source, long before they reach the datacenter. This is exactly the layer that relieves a line you cannot relieve yourself.
• Layer 2: Arbor real-time filtering with 3.2 Tbps in Frankfurt am Main. Directly in front of the server, protocol-specific patterns are recognized and dropped packet by packet, among them UDP floods and reflection traffic on the typical voice and game server ports.

Two points matter more than they sound. First, the protection is permanently active from provisioning onward and does not have to kick in first, so there is no ramp-up window in which an attack gets through. Second, no attacked IP address is taken off the network: no null-routing means your people keep talking while the filtering runs. How this looks for other services and protocols is described in the article Game server DDoS protection in real time.

Tier 2: Advanced DDoS Protection for projects under constant attack

Some projects are not hit once, they are hit for weeks. For those cases there is Advanced DDoS Protection from €50.00 per month, PrePaid and with no minimum term. It adds three things to the included always-on protection:

• A dedicated protected IP from the Frankfurt core, which your server is switched over to. No rebuilding is needed on your side.
• Self-managed protection rules per port and protocol in the customer panel. You configure 64738/UDP differently from 64738/TCP without opening a ticket, and changes take effect in real time. With Mumble that separation is the crucial part, because both protocols sit on the same port and have completely different load profiles.
• A protection profile matching the service in question, with ready-made profiles for more than 40 games and protocols, Mumble included. How those profiles work is described in the article Game DDoS protection with real-time filtering.

PrePaid means exactly that: no minimum term, no notice period, no contract, no setup fee. You add the protection for the duration of an attack wave and let it lapse afterwards. This tier does not exist for servers hosted elsewhere; it requires the server to run in our network. Anyone under constant fire who hosts with another provider solves it with a migration, not with an add-on product.

The two tiers compared

Common mistakes and how to fix them

The configuration file gets edited and nothing changes: almost always it is the wrong file. Older systems read /etc/mumble-server.ini, newer ones /etc/mumble/mumble-server.ini, and anyone running a source build has the file somewhere in their own directory. systemctl status mumble-server --no-pager prints the command line of the running process and ends the discussion.

The setting is in the file and still does not apply: check the start of the line. Comments in this file begin with a semicolon. A line reading ;allowping=false is a comment and does nothing.

After switching allowping off the server suddenly sounds worse: check in the client whether the connection is still listed as a UDP connection. If the client falls back to the TCP control connection, the delay rises visibly. In that case switch allowping back on as a test and limit the ping rate in the packet filter instead.

Only 64738/TCP is open and everyone complains about delay: that is the same effect from a different cause. Without an open 64738/UDP the voice runs over the control connection. Open the UDP port and the delay disappears within seconds.

The server drops out of the public registry after a server password was set: that is not a fault, it is the documented rule. A server with a password does not get listed. You can have either, just not both at once.

Several people behind one connection get thrown out together: that is the built-in connection brake, which by default counts successful connections too. Set autobanSuccessfulConnections=false. The ban itself appears in no ban list and can only be waited out or ended by restarting the server process.

The rate limit is set too tight and hits your own people: a typical case is a student dorm or a family behind one shared connection. To the filter that looks like a single address with a conspicuous number of packets. Check with nft list table inet mumble whether the counter climbs while no attack is running.

The firewall is armed and access is gone: on KVM root servers and dedicated servers from KernelHost you get onto the system through the VNC console in the customer panel. That console does not hang off the network stack of the guest system, so a firewall rule cannot block it. Log in there as root and switch the firewall off with ufw disable before you go looking for the cause.

Everything is in place and the server is gone anyway: then you are dealing with a volumetric attack, and there is nothing left in your hands on the server itself. Collect the values from ip -s link, the affected IP address, the port and the time of the first anomaly, and pass that on to your provider. At KernelHost you open a ticket in the customer panel; while an attack is running you can also reach us through the WhatsApp emergency chat at +43 650 8209883.

In short

• A Mumble server needs exactly one port, 64738, over TCP for control and over UDP for voice at the same time. Without UDP the client pushes the voice through the TCP control connection and the delay rises audibly.
• On 64738/UDP the server answers an unencrypted 12 byte request with 24 bytes of server details, with no login at all. That is an amplification factor of 2 on the payload and 1.3 on the IPv4 packet.
• Mumble is therefore not a bandwidth amplifier but a packet rate reflector: every request produces exactly one answer packet at the victim, and packet rate is the quantity networking equipment fails at first.
• allowping=false puts a stop to it. The price is an empty connect dialog: no latency, no user count, no bandwidth figure before connecting.
• The file name changed with the rename from Murmur to Mumble Server, the names of the settings did not. Which file applies is answered by systemctl status mumble-server --no-pager.
• A server password handles slot exhaustion and login floods at once and necessarily takes the server out of the public registry.
• A rate limit per source address is weak against an attack on your server and strong against its abuse as a reflector, because there every request carries the same forged address.
• Once the line is saturated only filtering in the network in front of it helps: 17 Tbps of scrubbing capacity plus Arbor real-time filtering with 3.2 Tbps in Frankfurt am Main, included with every server and without null-routing.