Staff

@darksent21 Hello! Your idea is totally correct but unfortunately Android forbids (for unfathomably alleged security reasons or waffling technical oversight) the phone to work as a hot spot in tethering mode when in a VPN. So you can't share the VPN traffic with an un-rooted Android device working as a hot spot. Technically, it's because Android VPN tethering system app fails to set the proper packet pre-routing and forward rules for a virtual network interface. However, if you have a rooted device you can fix the problem by adding the missing mangling rules with iptables. Please see here: https://android.stackexchange.com/questions/60819/can-i-share-my-androids-vpn-connection-over-a-hotspot Kind regards

Hello! Please try the following procedure: https://airvpn.org/forums/topic/58289-openvpn-certificate-has-expired/?do=findComment&comment=231319 Kind regards

Hello! Nothing wrong on your side, you performed the procedure correctly. The error changed, now it is very different: . 2024.04.18 01:49:20 - OpenVPN > TCP: connect to [AF_INET]192.30.89.29:443 failed: Unknown error Knowing that the error is "unknown" does not help so much, but at least the previous problem is solved. Do you run any antimalware tool which could be blocking OpenVPN and cause this unknown error? What happens if you switch to WireGuard? To do so: from Eddie's main window please select "Preferences" > "Protocols" uncheck "Automatic" select the line with WireGuard port 51820. The line will be highlighted click "Save" and test again connections to various servers Kind regards

Hello! You can test different MTU values. Please install Eddie 2.24.x (if you haven't already done so) and change MTU on "Preferences" > "WireGuard" window. Please try all the possible values to determine which one can provide you with the best performance. Each time you change value you need to re-start the VPN connection, in order to apply the change on WireGuard. Please make sure to perform a variety of "speed" tests on a level playing field. Also, please make sure to test servers in a variety of locations around your node. The limit of 5 ports can't be increased at the moment, we are very sorry. We are working to power up remote inbound port forwarding system in order to avert port depletion and also be able to offer a larger quantity if needed. Stay tuned and welcome aboard! Kind regards

@b0sszkr1 Hello! Do you still get this error? . 2024.04.17 13:43:12 - OpenVPN > AUTH: Received control message: AUTH_FAILED If so, try to delete the following file while Eddie is NOT running: C:\Users\ag\AppData\Local\Eddie\default.profile Then re-start Eddie (you will need to re-enter your AirVPN credentials and the custom options you wish) and test again. Kind regards

@b0sszkr1 Hello! We see that you renewed your OpenVPN key and certificate very recently. Eddie updates them only when an account logs in (this behavior will change in future versions). Please try the following procedure: run Eddie log your account out log your account in try again a connection Kind regards

@AirGuy24 Hello! The route check failure claimed by Eddie seems correct, because it is confirmed by WireGuard: Therefore, this problem could be peculiar to the WireGuard code implemented in Eddie 2.21 (or Eddie is blocked by some other blocking tool, can you please check?) and the new WireGuard resolves the problem. Can you please test whether or not the same problem occurs with Eddie 2.24.x? Please see here to download it: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ Kind regards

Hello! Please try the following procedure to quickly resolve the problem: run Eddie on Eddie's main window uncheck "Remember me" log your account out log your account in (you'll need to re-enter your AirVPN credentials) try again a connection Kind regards

@overmorrow Hello! Do you have the package mono-runtime-common available for your system? If so, try to install it and test whether the problem gets solved. Of course a portable program should not require external installations, but at the moment that's a workaround for a "quick and dirty" patch. Kind regards

Hello! Well, very strange case. BTW, ca.crt is just a public certificate and is always the same, so no, the Configuration Generator is not strictly needed, once any account has the ca.crt, it can be sent to any other account. The client certificate and key, on the contrary, are secret and non-sharable files. Kind regards

Hello! Just in case it may help, Eddie Linux edition handles automatically OpenVPN over SSL, you can just set it in the "Preferences" > "Protocols" window. Once connected run the Tor Browser. Eddie is available even in a deb package for super-easy installation in Debian, Ubuntu and derivatives. If you don't want to run Eddie you can follow the instructions available here, but the setup is more complex: https://airvpn.org/ssl/ Frequently, OpenVPN over SSL is not necessary. OpenVPN in tls-crypt mode (the default connection mode in our service) is able to bypass any block against OpenVPN just like OpenVPN over SSL does. in your subscription unlimited technical support is included, so you don't have to pay anything, just contact the support team by opening a ticket or writing to support@airvpn.org, if you haven't already done so. Kind regards

