Staff

@XV-8774 Hello! We have detected the same problem on a few Samsung devices running Android 10 and 11. Although the cause of the lack of "traffic-through" is currently unknown, (and we don't know why only certain Samsung devices are affected) we verified that Eddie 2.5 alpha 3 resolves the problem. Please see here to download the apk (you need to uninstall Eddie 2.4 first, and then side-load Eddie 2.5 alpha 3): https://airvpn.org/forums/topic/49705-eddie-android-edition-25-alpha-is-available/ Eddie 2.5 beta 1 public availability is imminent, currently we are testing it internally. Please let us know whether Eddie 2.5 resolves the problem for you too. Kind regards

Hello! To help us troubleshooting DNS block list issues with WireGuard, please activate at your convenience the DNS List "Air ADV", and try from terminal (Linux and macOS) # dig ad-delivery.net @10.128.0.1 or in Windows # nslookup ad-delivery.net 10.128.0.1 Then publish the output. Kind regards

Indeed! Express is a filthy enemy of AirVPN mission and a threat to its own customers. https://english.almayadeen.net/articles/analysis/exclusive:-expressvpn-insider-tells-all-on-companys-israelua https://twitter.com/Snowden/status/1438291654239215619 Kind regards

Hello! The issue is unexpected and not deliberate, we will investigate. In the meantime, please do not attach files, just copy and paste text into your message. In particular, do not send screenshots which in many cases are useless and cause only a waste of time for obvious reasons. Should attaching screenshots be absolutely unavoidable, attach them to an e-mail to support@airvpn.org Kind regards

Thank you, we're very glad to know it. We have not changed anything on our side so the cause of the problem remains unknown. If it wasn't on your side, the problem might re-appear. Open a ticket if it does to let us investigate more properly. Kind regards

@autone Hello! Can you confirm that remote inbound port forwarding works as expected even in WireGuard subnets? Kind regards

@C205Veltro Hello! Probably it's not a connectivity issue because you could connect to the VPN, but a DNS problem. Please check your DNS settings and make sure that publicly available DNS server addresses are set. Good choices we recommend are OpenNIC https://www.opennic.org and Quad 9 (9.9.9.9). Instructions if necessary to change DNS in macOS: https://serverguy.com/kb/change-dns-server-settings-mac-os/ Kind regards

@Zebby Hello! The forum for the community is moderated and moderators can warn an account with points for posts infringing community forum policy. Kind regards

Hello! We're glad to inform you that Eddie 2.5 Alpha 3 is now available. It includes the ability to start and connect during bootstrap (if Master Password is disabled) according to a priority list which includes automatic choice, your defined country and your defined server, on top of the usual ability to start and connect at bootstrap via a profile. The feature is available in Android versions from 5.1 to 12, and in Android TV versions from 5.1 to 9. The feature is lost in Android TV 10 and 11 due to unavailable operations on Android systems lacking "Always on VPN" option. Eddie 2.5 Alpha 3 is now linked against OpenSSL 1.1.1l and also features several bug fixes, including bugs reported in this thread. The first post has been updated to show the correct URL of the latest apk and its checksum. Please keep testing and report malfunctions and bugs, thank you in advance! Kind regards

@spinmaster Hello! It's a bug in the Configuration Generator coming from the times when the name earth3.airvpn.org existed. Now it doesn't exist anymore. Please modify it into earth3.vpn.airdns.org or earth3.all.vpn.airdns.org. The first name resolves into the entry-IP address 3 of the "best" Earth server, the latter into entry-IP addresses 3 of all VPN servers. We will fix the bug, in the meantime you can simply edit with any text editor your ovpn file. Thank you for having found and pointed the bug out. Kind regards

@monstrocity Hello! That's irrelevant for the problem @autone mentioned. Regardless of the tunnel transport layerl, inbound packet forwarding must work both with TCP and UDP, and both with WireGuard and OpenVPN. The fact that you can't use WireGuard is related to a possible UDP block but has nothing to do with the packet forwarding problem inside the tunnel experienced by @autone with WireGuard only. We invite @autone to open a ticket if the problem persists. In this way we can check in real time what happens with packet forwarding. Kind regards

@msbntt @OpenSourcerer Hello! Investigation on this case and a few similar ones will start soon. It's a rare issue as far as we can see and it's confirmed. @msbntt Please try now. If you still can't connect we will compensate the fact that you can't access the service until the problem is resolved. If you have urgent need to connect and still you can't now, please open a ticket and we will give you a disposable account for the time being necessary to resolve the bug. Kind regards

@monstrocity Hello! Watch out, the fact that WireGuard's transport layer is UDP does not prevent (as it happens with OpenVPN, on the other hand) both TCP and UDP wrapping, of course. TCP and UDP packet forwarding must work both with WireGuard and OpenVPN in the same way Please feel free to open a ticket if they don't. Kind regards

@CXX Thank you very much! Kind regards

Hello! Have you added the generated magnet link to your torrent software? Kind regards

@jelegend Hello! About remote port forwarding you though right. Your ISP can't interfere because the data stream is still encrypted in the ISP devices, up to your own node. Strange question... It's the software that must receive the packets, in other words the software you run in your system which must be reachable from the Internet, the only software you forwarded an inbound port for. Kind regards

@Agrock Hello! DNS over TLS is supported since several months ago. It is almost useless since plain DNS queries to our VPN DNS, and their replies, are anyway encrypted and authenticated because they stay in the tunnel, but you might need DoT for peculiar configurations. Check the usual specs page for more details: https://airvpn.org/specs You can define anyway custom per "device" (i.e. client certificate/key pair) block lists, personalized exceptions and blocks, regardless of the fact you use DoT or not. Kind regards

Hello @jelegend "Connection refused" usually implies that the packets reached your node and were actively refused. A firewall, or maybe the final service, might have dropped them. If you had had the packets lost between the server and you, or not forwarded at all, you would have seen "Connection timeout" error. Kind regards

@jamesmac77758 Hello! It is possible, but Network Lock rules would have blocked traffic leaks by qBittorrent even in this case. Do the allegedly shared content and the listening port match? If so, it should be authentic. On https://ipleak.net you find a torrent dedicated test, "Torrent address detection", make sure you perform it. Also, check the firewall rules (what is your Operating System?) while Network Lock is enabled and your system is operating in the VPN. Send them to us if in doubt. Kind regards

@jamesmac77758 Hello! So, the first time you had Network Lock off and therefore a letter might be expected in certain countries (no matter whether you shared free or copyrighted content). About the second case, keep in mind that Network Lock is based on your default system firewall. If that firewall doesn't work, or its rules are modified by some process with administrator privileges, the whole concept fails, and you might have even more serious problems than a letter from your ISP: if administrative actions were performed without your knowledge, it would mean that your system is compromised. Also, you never know, check the letter and make sure that it's not a bogus letter. Ascertain its authenticity, if you haven't already done so. In particular, verify whether the complainant really tried to connect to your torrent client (check the port is really the one you employ, check the datestamp of presumed infringement and so on). Since recently, smaller copyright trolls did not validate with an active connection the IP address harvested from trackers (too expensive), and therefore it was so easy to engulf trackers with announcements containing fake IP addresses, just to prank people you don't like for example, or any other joke. Kind regards

Hello! What happens if you switch to the wintun driver? From Eddie's main window select "Preferences" > "Advanced", tick "Use wintun driver", click "Save", and re-start Eddie. The wintun driver is more modern than the TAP driver and in various cases it is able to resolve several TAP driver issues as well as providing higher performance. Should it resolve your issue, you can probably forget the TAP driver. Kind regards

Hello! The deal will end in a few hours, around 2021-11-02 23:59 UTC. Kind regards

I too am confused as to where and why the user's IP address is stored permantly. I understand that while connected to Air servers, the user IP address will be known. Why is this not purged from the Air after disconnect or server change? Hello! Keeping permanently the client IP address is a WireGuard feature, see also https://airvpn.org/faq/wireguard That's why we force a purge of the real IP address. "In AirVPN servers, if no handshake has occurred within 180 seconds, the peer is removed and reapplied. Doing so removes the real IP address from server memory.". Note that 180 seconds are not 10 minutes. If that's not acceptable you must not use WireGuard, keep using OpenVPN, which will get rid of the client IP address by itself (no need of active deletion). About the VPN IP address, which is another privacy problem, we invite to read the above linked FAQ answer. Kind regards

Hello! We don't think they don't understand because the error message seems clear. You're asking to delete the reason of existence of airvpn.dev. Explanation can be found in the specs page: "airvpn.dev web server configuration provides a hardened security configuration to get a rating aiming to 100% (Qualys SSL Labs, CryptCheck) which sacrifices compatibility with older systems and browsers (example: Android 6 will not connect)." Kind regards

Hello! This is not an issue, so there's nothing to be sorted out for any user. Various apple.com subdomains, such as advertising.apple.com and banners.itunes.apple.com, are blocked by the "Ads & Trackers block list", which is a merge of public lists not compiled by us. Please remember that we do not add blocks by ourselves whatsoever. The blocks do not seem to affect Apple Store, though, as confirmed by other users at the moment. Please be aware, however, that Apple may block access to Apple Store from VPN and Tor. This happened already in the past, even to ProtonVPN, so we can't rule out that some of our servers are already blocked by the Apple Store. If you don't think that Apple advertising is advertising or anyway the list disturbs you, you should not enable this anti-ads list, or you can add exceptions. When you click "LIst", all the blocked domains are shown. Quickly search for "apple.com" and you will see immediately which subdomains are blocked. You can also propose some other block list against advertising which does not block advertising by Apple, if you can find one. Kind regards