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