Staff

Hello! We're terribly sorry, it will not be possible. Kind regards

Hello! Of course you can ask for (and obtain) a refund, as you may have read in the original message. In order to ask for a refund you may either drop a ticket (click "Contact us" from the web site upper menu while you are logged in) or write an e-mail to support@airvpn.org, as you prefer. Kind regards

Hello! That's a pity, and apparently an unnecessary limitation. In our infrastructure WireGuard lives in one 10.128.0.0/16 subnet to make the key <> IP address static correspondence more manageable (WireGuard can't assign addresses dynamically), no need to change subnets and public key on each server. Kind regards

Hello! Well, of course... that's the servers' public key, you can't change it! Kind regards

Hello! With AirVPN you may have multiple keys per account and you may use unique keys per profile, please see here: https://airvpn.org/forums/topic/26209-how-to-manage-client-certificatekey-pairs/ Kind regards

Hello! We will act with due diligence to prevent access to residents of Italy on the purchase page. Blocking Tor on the purchase page may be unnecessary as the payment processors themselves block payments from Tor and they are certainly quite effective (probably more effective than we could ever be), but yes, if the action were within due diligence we might seriously consider it. It shouldn't be strictly necessary, both for the binding declaration where a user states he/she is not a resident of Italy, and for the identical blocking on the purchase page. It might add useless redundancy and incorrectly block non-residents of Italy, but again, see above. We can't see why not. Tor remains a viable, perfectly legal tool in most countries, Italy included, aimed at facilitating the exercise of some fundamental rights, and it is very good especially when high speeds and UDP are not required. Kind regards

Hello! The following errors: hint to an UDP block. Please check any packet filtering tool both on your router and system and make sure that no UDP block is enforced. If you find nothing blocking, it is possible that your ISP is the culprit. Maybe the block is against OpenVPN and not against UDP. To discern, please try a different connection mode: from Eddie's main window please select "Preferences" > "Protocols" uncheck "Automatic" select any line with WireGuard. The line will be highlighted. click "Save" and re-start a connection to apply the change please make sure to test a few servers in different locations around your node If the above connection mode fails too, please try the following, different connection mode: from Eddie's main window please select "Preferences" > "Protocols" uncheck "Automatic" select the line with OpenVPN, port 443, protocol TCP, entry-IP address 3 (three) click "Save" and re-start a connection to apply the change please make sure to test a few servers in different locations around your node Kind regards

@qwertyuiopas Hello, we think the moderator locked the thread correctly because you yourself wrote that the problem was resolved: Since you just wrote the opposite we have re-opened the thread and merged it with your new message, no problems. Kind regards

Hello! Customers who are not residents of Italy and purchased the service from outside Italy should not suffer any unintended suspension, even if they are transiting through Italy (for example for tourism). Should any problem arise please contact the support team. We will carefully explore different, feasible options when necessary, and this is one of them. This is because the authority will seek to enforce blocks on any company offering services to residents of Italy, regardless of whether the service is offered from another country and jurisdiction. See, for example, the request for DNS poisoning filed to Quad9, a non-Italian company that operates DNS servers outside Italy but accessible to residents of Italy. It is remarkable to note that Quad9 challenged a similar request from Sony in court, and won. Kind regards

@trekkie.forever Hello! In general OpenVPN doesn't manage this situation properly. To automate the procedure you are forced to perform, you may consider to run a script (with root privileges) on wake up. This script might send a SIGTERM to OpenVPN and re-start it, or perhaps just sending a SIGHUP to OpenVPN might suffice (to be tested though). Some ideas for systemd based Linux systems: https://unix.stackexchange.com/questions/152039/how-to-run-a-user-script-after-systemd-wakeup Kind regards

Hello! Please generate and send a system report in the following way: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/ Avoid screenshots whenever possible. From what we can see from the screenshot, anyway, the problem is caused by a potentially alien "VPN Client Adapter - VPN" which might have been installed by some other application. If we're correct then the solution is immediate, see here: https://airvpn.org/forums/topic/56643-stuck-in-a-broken-route-never-connects/?do=findComment&comment=225323 However, if the problem persists, please send us the mentioned system report. Kind regards

