Staff

@noonereturnsthesame Hello! A possible problem we can infer from the piece of log you kindly published is a conflict with Proton. Since we see that a Proton interface is up, it's possible that you're trying (even unintentionally) to use both AirVPN and ProtonVPN at the same time. This is possible but only with special configuration (multiple routing tables and virtual interfaces, or more trivially with virtualization) and in general it will cause conflicts. Can you please make sure that, when you are going to use AirVPN, ProtonVPN related programs and services have been already stopped? If you ascertain the above and the problem persists, please generate and send a full system report, please see here to do it: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/ Kind regards

Hello! You didn't need that, you could have used a configuration file generated by the Configuration Generator, provided that you could access at least one of the various AirVPN web sites. For those persons who can't access any of the AirVPN mirrors we have an easy workaround solution that is not published because it must be tailored almost individually, please contact the support team. Technically, the reason is that the AirVPN bootstrap servers and/or the protocol used to communicate with the bootstrap servers is/are blocked by some Russian ISPs as reported in the dedicated thread on blocks in Russia. Yes, definitely, and this is planned. It is being implemented and you will see it in an imminent Eddie 4 version, maybe already in beta 2 or RC 1. Eddie will read locally the user data when bootstrap servers are unreachable. So you will need to access a VPN server only one time through a configuration file. Once in the VPN, the block toward the bootstrap servers are bypassed and Eddie will download and store locally the file it needs for future usage. It will remain stored as long as you don't force its deletion. Side (obvious) note: the mentioned user file is related only to the user you logged in, so it will not be valid when you try to log a different user in to the service Not true. Eddie Android edition can be used as a generic client so anything a generic client can do, Eddie can do too. In this case generate a proper configuration file and have Eddie connect by reading that configuration file. Kind regards

Hello! It could be sufficient and currently it is indeed sufficient from Russia and China, where you bypass blocks with the backward compatible H parameters. The H parameters could become in the future an additional weapon against evolving blocking techniques. Kind regards

Hello! Correct, the I parameters are meant for Custom Protocol Signature (CPS). When you connect to a WireGuard based server you must preserve backward compatibility. Jc, Jmin, Jmax, I1-I5 parameters remain free (within the mentioned constraints), while you must set: S1 = 0 S2 = 0 H1 = 1 H2 = 2 H3 = 3 H4 = 4 Various persons (as well as our original post) report also that you can mix H parameters, but they must be different from each other, and each H must be included between 1 and 4. Kind regards

Hello! We're glad to inform you that AmneziaWG support has been implemented in Eddie Android edition 4.0.0 beta 1 and it will be progressively implemented in all the other AirVPN software. https://airvpn.org/forums/topic/77633-eddie-android-edition-400-preview-available/ Eddie Android edition public beta testing is going very well and the development team is optimistic about a near future release. This is only partially true. When you use CPS on your side and you connect to a WireGuard based server, demultiplexers will identify the traffic according to the CPS settings (QUIC, DNS...) only initially. They will soon be able to detect the traffic as WireGuard traffic. With DNS mimicking this happens just after the handshake, while with QUIC the inspection tools need much more time. We can confirm the above after several experimental tests we repeatedly performed with deep packet inspection. Anyway QUIC mimicking is effective and actually it can nowadays bypass in about 100% of the cases the blocks in both Russia and China. But we have planned to support Amnezia on the server side too, because the current method is anyway not so strong on the long run. When we have Amnezia on the server side too, no tool is able to ever identify the traffic as WireGuard traffic: it remains indefinitely identified as QUIC. Currently we are still at a testing phase, but the outcome so far is very promising. Stay tuned! Kind regards

Hello! You may be right. According to your user feeling, what is the best selection of server using quick connection mode (i.e. you do not force a white list of any type) between Eddie Desktop, Eddie Android and AirVPN Suite (if you ran two or all of them)? And what is the software that achieves the best selection inside a single forced country (when the country offers multiple servers)? Kind regards

Hello! That's correct, the routing and the firewall rules are not infringed and the queries are not treated differently. However, you may create specific environments where DNS queries are not tunneled even when everything is properly set up and Network Lock is enabled. A typical example is when you force your router address as DNS server of the machine connected to the Internet. Network Lock won't stop the traffic to this router, thus DNS query will go to the router (outside the VPN tunnel, according to the table) and then the router will forward it on to the Internet from its physical network interface with its "real" (ISP assigned) IP address. The system is adhering precisely to what it has been told to do, so it is not a DNS leak, but at the end of the day the outcome is equivalent on the client's point of view. Yes, good solution at a first glance. BIND, dnsmasq, Unbound and PowerDNS offer this feature. Kind regards

Hello! In this case you should use your hosts file, so you bypass DNS directly, no need to expose any detail in AirVPN configuration of course. You would need to disable DHCP to have static addresses for the key devices in your LAN, but we don't know if you may like this limitation. Kind regards

Hello! Thank you first and foremost for this valuable information related to the possibility that a plasmashell crash can cause sending a graceful SIGTERM to children apps etc. This should be confirmed or denied as it is relevant. From the correct and precise info that @Tech Jedi Alex provided, you now know that: Network Lock is a set of firewall rules if Eddie is properly shut down, it restores the previous firewall rules if Eddie is killed ungracefully / crashes the rules remain in place, i.e. Network Lock stays "active" Now, you have an unstable environment which might cause a proper Eddie shut down with a tranquil kill signal, so you need to either revert to a stable environment, or keep even the firewall rules that are restored as blocking rules preventing leaks, so you have a "permanent" lock. Of course, should the environment cause modifications even to the filtering table, then a "permanent" network lock becomes impossible and the only real solution is using a stable environment, which would be the healthiest and safest solution. Seeking these types of protection when the operating environment itself is seriously unstable is not logic unless it's an exercise / proof when the assessed risk in controlled condition is zero (therefore do not use this environment for sensitive activity / sensitive data flow). Kind regards

Hello! Please note that guaranteed bandwidth does not mean guaranteed speed. The weakest hop in the routing between your node and the VPN server determines the maximum performance. Nobody can guarantee anything on the Internet as soon as any interconnection with a not owned network takes place, obviously. In your case of course the poor throughput comes from a cap / bottleneck somewhere else, not in the VPN server itself, according to your description. Kind regards

Hello! You should "re-map" the VPN server remote port 33585 to your local VPN interface port 32400 by filling the "Local" field on your AirVPN account port panel. Kind regards

Hello! It's by Telecomix, a group an AirVPN founder co-operated with! https://en.wikipedia.org/wiki/Telecomix Kind regards

Hello! Yes, keep in mind that Plex always listens to port 32400 of the VPN interface, no matter what. Therefore you should "re-map" the server port 33585 to your local VPN interface port 32400 (directly on your AirVPN account port panel). Note: hot change is supported for remote port only, so when you change local port on your AirVPN account port panel, if you are already connected to the VPN please disconnect and re-connect to apply the change. Kind regards

It's so much easier on our state of the art VT100, but the bosses promised that we could have the brand new VT220 for Christmas if we behave, ROFL.

Hello! It sounds like some Mono related problem, can you check your Mono version in your system (and update it if newer version is available)? Kind regards