Leaderboard

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

This is curious, maybe this is what I've been experiencing? I've jumped around between Revati, Sarin, Xamidimura, and Maia. I went ahead and bought a new router this week, over $300, got tired of the old router's limitations/issues and wanted to get something future proof. Unfortunately even on this one, I dropped downstream connection again yesterday evening, and even just now a few minutes ago. I also want to add that I am using two STP Cat6a cables, one between my modem/router and one between my router/desktop. They are pretty new too. Despite the above though I still seem to only experience issues with AirVPN only. I don't have issues with other VPN services.

They will be lifted automatically after a certain small amount of approved posts, just keep posting.

I've been a happy customer for a long time now. And I have a long time commitment to AirVPN too, with my plan not expiring for four more years. In the past few months the situation with servers load has gone from bad to worse. It's become noticeable in all applications. P2P above else, where I have a pretty firm idea of what the performance can be. This is my current performance under AirVPN. This is my current performance outside the tunnel. Before the recent influx of new users the situation was far better. Sad state of affairs and I'd like to understand if AirVPN is planning to so something to remedy the situation or if I have to look elsewhere in order to properly use my connection. Thank you. Even though the message might not sound like it, I'm a big fan of AirVPN and of their overall mission.

In what way would this be equivalent to using the same password in multiple places? You are not sharing your private key with the wireguard server like you would be with a password, you only share a public key. It's literally a feature of Wireguard to have multiple peers on the same tunnel. For this to happen you would be using the same wireguard tunnel (therefore the same key) to connect to both peers (in my case AirVPN and my home network). But I cannot use this feature because I do not trust the safety/security of my AirVPN-generated key pair. So yeah, currently I am doing what you are advising (two different tunnels therefore two different keys) but the experience is much worse than it could be, since you cannot have both tunnels active at the same time on Android. I need to choose whether I want to be able to access my home network or have my traffic tunneled through VPN.

In my case, that would not be the sole purpose of the key. The key would also be used to authenticate myself against my own wireguard server, which is the reason I want to remain in control of this key. If I were to do this setup currently, I would have to put complete trust in AirVPN to keep this key safe. Anyone with the key could authenticate against my own wireguard server, which is where the risk comes from. Keeping my private key stored locally and only providing the public key would definitely be preferred.

I also would like to see this option. For an example use case -- I have a wireguard tunnel set up between my home network and offsite devices. I already have generated keys, and can provide the public key (which should be all that is needed on AirVPN side). If I had this option, I could use the same wireguard key on my offsite devices with 2 peers (home network and AirVPN, only allowing local traffic to home network). Currently, the only option would be to use the private+public key pair combo generated by AirVPN, and allow that on my tunnel at home which would not be acceptable security wise. In that case then AirVPN or anyone who obtained the key would be able to VPN into my local network. It would be better to never have the private key stored anywhere else.

No, it is just that – a functionality thing. As written above, and I write it again, this key is not used for encryption, only for authentication against a server, so providing your own key is a completely unnecessary feature. One of the reasons is Mr. Envy1851's situation: You should know that you're not supposed to use the same password in multiple places, so how is using the same key in multiple places any better? Your reasoning is really off and not something to be encouraged by offering such a feature.