Hello! We regret to inform you that we will be discontinuing the service to residents of Italy as of February the 19th, 2024. From the above date, any user registering on the platform must declare that he/she is not a resident of Italy. The purchase page will have IP address-based geolocation and will not be served to IP addresses located in Italy. We will not interrupt the service to current subscribers until the natural expiry date and the refund policy will be granted as usual. REASONS FOR DISCONTINUATION The so-called "Italian Piracy Shield" is a legal framework with implementing regulation by AGCOM (Italian Telecommunications Authority) that forces operators offering services in Italy to block access to end services through IP blocking and/or DNS poisoning. The list of IP addresses and domain names to be blocked is drawn up by private bodies authorised by AGCOM (currently, for example, Sky and DAZN). These private bodies enter the blocking lists in a specific platform. The blocks must be enforced within 30 minutes of their first appearance by operators offering any service to residents of Italy. There is no judicial review and no review by AGCOM. The block must be enforced inaudita altera parte and without the possibility of real time refusal, even in the case of manifest error. Any objection by the aggrieved party can only be made at a later stage, after the block has been imposed. For further details: https://www-wired-it.translate.goog/article/piracy-shield-agcom-piattaforma-streaming-pirata-calcio-segnalazioni/?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-US&_x_tr_pto=wapp The above requirements are too burdensome for AirVPN, both economically and technically. They are also incompatible with AirVPN's mission and would negatively impact service performance. They pave the way for widespread blockages in all areas of human activity and possible interference with fundamental rights (whether accidental or deliberate). Whereas in the past each individual blockade was carefully evaluated either by the judiciary or by the authorities, now any review is completely lost. The power of those private entities authorized to compile the block lists becomes enormous as the blocks are not verified by any third party and the authorized entities are not subject to any specific fine or statutory damage for errors or over-blocking. By withdrawing service availability from Italy, AirVPN will be able to stay outside the scope of the framework and maintain integrity and efficient operations. We certainly sympathise with our fellow Italian citizens, and we will be happy to offer advice and alternatives. We would also like to remind them of our more than ten years of support for the Tor network, which is freely accessible even from Italy, and which is becoming increasingly reliable and fast thanks to a myriad of small contributions like ours. Kind regards and datalove AirVPN Staff

Hello! Unfortunately not, you need Eddie 2.23.2 or higher version. Kind regards

@kbps Thank you. Very puzzling, we can just confirm that from our testing lines in Holland and Italy the performance we get while connected to UK M247 servers is very similar to the best performance you got on the screenshot you sent us. We use WIreGuard with 1320 bytes MTU. Mullvad software forces 1280 bytes, please try with 1280 bytes MTU when you connect to our servers too. To change MTU in Eddie Desktop edition (2.23.2 or higher version required) open the "Preferences" > "WireGuard" window. If you use WireGuard configuration file, please edit it with any text editor and add in the [Interface] section the following line: MTU = 1280 Test also bigger MTU up to 1400 bytes. Kind regards

@organicchocolate Hello! Your setup is fine. On your side you may either use WireGuard or OpenVPN. You can't use them at the same time on the same machine. In many cases WireGuard can provide higher performance especially on devices without AES-NI acceleration, such as your iPhone. WireGuard kernel module, which plays an important role to make WIreGuard faster than OpenVPN, is not available in macOS, so you may also compare in your Mac OpenVPN vs. WireGuard and pick the one which can provide the better performance. Kind regards

Hello! Since WireGuard works, we can rule out that the problem is caused by a general block against UDP. Possible causes include a selective block by your ISP (UDP to certain ports, or OpenVPN in itself) or a local problem with OpenVPN and/or OpenVPN adapter We see that you have a DCO adapter, probably installed by openvpn-connect: this adapter is incompatible with OpenVPN versions older than 2.6, like the one packaged with Eddie Windows edition and may be the source of the problem. Useful clues may come from a system report generated by Eddie: Kind regards

Hello! Server load is indeed, and it has always been, one of the variables which are taken into calculation to determine the server rating and therefore recommend a server over another. Furthermore we have other inner variables which are monitored and are indicative of a server overload. In extreme cases yes, a server may be even closed to new connections due to overload, nothing new here. Such events are quite rare. Where does this assumption come from? There's no evidence that OpenVPN users are slowing down WireGuard users. The problem is mainly on the OpenVPN client side, as users running OpenVPN on agnostic networks and/or on devices not supporting AES-NI might be unable to reach the performance which they would enjoy with WireGuard. Again, whether or not prioritizing WireGuard over OpenVPN on the client side through our software default settings is not a problem due to OpenVPN stealing CPU time to WireGuard on server side (as incorrectly understood by @ms2738 too, we see now), as all servers have plenty of CPU available time for WireGuard, but a problem of customer satisfaction (in our previous message we mentioned the pros and cons which make the choice non trivial). Kind regards

