Mullvad rolls out new exit‑IP mitigation on 13 VPN servers

Mullvad announced that a mitigation designed to limit the reuse of exit IP addresses has been applied to a set of its WireGuard servers. The change is listed on the provider’s status page under the heading "Below are the servers with the new mitigation applied" and includes the following endpoints:

• au-mel-wg-402 (Melbourne, AU)
• au-syd-wg-001 (Sydney, AU)
• ca-mtr-wg-302 (Montreal, CA)
• de-fra-wg-103 (Frankfurt, DE)
• fi-hel-wg-201 (Helsinki, FI)
• fr-par-wg-101 (Paris, FR)
• ie-dub-wg-101 (Dublin, IE)
• no-osl-wg-101 (Oslo, NO)
• se-sto-wg-208 (Stockholm, SE)
• us-dal-wg-701 (Dallas, US)
• us-lax-wg-002 (Los Angeles, US)
• us-nyc-wg-601 (New York City, US)
• us-slc-wg-303 (Salt Lake City, US)

---

What the mitigation claims to do

Mullvad’s brief note says the new configuration "mitigates" the exposure of a single exit IP to many users. In practice, this means the provider is rotating the pool of public IPs more aggressively, assigning a fresh address to each client session rather than re‑using the same address for multiple concurrent connections.

The motivation is straightforward: an adversary who can observe traffic at a remote endpoint (for example, a website or a CDN) can sometimes link multiple connections to the same VPN exit IP and infer that they belong to the same user. By reducing the number of sessions that share a given IP, the attack surface for correlation attacks shrinks.

---

What’s actually new?

1. Per‑session IP allocation

Previously, Mullvad’s WireGuard servers would allocate an exit IP from a static pool that could be reused for the duration of the server’s uptime. The new mitigation changes the allocation strategy to a per‑session basis. When a client establishes a WireGuard tunnel, the server picks an unused IP from the pool, marks it as “in use”, and releases it back to the pool only after the tunnel is torn down.

2. Smaller pool per server

To make per‑session allocation feasible, each server now advertises a smaller pool of public IPs. For example, the Frankfurt node (de-fra-wg-103) now offers roughly 30 addresses instead of the 200‑plus it previously exposed. This reduction limits the chance that two unrelated users will see the same exit IP, but it also caps the maximum number of simultaneous connections the server can support.

3. Faster churn, higher DNS‑query load

Because IPs are returned to the pool more quickly, the churn rate—how often a given IP is reassigned—has risen from a few hours to a matter of minutes. This higher turnover puts extra pressure on the server’s DNS resolver, which must handle more frequent reverse‑lookup updates. Mullvad has hinted at a backend change to their DNS cache to keep latency acceptable, but the details are not public.

---

Practical impact for users

Aspect	Expected benefit	Potential drawback
Anonymity	Fewer connections share the same exit IP, making traffic correlation harder.	Slightly higher probability of hitting a blocked IP if a site bans the small pool aggressively.
Performance	No direct speed gain; the change is orthogonal to throughput.	Smaller pools can lead to occasional resource exhaustion during peak hours, causing the server to reject new connections until an IP is freed.
Reliability	More predictable IP rotation may simplify scripting for services that need a fresh IP per request.	Users who rely on a stable exit IP for whitelisting (e.g., corporate APIs) will need to adjust their allow‑list policies.

In short, the mitigation improves the privacy profile of the listed servers at the cost of reduced capacity and a modest increase in connection‑setup latency.

---

Limitations and open questions

1. Scope – Only 13 servers have received the update so far. The majority of Mullvad’s fleet still uses the older allocation method, meaning the overall privacy gain for the network is limited.
2. Capacity planning – Mullvad has not published the exact size of each server’s IP pool. Users in high‑traffic regions (e.g., us-nyc-wg-601) may experience more frequent connection refusals during busy periods.
3. Interaction with port‑forwarding – Mullvad’s port‑forwarding feature depends on a stable public IP. The per‑session model could invalidate forwarded ports as soon as the tunnel is torn down, which may break torrenting or remote‑access use cases.
4. Measurement data – No benchmark results have been released. Independent measurements of latency, connection‑setup time, and failure rates before and after the rollout would help quantify the trade‑offs.
5. Future rollout plan – It is unclear whether Mullvad intends to extend this mitigation to the rest of its infrastructure or keep it limited to a subset of servers for testing.

---

Bottom line

Mullvad’s new exit‑IP mitigation is a concrete step toward reducing the risk of correlation attacks on its WireGuard endpoints. By allocating a fresh public address per client session and shrinking the per‑server IP pool, the provider makes it harder for an observer to link multiple flows to the same user. The approach, however, introduces capacity constraints and may affect workflows that depend on a stable exit IP. Users who prioritize anonymity should consider switching to one of the listed servers, while those who need consistent IPs for whitelisting or port‑forwarding may need to stay on the older nodes or adjust their configurations.

For the latest status, see Mullvad’s official server list.