Mullvad pulled port forwarding — is anyone still running anything real on it?

They pulled port forwarding on the 1st and I have spent three weeks pretending that does not matter.

Context so nobody has to ask: not torrenting. I have two boxes that need to accept an inbound connection from a machine sitting behind the tunnel, and the clean way to do that was a forwarded port. Now there isn't one.

So the question is whether anyone has found a shape of setup that survives this without going back to a plain VPS with a public IP, which is the thing the tunnel was there to avoid. Or is outbound-only just what the product is now and I should stop sulking about it.

FWIW everything else is unchanged. Account number, no email, Monero still knocks 10 percent off, five euro flat like it has been for years. It is the only service I pay for that has never asked me for a name.

it was never an inbound product. you used a side effect for four years and now it's gone

The forwarded port was the part that made you findable and you are annoyed it is gone.

An open inbound port on a shared exit is an identifier. Anyone who can reach it can correlate against everything else leaving that exit, and the provider has to hold routing state to make it work at all. Removing it is the first change they have made in years that improves the thing I actually pay for.

If you need inbound you need a box you control terminating it. That was always a different problem and no five euro tunnel was ever going to solve both.

Is correct and is also annoying, both can be true.

I move inbound to small VPS with wireguard, keep the tunnel only for browsing. Anyway two jobs, two things. Was my mistake to have one thing do both for so long.

Accepting inbound from where, and from how many sources? Most people who say they need a forwarded port need a reverse tunnel and have not noticed.

This comes up every time a provider drops a feature and the answers are always about the feature rather than about what it was standing in for, so let me do it the other way round.

What the forwarded port was actually doing

It gave you a stable, publicly reachable endpoint whose address did not belong to you. Two properties in one, and they are separable. The reachability you can rebuild anywhere. The not-belonging-to-you part is the one worth paying for, and it is the part that a consumer VPN was never a good vehicle for, because the endpoint was shared with a few hundred strangers whose behaviour you do not control.

Three replacements, roughly in order of effort

1. Reverse tunnel to a cheap box. Rent something small, give it the public IP, and have the machine behind the tunnel dial out and hold the connection open. Nothing inbound ever hits the machine you care about. This is the correct answer for the majority of cases and it costs a few euro a month. The trade is that the box now exists, is registered to something, and is paid for by somebody.

2. A provider that still forwards. IVPN kept port forwarding and multi-hop, which is exactly why the power-user crowd has been drifting there. Same anonymous account ID model, crypto only, Gibraltar rather than Sweden. Worth noting the price is quoted against a three year commitment, which is a strange thing to sign up for with a service you chose specifically so you could walk away from it.

3. Stop needing inbound. Polling is unfashionable and it works. If the thing behind the tunnel can check a queue every thirty seconds instead of being called, the entire problem disappears. I have replaced two of these in the last year and neither one noticed the latency.

The option I keep seeing suggested that I would not take

Moving to a big-brand provider because it has a free tier. Proton is competently run and Switzerland is a fine jurisdiction, but signup wants an email and once there is an email in the account there is a thing to subpoena that did not previously exist. If your reason for using an account-number provider was the absence of that field, do not trade it away for a feature.

Where I am uncertain

I have not tried to run a high-connection-count service over a reverse tunnel — my own is a handful of long-lived connections and it is boring. Somebody with real concurrency should say whether that falls over.

Summary: the port is not the thing you lost, the free public endpoint is, and you rebuild it on a box or you design around needing one.

Four years of free inbound and now a eulogy. Moving.

Every one of these services eventually removes the feature that the technical half of its userbase came for, and every time the forum reaction is to treat it as a betrayal rather than as the provider reading its own abuse queue.

In 2014 you could get a forwarded port on basically anything, free VPNs included, because nobody had worked out yet what people were doing with them. Then everybody worked it out at once. The interesting question is not whether five euro is still good value — it obviously is, it has been the same five euro for the better part of a decade while everything else doubled — but whether you built something whose survival depends on a single provider's product decisions. If yes, that is the bug.

Two sources, both mine, both fixed. So yes — reverse tunnel, as several of you said before I finished reading.

Rebuilt it last night. Autossh holding a remote forward open, restarted by systemd when the link dies, which on a residential line is roughly daily:

[Unit]
Description=reverse tunnel to edge
After=network-online.target

[Service]
Environment=AUTOSSH_GATETIME=0
ExecStart=/usr/bin/autossh -M 0 -N \
  -o ServerAliveInterval=20 -o ServerAliveCountMax=3 \
  -o ExitOnForwardFailure=yes \
  -R 127.0.0.1:8443:127.0.0.1:8443 edge
Restart=always
RestartSec=15

[Install]
WantedBy=multi-user.target

The two options that matter are ExitOnForwardFailure and the keepalive pair. Without the first, autossh happily reconnects into a session where the forward silently failed to bind because the old one has not been reaped yet, and you get a tunnel that is up and does nothing. Took me an embarrassing amount of time to find that the first time.

Depends what you're running, but if the edge box is now load-bearing then treat it like it is. Separate payment trail from anything else you own, and do not put it in the same account as the boxes it is fronting.

People build the tunnel carefully and then buy the endpoint on the same invoice as everything else, which undoes the work in one line of somebody's billing export.