@jowlo Hello! You must enter the Configuration Generator while you are logged in to the web site with an account having a valid plan. If you try to enter with an account that does not have access to AirVPN, the CG can't generate anything because the account does not have an OpenVPN certificate or a WireGuard key etc. To clarify, when you try to enter the CG from an account which does not have any valid certificate and/or key, you get a descriptive error message. "jowlo" has never had a valid plan to enter AirVPN, probably you have a different account, please check. Kind regards

Hello! It does. End-to-end encryption ensures data integrity and confidentiality between you and the recipient. End-to-end encryption must be used, properly and correctly, no matter what (with or without VPN, with or without Tor...). By adding AirVPN you enhance your privacy as nobody in the middle (including your ISP) comes to know that you and your recipient are communicating with each other (if necessary, you may hide your identity to your recipient too). As the Electronic Frontier Foundation pointed out, knowing who communicates with whom is a sensitive information which can be used against citizens' privacy even when the communication's content is encrypted. In this peculiar sense, privacy enhancement is also a security enhancement. In this specific case the AirVPN additional protection may or may not be necessary, according to your threat model. Let's imagine an hard case: your threat model includes an adversary which systemically wiretaps your lines. When this happens, hiding to that adversary the location of where you're uploading important amount of data is a layer of protection in itself: it may be a very good thing, and indeed a security feature, to prevent your adversary to know which datacenter you rely to store your data and so on, even when everything is encrypted. This is a real security enhancement (you cancel the knowledge of a crucial access point from the attack surface): even if the adversary can't decrypt your data, it can either destroy them, make the machine where they are stored inaccessible, or further encrypt them to ask for a ransom, if it comes to know their location and cracks the access system. Avoid it whenenver possible, but there are some cases where it comes in handy. Imagine that you have to cross the borders of a country with questionable practices towards foreign citizens and you want to avoid a compulsory, time-consuming and stressful analysis of your mobile devices or laptop (with the obligation to provide the decryption password, otherwise you will be charged as a criminal). To avoid this hugely stressful and time-consuming action, the usual solution is to upload the complete device image (heavily encrypted of course) to a service that you know you can access from abroad, and download and restore the image well after you have crossed the border. So you can cross the border with a dummy phone/tablet/laptop completely empty of any of your sensitive data, with just a few apps to make the inspection and intrusion quick and painless, or with no device at all, and then buy a new one and restore the image you have stored on some globally accessible server (of course, some passwords must necessarily remain stored in your mind). Kind regards

Hello! If the screenshot was taken while the system was connected to the VPN, it is fine: the DNS pushed by the VPN server is a private DNS for Android and in general (private address). You can check what your system says when it is disconnected from the VPN by entering the "Private DNS" view. You have three options: "on" sets the default DNS defined by the device manufacturer, "off" selects Google DNS, "manual" sets the DNS picked by the user. If you have a rooted device, you can permanently change the forced manufacturer and Google DNS. Kind regards

Hello! It's unexpected, can you please attach the link to a system report, generated after the problem has happened? Please see here to do so: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/ Can you also test Eddie 2.24.x and check whether the problem persists or is solved? Please see here to download Eddie 2.24 beta version: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ Kind regards

@overmorrow Hello! Developer will be alerted, in the meantime can you please test whether or not the same happens with the Eddie 2.24 portable package? Please see here: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ If it does, you may try the AppImage as a momentary workaround. Kind regards

