Staff

Hello! Is it 5-10% of a single core or the whole CPU? Can you tell us your Operating System name and version and the Eddie version? Kind regards

@calcu007 Hello! Please use a configuration file generated for OpenVPN 2.6 without DCO and you should resolve the problem. In the Configuration Generator please enable "Advanced" mode and then select "2.6 no-dco" from the "OpenVPN profile" combo box on the right. Generate and import the configuration file as usual. If the workaround doesn't work please consider to switch to WireGuard if possible. Instructions are available here: https://airvpn.org/ios/wireguard/appstore/ You might gain performance as a nice side effect. Can you please tell us the OpenVPN app version you're running? We failed to reproduce the problem with any configuration profile and we run openvpn-connect 3.4.1 linked against Ovpn 3.8.3. Kind regards

@LateStageCap1t4l12m Hello! You can disconnect from the VPN by ordering a disconnection to the program you run to connect to the VPN. For example, if you run Eddie, the Air client software, you may click the "Disconnect" button in the main window or, in the Android edition, the "power" button in the main view. If you run another program please read the manual of that program. If you experience any issue please mention your Operating System name and version as well as the connecting software name and version. Kind regards

New version 2.24.2, primarily containing bug fixes related to the Linux build. [bugfix] [windows] Shortcut .lnk for all users [bugfix] [linux] Fixed a systemd-resolved issue that caused wrong "DNS of the interface x switched to VPN DNS - via systemd-resolved" [bugfix] [linux] An issue with tray-icon at exit [bugfix] [linux] A concurrency issue that caused the application not to close [bugfix] [linux] Dependency to mono-runtime-common (only on .deb packages) [bugfix] [linux] Minor fixes [bugfix] [linux] Arch build in AUR

@ctss36pwwon Hello! OK that's fine, a mistake can be made by anyone and anyway we were genuinely interested in knowing the basis of your allegations, since M247 provides something like 20% of our global bandwidth, which is a remarkable amount. Glad to know that there's no basis, then. Sarcasm is welcome here except when it serves the purpose to write defamation in disguise. Please keep in mind that errare humanum est, perseverare autem diabolicum. Usually we leave the moderation to the community moderators but throughout the years we were forced to chime in for annoying and potential defamatory cases, so we prefer when possible a moderate prevention. Do you have the HN link we asked for, regarding the mega-leak you mentioned? Thank you for your great feedback. Kind regards

Hello! Assuming that in your setup it's the router the device connecting to some VPN server and sharing the VPN traffic with any device behind, please consider that the DNS settings of each device "take precedence". If the device is configured to query Norton Connect Safe DNS, the DNS queries from that device will be encrypted and tunneled by the router (together with all the traffic from that device) and reach the Norton DNS from our VPN servers. Norton DNS will see queries coming from the exit-IP address of our VPN servers. Kind regards

@ctss36pwwon Stating that the claim you made toward M247 is not a claim toward M247 does not improve things much. It shows that you wrote without any clue or proof of what you wrote. That's a very different thing, and let's get that straight, because once again you seem to be writing without any evidence or even a clue as to what you're writing, and jumping to assumptions and conclusions that are patently false or impossible. The event you mischievously suggest as potentially possible in our infrastructure would only be actually possible if: we had any employee with access to the customers' database the customer entered personal information in spite of the fact that AirVPN does not require it Point 1 is not met because AirVPN does not have any employee with access to the database (please read the privacy notice and terms). Furthermore, if the user or customer follows the recommendations, the database contains no personal data at all. That's very interesting and shows how better and different AirVPN is, please feel free to provide a link if possible. We found an article on The Register: https://www.theregister.com/2020/07/17/ufo_vpn_database/ In this article the leak allegedly comes from Kind regards

Hello! Yes, it is definitely possible. We will think about it. To the best of our knowledge M247 does not collect information about our customers and this practice, when involving personal data, without explicit consent would be a criminal offense in most jurisdictions M247 operates in. We have contractual agreements which do not allow M247 to do it, but please substantiate your claim now. On one hand we are interested in checking thoroughly your claim, on the other hand we host these forums for the community so we would like to put in place a little protection against any retaliation for libel or defamation, not to mention the right of reply to a company (whose customers we have been for years) especially in case of allegations of criminal offenses as well as statements damaging to reputation. We expect your expeditious reply (or corrections if necessary). Kind regards

