Discontinuing subscription. Feedback

[Janice Redfern 0]

Greetings fellow Airians,

I'm a Mullvad refugee and tested AirVPN for a short time to see if it could replace Mullvad. Unfortunately, while AirVPN seems to be the ethical choice and is European, it isn't on par with Mullvad and my search for an alternative continues. 

Issues
- Frequent disconnects with no reconnection, even on a stable network (WiFi home connection and mobile connection)
- multiple slow servers
- Upnp not used for port-forwarding
- Desktop app idiosyncrasies:
  * slow interface
  * unlabeled buttons that don't have clear functions
  * problems exiting (it just hangs and has to be sigKILLed)
  * UX for connecting is unclear; connection to server directly, not country
  * cannot generate wireguard configs for different device (flneeded for headless device) 
  * Wireguard config does have a "DNS" line, so DNS resolution doesn't work

Recommendations

Develop opensource clients that allow other VPN providers to just plugin their details (login server or whatever) and use a common API definition (e.g GET /api/v1/servers) for common VPN actions like getting servers, filtering them, generating wireguard configs, etc.). By making the client generic and allowing other providers to plug in their details, it would allow them to contribute and improve the app together.

The opensource clients should at least be inspired by other apps which make their usage dead simple.

And regarding connection stability, add a kill switch and the ability to reconnect automatically. And add some way for people to create debug traces to help debug. When the connections dropped and didn't reconnect, I had no idea where it came from. Other VPNs were just stable, so debugging was never necessary, so to be fair, maybe they suck at debugging stuff too.

Also, for P2P, the experience was just bad. It was not clear from the webUI that port forwarding was manual and had to be done at all.

Final words

I really wanted this to work and support a cause that feels like it's protecting privacy without funding fascism, but the service provided just doesn't work well. If things improve, I might return, but at the moment, this isn't usable by the average person, which drastically reduces the possible market range. 

Good luck in the future 

[Tech Jedi Alex 1581]

3 hours ago, Janice Redfern said:

Develop opensource clients that allow other VPN providers to just plugin their details (login server or whatever) and use a common API definition (e.g GET /api/v1/servers) for common VPN actions like getting servers, filtering them, generating wireguard configs, etc.). By making the client generic and allowing other providers to plug in their details, it would allow them to contribute and improve the app together.

It would also lead to the situation Intel found themselves in: Spearheading open source systems development (for decades), then noticing everyone's profiting off those open source projects while very little is given back to them. Actually, the state of pretty much all open source software less popular than flagships like Firefox. You can't seriously believe competitors will gladly put work in such a client, and after a nice day's work eat ribs and sing kumbaya with everyone? Markets are shady and unscrupulous, and the VPN market doubly so.
Eddie can be used as a client for other OpenVPN config files, but expandig that part simply requires more manpower there, and Eddie on PC is developed by one guy. That feature has been there for years; where are the competitors expanding on that feature to include their own infrastructure? Simply not happening. During or after that feature came out, all those competitors started or had already their own clients – and even Wireguard implementations.
Also, not sure whether Mullvad ever had an API as comprehensive as Air's; I found these docs which are just.. barebones, somehow. Or maybe it's just the docs, the OpenAPI specs include many more endpoints. But hey, maybe AirVPN doesn't boast a Swagger UI or similar (because the API is not REST), but even then the API is as comprehensive, maybe even more so, and follows a standard. This is not a point you can complain about.
 

3 hours ago, Janice Redfern said:

And regarding connection stability, add a kill switch and the ability to reconnect automatically

Already implemented, but not as a kill switch but as Network Lock, a set of firewall rules. And it does reconnect automatically. Unless you configured it not to do so. If you didn't, I'm sure especially the dev would've liked to know about it. All softwares have bugs.
Sadly, this seems to not have happened; since this is your first post in these forums, I believe there was no request for help from your side; you went straight to complaining. Are you German, by chance?  No offense.
 

3 hours ago, Janice Redfern said:

And add some way for people to create debug traces to help debug

There is, but you didn't read the manual/doc and didn't seek help (the responders would've told you how to provide such a trace; I probably would've been such a responder), so you can't know there is, making your point moot.
 

4 hours ago, Janice Redfern said:

Also, for P2P, the experience was just bad. It was not clear from the webUI that port forwarding was manual and had to be done at all.

To be fair, it does make sense mentioning this requirement in the UI. It is correct that uPnP is not in use. But this has a very simple reason: uPnP can by mistake open the remote port on your router which would expose you to correlation attacks. So port forwarding is manual.
But still, it's a good improvement request.
 

4 hours ago, Janice Redfern said:

but the service provided just doesn't work well. If things improve, I might return, but at the moment, this isn't usable by the average person, which drastically reduces the possible market range. 

And that's perfectly okay. If it doesn't work for you, please look for something else; the market is quite big.

[Staff 10693]

On 7/31/2026 at 1:08 PM, Janice Redfern said:

Develop opensource clients that allow other VPN providers to just plugin their details (login server or whatever)

Hello!

This is an interesting smearing message that occasionally comes out, trying to exploit the forum we keep open for the community, for some hidden purpose or, we guess, just for hate. You can easily verify that every defect mentioned by the OP is either false or distorted. A community moderator provided some corrections that disprove the OP's claim, here we would like to add just three remarks on subjects we care about: interoperability with other VPN services, infrastructure stability and how good our remote port forwarding system is. We also want to quickly make you aware that the OP never opened a ticket for professional support, so he/she was probably not interested in a solution of his/her problems, but maybe only in building a case based on false or fabricated premises.

1. Eddie Android edition, AirVPN Suite and Eddie Desktop edition allow connections to any VPN supporting either OpenVPN or WireGuard through the most standardized method that can exist, the supported profile for each VPN application (much better than any API, especially when it does not exist on most VPN services).

2. Over the past 16 years AirVPN infrastructure constantly evolved toward more stability and speed, it's all in the records.

In AirVPN we have had and we have users connected CONTINUOUSLY for SEVERAL MONTHS. Enough for connection stability? 😉 We could have even longer periods, if it wasn't for the necessity to reboot a server periodically for kernel upgrades.



3. Implementing remote inbound port forwarding over a VPN by having the VPN server use UPnP/NAT-PMP/PCP to dynamically open ports on behalf of clients is generally considered a poor architectural choice because:

• UPnP was designed for trusted, local networks
• No authentication in classic UPnP IGD exists
• Race conditions in a large infrastructure like AirVPN's one becomes an architectural problem
• UPnP would make "hot change" and other interesting features appreciated by AirVPN customers impossible
• Privilege escalation. UPnP used outside a local network facilitates various exploits including privilege escalation.
• The VPN server already controls firewall rules, NAT, routing and connection tracking. Using UPnP as an intermediary adds another protocol layer rather than configuring those systems directly. This depends on your design philosophy, but at the moment management does not see favorably functionality duplication.

At the end of the day, such a poor choice would pose a bunch of problems for essentially nothing, as selecting a random port with the additional features is a matter of seconds.

Kind regards