Hello everyone! We hereby publish the Community Forum policy in response to requests for clarification as apparently the generic invitations to comply to Netiquette are not sufficient. We will spread this information throughout the platform if necessary. This document pertains only to Community forums and not to AirVPN forums for official AirVPN communications and guides, where only AirVPN staff can open new threads. The Community Forums are managed and maintained by AirVPN, inside its own infrastructure, and are intended to be an environment to: improve AirVPN services through community driven suggestions provide an old style, relaxed platform for customers to get technical help in addition to the core assistance provided by the professional AirVPN customer care and support team. Community forum is open to everybody, including non-AirVPN customers, and moderated by AirVPN staff. Community moderators may be appointed by AirVPN staff on a voluntary basis to improve moderation. Messages posted on the forums and authors must comply with the following rules: Message content and author's behavior must respect Netiquette rules as described here: https://www.britannica.com/topic/netiquette Content must be rigorously on topic. The topic is specified in the description of each forum or made explicit in the name itself. Any form of explicit or surreptitious advertising for third party companies or private activities is prohibited. Moderators have the task to enforce compliance with the above rules. Messages that violate the rules can be deleted. When possible, moderators will inform the author about the infringement. Authors of two or more messages whose content violates the rules can have their accounts temporarily prevented from posting in the forum. If the author of a message reputes that a moderator made a mistake in the moderation actvity, communication with the moderator is encouraged. If the author is still unsatisfied by communication with the moderator, AirVPN staff can be contacted at info@airvpn.org. The staff undertakes to examine author's' complaints within a reasonable time not exceeding 30 days. Kind regards and datalove AirVPN Staff

Yes. I also set the MTU to 1320, because that's what the AirVPN conf file said. Hello! Please lower it even more to 1280 bytes and test again. Cases requiring the minimum possible MTU accepted by WireGuard are rare but not impossible. EDIT: ONLY through WireGuard directive, the small MTU is needed on the VPN interface. Do NOT touch the MTU of the physical interface. Kind regards

@TToD Hello! Please feel free to open a ticket and the support team will examine the problem and suggest a possible solution. Make sure to include the OpenVPN log showing the connection attempt failure. On the client side TLS Crypt improves ability to circumvent blocks because in the first phase of the TLS negotiation the "client hello" and the "server hello" are already encrypted by the pre-shared TLS key, therefore the OpenVPN initialization remains hidden from the ISP. All the other steps are the same. You have no urgent reason to switch to TLS Crypt since your ISP does not block OpenVPN. Kind regards

@TToD Hello! To clarify, be aware that europe.vpn.airdns.org will resolve into entry-IP address 1 of some VPN server in Europe. Entry-IP address 1 accepts only TLS Auth. You must have europe3.vpn.airdns.org for TLS Crypt with tls-crypt.key, and europe.vpn.airdns.org for TLS Auth and ta.key. TLS Crypt encrypts completely the whole OpenVPN Control Channel and therefore it is superior in its ability to bypass specific blocks against OpenVPN when TLS Auth may fail. Kind regards

Hello! You might be running an nft version that supported a different syntax, or this was a peculiar error in Eddie 2.19.7. Please try to rename the "nft" utility as a momentary workaround. Eddie should fall back to iptables-legacy (if we're not mistaken that's supported in your system) and the problem should be resolved. From your description we also infer that you can't run Eddie 2.24 beta testing version in your system; if that's correct, feel free (if you haven't already done so) to warn the developers in this thread: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ Kind regards

Hello! Yes, as you can see on the forum all the users who had the obsolete ca.crt resolved the issue and the same happened to those who opened a ticket. Which Operating System and which OpenVPN version do you still experience the problem with? Can we see the OpenVPN log taken after a connection attempt has failed? Kind regards

Hello! Again: Apr 13 02:18:01 openvpn 39844 SIGTERM[soft,auth-failure] received, process exiting Apr 13 02:18:01 openvpn 39844 TCP/UDP: Closing socket Apr 13 02:18:01 openvpn 39844 AUTH: Received control message: AUTH_FAILED You renewed your client certificate a few hours ago, and locally you have the previous certificate (which is no more valid due to the renewal you did). This is confirmed as the current user.crt certificate of yours expires in 2034, but locally you have: showing that you have the old certificate you revoked. EDIT: remember to update again the user.key too. Kind regards

Hello! Authorization failure. Can you please re-check your user.crt and user.key too? Kind regards

Hello! What you can do is binding a program to a network interface. In macOS the VPN interface name is "utunx" where x is a digit. By binding the torrent program to the proper utun interface you will prevent traffic leaks outside the VPN tunnel (of the torrent program only, of course). Various torrent programs offer this feature in the settings, but probably not all of them. To prevent traffic leaks in any case, and even for those programs that don't offer a bind option, please enable the "Network Lock" feature available on AirVPN software (Eddie macOS edition). Network Lock is a set of firewall rules which will prevent any possible traffic leak. The rules remain in place until you don't explicitly disable them or you cleanly shut down Eddie. Kind regards