Hello! No, you did not understand correctly at all.. we have no power or authority to conduct investigations. Investigations can be carried out by the relevant authorities using the proper procedures, and what we can do is to cooperate with the relevant authorities and only in accordance with the orders of the competent courts. We can't see how infringing privacy (which is a fundamental right), net neutrality and enforcing censorship can help the good guys and/or support crime prevention. We challenge you to publish a proper impact assessment and/or research which shows how the "good guys" are protected by censorship, blocks and general violations of privacy and net neutrality. On the contrary, reports and studies on blanket and indiscriminate privacy violations by various bodies and police forces around the world show the opposite, i.e. that data retention is ineffective in fighting serious crime and at the same time is incompatible with fundamental rights, in particular (as pointed out in 2019 by the EU Council too in official document) the rights to privacy, protection of personal data, non-discrimination and presumption of innocence. Indeed, such considerations led the Court of Justice of the European Union to strike down the Data Retention Directive with retroactive effect, and also to prohibit the EU Member State from enforcing a blanket data retention obligation on Internet Service Providers. The Court of Justice declares the Data Retention Directive to be invalid https://curia.europa.eu/jcms/upload/docs/application/pdf/2014-04/cp140054en.pdf The Members States may not impose a general obligation to retain data on providers of electronic communications services https://curia.europa.eu/jcms/upload/docs/application/pdf/2016-12/cp160145en.pdf The Court of Justice confirms that EU law precludes national legislation requiring a provider of electronic communications services to carry out the general and indiscriminate transmission or retention of traffic data and location data for the purpose of combating crime in general or of safeguarding national security https://curia.europa.eu/jcms/upload/docs/application/pdf/2020-10/cp200123en.pdf As for the protection provided by a layer of anonymity, which is an additional and specific method of enhancing privacy, both the United Nations Special Rapporteur and the United States Supreme Court have recognised it as one of the essential tools for exercising freedom of expression. You can find the links on the same AirVPN mission page you mentioned. In 14 years no AirVPN user has ever had his/her identity compromised due to AirVPN behavior or technical failure but of course any server can be wiretapped without AirVPN knowledge, legally or illegally. In order to defeat adversaries who have the power to eavesdrop on servers through black boxes (external to the server: these boxes can't see the traffic content of course, but they can correlate incoming packets to outgoing packets, which is in some cases a relevant information), we have written repeatedly, please check here: https://airvpn.org/forums/topic/54-using-airvpn-over-tor/?do=findComment&comment=1745 Kind regards

Hello! It is not possible to force Eddie to block specific apps traffic. It is possible to configure Eddie to have specific apps traffic inside or outside the VPN tunnel (traffic splitting on an application basis). If it is not possible to kill or uninstall the apps which you want to block, you could consider removing network access permission, through Android settings, from those apps which must be blocked (Android 10 or higher version required). However, please consider that this is a setting which has been eradicated from Android by some Android device manufacturers (presumably to aid and abet profiling and data harvesting). Quick guide: https://www.digitalcitizen.life/how-block-internet-access-specific-apps-android/ Kind regards

Hello! Please let us and the community know in case Plex support or community find a solution to this problem, thanks in advance! The OP had his problem suddenly solved without an explanation. Kind regards

Hello! We're very glad to know it! Alas, it is still inexplicable that previously it worked only for a limited time or it did not work at all, and now it works reliably. It could be something to do with how Plex picks the preferred network interface, who knows, but from lsof it was clear that it listens on all interfaces. Maybe their support team can shed some light on this strange incident. Kind regards P.S. The new lsof output is consistent with the previous one, no changes.

@dalesd Hello! Please see here, it should solve the problem you reported: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/?do=findComment&comment=229914 sudo apt install mono-runtime-common Please follow the above linked thread when you have time and feel free to post any further bug you find. @user972512 reported that Eddie 2.24.1 runs fine in Pop!_OS 22.04 LTS. We will be glad to know from you as well. Kind regards

Hello! The main differences between today's OVPN files and those of a few years ago: RSA key size is 4096 bit and not 2048 bit default generated profile is compatible with 2.5, 3 and 2.6 without DCO default TLS mode is tls-crypt and not tls-auth About points 2 and 3, you may force the CG to generate files for different OpenVPN versions: enable "Advanced" mode select the proper OpenVPN version, according to the one you run, on the "OpenVPN profile" combo box consider that you may select entry-IP address 1 (in place of 3) if your OpenVPN version does not support tls-crypt If the problem is related to the key size (unlikely, but we remember a similar problem some years ago on a different system, which was promptly fixed) you will need to contact the customer service. Kind regards

@matteoar1 Hello! We're very sorry, we have nothing else to suggest you. Please consider to contact Plex support and community and provide them with all the information you gave us and include Plex log which can contain some precious information. Kind regards

@matteoar1 Hello! Plex ignores your setting (port 63162 does not appear anywhere). From the documentation, we can infer that the "public port" is only used to announce it through Plex centralized system to clients to facilitate connections, authentication and other purposes, and then it is required that some Plex upstream (the router or system packet mangling tool) re-directs incoming packets to port 32400. Try to re-map port 63162 to your port 32400. If Plex announces to clients public port 63162, clients will contact AirVPN server IP address on port 63162 and the server will forward the packets to your Mac utun interface port 32400. Since Plex listens to port 32400 of all interfaces in IPv4 and IPv6: Plex\x20M 728 matteo 18u IPv6 0x5e8f1037afa692f5 0t0 TCP *:32400 (LISTEN) (about why lsof in BSD and Linux shows an IPv4 and IPv6 socket only as IPv6 see here) then your Plex should become reachable. In order to do so just add "32400" to the "Local" field of your remote port 63162, in your AirVPN account port panel. Kind regards

