Staff

Hello! If you run manually WireGuard (wg-quick) and OpenVPN do you still get errors? Kind regards

Hello! Important notice: Wurren's configuration has been modified, please test again with WireGuard if you did not get satisfactory throughput. Kind regards

Hello! It's fine: the predefined server list is consulted by Eddie Android edition for the connection during the bootstrap (according to the boot list priority you have set of course) if a Master Password is not enforced. For your purpose, just use the "Favorite" server list. Add to "favorites" one or multiple UK servers according to your preferences. The quick connection mode will respect this list. Kind regards

For Eddie Desktop edition please check here: https://eddie.website/support/recommended-servers/ However the choice could be incoherent for the following bug under investigation: https://airvpn.org/forums/topic/56428-eddie-desktop-223-beta-released/?do=findComment&comment=224309 In the meantime we would recommend that you white list the country, or even better the server set, you wish to connect to. By defining a white list, Eddie will consider only servers included there, and the problem will be easily circumvented. In Eddie Desktop edition you can define a white list of servers in the "Servers" window. For example, if you prefer to connect to Canada, you can build a white list of those 3-4 servers in Canada which can provide you (according to your experience and tests) with the best performance. Kind regards

@BKK20 Hello! Just don't specify twice the same DDNS. If you need the same name for different ports, just make sure that all of those ports are forwarded for the same device (in your example ABC). Kind regards