@kbps @rabbit Hello! As promised we monitored the UK servers but again we did not notice any anomaly. This is what we see in the worst conditions, during peak times, from a variety of datacenters in Europe (connection through WireGuard, OS Linux or FreeBSD) to the servers in UK: More or less it's the same on all servers, during peak times. We see more than decent throughput and no significant asymmetry between upload and download. Maybe it's a problem only with peering with some ISP. We publish this not to rule out the option to have another provider in the UK, but just to show that according to our tests and monitoring there is no capping or congestion on the M247 side. @Atien That's not surprising, because the NL servers lines go directly to AMS-IX, so the probability that any other server in Europe can seriously compete with them while having connections from a residential ISP is moderate. Kind regards

Hello! We will look into the issue together with the developer. Your case is peculiar as you enforce a white list of a single server, so it is equivalent to specify the connection to a single server directly and not to a country and not in quick mode. You can be right, the manual may document more thoroughly the interaction and/or the program could manage the situation differently. Something under this respect was planned anyway, please feel free to test next releases of the Suite 2 preview: Kind regards

@ScarAtlas @roklipni @S.O.A. Hello! Please open a ticket and/or your own thread. The problem in this thread has been resolved so you might have a different problem. What's more, each one of you might have a different problem. Adding your messages in this way in a thread which already solved the original problem might probably lead you nowhere unfortunately. Kind regards

Hello! Unfortunately not. This option has been deliberately disabled by Google in Android TV systems (from version 9 if we're not mistaken). On some manufacturer's devices, apps can be launched during the bootstrap through a launcher/boot app running on high privileges but, as far as we know (we would be happy to be corrected if we're wrong), that's not possible with Sony Bravia. The second behavior (hung -> blank screen -> restart without connection) sounds like a bad crash. Please send us (either here or in a ticket to the support team) the complete report. It will contain the logcat too, so it may provide us with valuable information to understand what happened. To send us the log and logcat: open the settings view tap the paper plane icon on the top note down or copy to the clibpoard the URL that the app will give you back send us or the support team the URL Kind regards

Hello! Just for a definitive confirmation, your account is not banned and has no limitations whatsoever. It must be a local problem. In the following thread, two users with this problem found out that it was caused by BitDefender: https://forums.openvpn.net/viewtopic.php?p=120189 Can you check, if you run BitDefender? Kind regards

Hello! Yes, this problem was reported on 2.21.6, as the OP correctly specified. Do you still experience this problem on 2.21.8 and/or 2.23.2? Kind regards

@Rmanso33 Hello! Eddie "Network Lock" modifies firewall rules to prevent traffic leaks outside the VPN tunnel. The blocking rules are not permanent. Even if Eddie's exit is not clean, you can flush firewall rule or you can reboot the system to solve the problem. If Eddie was running with Network Lock on, then it was doing its job. An additional step to improve compatibility with any software is disabling Fast Startup on Windows: https://www.windowscentral.com/how-disable-windows-10-fast-startup If Eddie's exit is not clean, you will need to check DNS settings as well, because VPN DNS is not accessible from outside the VPN and it will remain set even after a reboot. You can fix by re-running Eddie and shutting down it properly, or you can operate manually: https://www.windowscentral.com/how-change-your-pcs-dns-settings-windows-10 You're not forced to run Eddie to connect to AirVPN servers. In this page you can find various alternatives: https://airvpn.org/windows/ Another software for Windows which recently has received a remarkably good feedback by AirVPN users (although it is not open source) is WireSock, please see here: https://airvpn.org/forums/topic/57174-how-to-correctly-use-the-routes-tab-to-only-route-the-torrent-client-through-eddie/?do=findComment&comment=228744 Kind regards

@salvialight Hello! You need to install resolvconf. We're not sure it's available for your Ubuntu / Pi OS version in the official repositories though. Worth a try: sudo apt update sudo apt install resolvconf wg-quick runs resolvconf to manage DNS properly. Side note: please send text and not screenshots whenever possible (in your previous message you could just copy and paste the text in the terminal). Kind regards