Please open a new thread, this is outdated and caused by Windows and the TAP adapter driver, not Eddie. Specifically, the problem was partially reproducible with old Eddie version using TAP adapter driver and interface instead of the Wintun driver. If you find this problem with Windows 10 or 11 and Wintun driver chances are that it's a different issue, therefore worth of a new thread. If the problem occurs when you run Eddie 2.24 please feel free to add it on the following thread: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ Kind regards

Hello! While the system is connected to the VPN and Plex is running please open a terminal and enter the following command: sudo lsof -i -n -P | grep -i plex Then copy and paste in your next message the whole output. The method suggests enabling IP forwarding and redirecting all packets destined for Plex to the physical network interface port 32400, as if Plex were a very peculiar server unable to listen on the VPN interface. If that's the case yes, you will need that, but we refuse to think that Plex is so junky with this basic feature. Furthermore the method uses pf for packet mangling and therefore it may interfere with Network Lock, which uses pf too. According to other customers (but please note that we do not use Plex) this method is not applied in recent Plex releases and everything works as it should. Kind regards

@matteoar1 Hello! At least you now know that your VPN and system settings are correct and that the VPN remote inbound port forwarding system works properly. We would like to see, while the system is connected to the VPN and Plex is running, which interface(s):port Plex listens to. How to print such info varies from system to system: can you tell us your Operating System name and version? Kind regards

@matteoar1 Hello! We get a "connection refused" (error 111) when a packet is sent to your VPN client port 63162. The packet reaches your node and the connection is actively reset. It's possible that a firewall rejects the packet (instead of silently dropping it) or that nothing listens to port 63162 and the system is configured to reset any attempted connection when the destination port doesn't exist. This fact seems to confirm that the problem is with Plex. Unfortunately we can't see a reason, with the current information, to explain how it's possible that Plex works fine for some time and then stops working (maybe some firewall rule which is enforced with some delay? but this sounds like a wild speculation...). Can you please run anything else listening to VPN interface port 63162, while the system is connected to the VPN, and check what happens? Kind regards

@v0e#nuy Hello! When Bluetit connection mode is set to country, Bluetit calls on domain names to get the destination server IP address (this feature is being completely rewritten and in the next versions domain names will not be used anymore). When a domain name can't be resolved the connection attempt unavoidably fails. In your situation the name resolution is impossible as the system DNS seems unreachable, and actually the DNS server address is private; it is perhaps a spurious remnant from some previous session: You can restore proper DNS settings and/or consider not relying on domain names by creating a white list of your favourite servers in Japan. When a white list of servers is created and the connection mode is set to quick (e.g. airconnectatboot quick in the run control file), Bluetit will select the best rated server in the white list. Example for bluetit.rc: airconnectatboot quick airwhiteserverlist Ainalrami,Albaldah,Bharani,Biham,Fleed,Iskandar,Okab,Taphao Kind regards

@Jimmyboy52 Hello! Apparently Eddie does not follow your settings (you ordered a connection in TCP and Eddie keeps trying in UDP) therefore we suspect that the configuration file is corrupt. Please try the following procedure: make sure that Eddie is not running delete the file C:\Users\Joey\AppData\Local\Eddie\default.profile: from a command prompt enter the command del C:\Users\Joey\AppData\Local\Eddie\default.profile re-start Eddie and test again connections both in UDP and TCP Also, please test WireGuard, no matter whether the problem got resolved or not: from Eddie's main window please select "Preferences" > "Protocols" uncheck "Automatic" select any line with WireGuard, for example WireGuard port 51820. 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 Kind regards

@OhioStateHack Hello! Apparently either UDP or OpenVPN is/are blocked: Please check any packet filtering tool both on your router and system and make sure they do not block UDP. Also test a connection over WireGuard. WireGuard works in UDP too so you can have a first discernment. In order to switch to WireGuard: from Eddie's main window please select "Preferences" > "Protocols" uncheck "Automatic" select any line with WireGuard, for example WireGuard port 51820. 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. Kind regards

@BettyIsBoop @mnzx and anyone with the error "System.TypeInitializationException" Confirmed, hopefully this will be fixed in the next release. As a workaround for now, please install mono-runtime-common: sudo apt install mono-runtime-common @svenmaninov : Hi, it's expected. There shouldn't be any Mono dependency theoretically as it's bundled now. However, there is an issue that is being investigated.

Confirmed, will be fixed in 2.24.2.