Hello! Please select (from Eddie's main window) "Preferences" > "Protocols", uncheck "Automatic", select the line showing the connection mode you want and click "Save". Kind regards

Hello! Yes, you need to decide according to your needs. In your case we guess that Eddie must not wait for the process to end, but of course you may have different needs. Please decide on a case by case basis. For that you don't even need events, as you noticed. Just check "Activate Network Lock at startup" and Eddie will activate Network Lock even before a session starts (so you have no time pressure to connect to the VPN). It will try to do it as soon as possible. Network Lock prevents any possible traffic leak outside the VPN tunnel through proper firewall rules (iptables, nftables, pf and WFP are supported). If the Internet connection is cut off you will lose VPN connection. However Network Lock remains in place and when the Internet "comes back" your system will not leak traffic. Note: Network Lock will be disabled if you shut down Eddie cleanly; however an Eddie's dirty exit (for example a crash or a kill without grace) will not put Network Lock down, that's important for your safety. Only root by resetting the firewall could bring Network Lock down in that case. Your messages are perfectly understandable. However, if you have some issue to read help messages or instructions and you need support in different languages, the support team can read and write in French, Japanese, Spanish, Italian and German (moderately delayed answers may occur). Kind regards

Hello! In addition to what mentioned earlier, right now we have opened a brand new 10 Gbit/s full duplex server in Toronto, with high end hardware capable to push the throughput near the limit. Shifting to North America in general, we have powered up Miami with the addition of two 1 Gbit/s full duplex lines and two brand new servers with more modern hardware (each one with a dedicated line and port of course). We have improved connectivity in Los Angeles (bandwidth remains the same but now it should be more enjoyable from US residential ISPs). We are also working on New York City for a significant increase in bandwidth, stay tuned. Kind regards

Hello! Eddie can run script/binaries when definite events occur, with the privileges of the user which started the CLI or the GUI (not root). The events can be configured in "Preferences" > "Events" window . However, the message we wrote is not a solution to your main problem, which will be put to the attention of the devs, but only an inquiry into OpenSourcerer's statement in order to understand whether there's something wrong which we missed in the events management after the latest update. Several years ago Eddie Desktop edition was re-designed and split into a "frontend" and a "backend". The frontend runs with the privileges of the user which starts it, while the backend runs with root privileges. The entities run by the events are cut out from root privileges and will run as the same user who started the frontend, and no more as root. The feature remained as it is very comfortable. We deemed this modification as critically necessary because in the other way the attack surface was enlarged and could cause successful attacks with privilege escalation up to root if the attacker could gain in the attacked system any normal user privilege. The available events are (in parenthesis a rough explanation of when the script or binary is launched): App Start (something to be launched just after Eddie starts but before any session starts) App End (something to be launched as last thing when Eddie shuts down, but before Eddie finishes the shutdown - note the if "Wait for end of process" is unchecked, then Eddie will finish shut down without waiting the process to exit, of course) Session Start (something to be launched when a session (login) begins, but before a VPN connection is started) Session End (something to be launched when a session ends) VPN Pre (something to be launched when a connection is ordered, but before the connection is established) VPN Up (something to be launched when a VPN connection is successfully established) VPN Down (something to be launched when a VPN disconnection occurs) For each event you can tell Eddie whether it must wait for an exit code by what was launched or not. Kind regards

Hello! It can. In your example the proper event to start them is the "VPN Up" event. Do you experience any problem with it? For qBittorrent remember to uncheck "Wait for end of process". Kind regards

Hello! We're very glad to inform you that a new 10 Gbit/s (full duplex) server located in Toronto (Canada) is available: Wurren. The AirVPN client will show automatically the new server; if you use any other OpenVPN or WireGuard client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP for OpenVPN and ports 1637 and 47107 UDP for WireGuard. Wurren supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, OpenVPN tls-crypt and WireGuard. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses and 4096 bit DH key not shared with any other VPN server. You can check the status as usual in our real time servers monitor: https://airvpn.org/servers/Wurren Do not hesitate to contact us for any information or issue. Kind regards and datalove

Hello! Interestingly you did not have that problem on your first report: Eddie could contact bootstrap servers and download the needed information, but its pings and https tests were already blocked. Please check again any packet filtering tool and/or antimalware tool in your system and make sure that they do not block Eddie traffic. Please consider to disable completely those tools for a quick discernment test. We can't help much here. Try to remember what you installed on your system and check the running antimalware and packet filtering tools on the list of installed software. Kind regards

Hello! We're sorry, no news. Google blocks some of our VPN servers as well as VPN servers of our competitors. Moreover, some servers are not blocked, but it's the Google's authoritative DNS that blocks our DNS servers, so we have two different approaches to sabotage VPN access. That's understandable as a widespread usage of VPN, Tor etc. is a threat to Google core business, which is also pushing its own VPN in an attempt to stop the threat. Google services must never be used and if you share our mission you should avoid them at all costs, but if you want to access them from the VPN you may consider to contact Google and send them your complaints. For Google Search consider startpage.com (which helps mitigate Google Search tracking) or switch to some better search engine which does not harvest your personal data such as https://search.brave.com Kind regards

Hello! UDP (the protocol used by OpenVPN) is blocked, or OpenVPN traffic itself is blocked Usually the block comes from a packet filtering tool or an antimalware integrated tool. Since the error says "operation not permitted", the block is most likely enforced on the same machine which also runs Eddie and OpenVPN. Please check any mentioned tool and remove the block. OpenVPN may operate in TCP too, but we recommend that you remove the block because OpenVPN is more efficient in UDP and also because you can run WireGuard which can work only on UDP. In Eddie, you can switch to WireGuard from the "Preferences" > "Protocols" window, after you have unchecked "Automatic". Kind regards

Hello! Please read: https://airvpn.org/faq/port_forwarding/ and: https://airvpn.org/faq/p2p/ Kind regards

@MelonPan Not the user agent (a user agent is a different thing) but the program name and version if your program sends it. Yes, it's an information voluntarily sent by your program. If your program does not tell the server anything, this information is not available. It is meant for your comfort so you can discern and identify your devices and programs used for each connection slot in your "Client Area" at a glance. Sometimes useful for self troubleshooting too. For example seeing an alien OS that you don't run using one of your account connection slots to some server that you don't connect to may suggest something. In general very useful, not creepy at all. About the IP address, @SurprisedItWorks and @OpenSourcererexplained already, we just add that knowing the destination address is strictly necessary for every application in every network based on IP (Internet Protocol), it's not some "special" requirement of OpenVPN, WireGuard or whatever. Kind regards

Hello! You are and were correct, you can also see here the announcement: https://airvpn.org/forums/topic/56495-servers-power-up-shown-in-the-web-monitor/ Kind regards

Hello and thank you for your choice! We will have Eddie's developer investigate the issue. In the meantime please try the following settings to solve the problem: from Eddie's main window select "Preferences" > "Advanced" uncheck "Check if the VPN tunnel works" click "Save" from Eddie's main window select "Preferences" > "DNS" uncheck "Check Air VPN DNS" click "Save" from Eddie's main window enable "Network Lock" try again connections to various servers We're looking forward to hearing from you. Kind regards

Hello! Yes, what you write is substantially true, although a server reboot is not needed. The matter has become a FAQ and we added an answer to this FAQ here: https://airvpn.org/faq/wireguard/ In the answer you can see how we patch a specific problem, how you can act through our tools to improve your privacy when you run WireGuard, and all by not breaking original WireGuard compatibility. However OpenVPN under this respect remains widely superior, so consider it according to your threat model and the amount of annoyance you would get to generate new keys after each WireGuard session. Kind regards

Thank you for the important information. Kind regards

Hello! It's possible, as AirVPN Suite 1.3.0 was released on the 7th of June and Network Lock features were extensively rewritten. If you want to go back to 1.2.1 here's the direct link to the tarball for Linux x86-64. https://eddie.website/repository/AirVPN-Suite/1.2.1/AirVPN-Suite-x86_64-1.2.1.tar.gz If you decide to downgrade, please let us know whether 1.2.1 is fine on your system. Also remember to wipe out the whole /etc/airvpn directory and any goldcrest.rc file because some new directives are not supported by 1.2.1. Kind regards

@Gooberslot Thank you for the report. Can you please check whether the same problem persists when you re-enable network lock, but disable ufw completely? sudo ufw disable We ask because we have seen lately strange interactions (probably caused by translation errors) in systems based on nftables (iptables has been left apart by most distributions) when ufw kicks in needing translations and the Suite uses nftables (ufw is a frontend of a frontend of a frontend in this case, because it is able to operate through iptables only and not nftables). After that we will send all the info and report to the Suite developer. Kind regards

We're glad to know that this solution meets your needs. Thank you very much for your choice and your great feedback! Kind regards

@ProphetPX Hello! First and foremost, let's specify that the system names resolution priority is always hosts file before DNS (unless you have deeply tweaked the system, but it's not the case we guess). With that said, you can tell Eddie not to consider the server DNS push and leave your DNS settings unaltered in the "Preferences" > "DNS" window. Set the "DNS switch mode" combo box to "Disabled" and uncheck "Check AirVPN DNS". We don't know how it's possible, according to your description, that DNS push could work if DNS client service was disabled, we leave this part to Clodo. Thank you very much! Kind regards

Hello! For the selection problem, please consider this potential solution in your ovpn configuration file: remote-random remote <country>3.vpn.airdns.org remote <another country>3.vpn.airdns.org ... remote <yet another country>3.vpn.airdns.org where you list only the ISO codes of the countries you want to connect to. Please see also here: https://airvpn.org/faq/servers_ip/ About the connection instability you experience have you examined the OpenVPN log to check whether packet errors are reported (hinting to bad line or MTU size related problems)? If the device is connected via WiFi, try to change channel and/or get a stronger signal. If you suspect that the problem is MTU related, try the following directive (in the ovpn configuration file) and check whether it mitigates the problem: mssfix 1280 Kind regards