Staff

@after_lunch Hello! Kaspersky tools blocked AirVPN, Nord, Cisco and other VPN various times in the past, since when Kaspersky started pushing for their own VPN (just a coincidence...). If you can't afford to test with Kaspersky tools completely eradicated form your system (disabling all the modules may not be sufficient) follow this guide and check whether the problems you experience get resolved or not: https://windowsreport.com/vpn-blocked-kaspersky/#1 Kind regards

Hello! For the readers, we paste the reply by the support team to your ticket: ==== Hello and thank you for your choice! We report the physical location of the server which in this case is Atlanta. [....] we assume that the provider claims the truth and we also perform some network verification. [Try] mtr 64.42.179.58 you will see in the last hops: core.atl.dedicated.com which is inside a datacenter in Atlanta. http://atldedicated.net/ Note that the the IP address belongs to a company located in Vancouver (WA), maybe you were confused by that. About the round trip time, you need to consider that physical distance is not necessarily related with direct proportionality to network distance, although of course the physical distance plays an important role. Consider the common case for which a residential ISP serving you must reach the node of someone living just in front of your road, but connected to another ISP, and that those ISPs interconnect via a peering agreement with a tier 1 transit provider whose nearest node is 100 Km away from you. To reach the house node which is a few meters away from your house, your packets will enter your ISP network and will be routed according to the Internet "best effort" routing. Sooner or later they will get out of your ISP network, reach the tier 1 provider hop 100 Km away, and then start their travel back to the house in front of you. So, in this particular case, packets will have traveled a minimum of 200 Km (and probably more) to reach a node which is a few meters away from yours. Use mtr tool to verify routes, round trip times etc., it will also help you understand the problems of routing, peering and interconnections (the Internet is (also) a huge set of networks which try to reach each other "in some way"). A nice article is available in Wikipedia https://en.wikipedia.org/wiki/Peering === Kind regards

@after_lunch Hello! Not as useful as we hoped unfortunately. We strongly suspect that there's still something blocking HTTP packets to port 80 or maybe in general packets coming from certain applications: note how even the preliminary HTTP test fails. This test is performed regardless of your account login. Together with the previously mentioned blocks of various web sites, we think that it's worth that you re-check packet filtering rules as well as the configuration of the anti-malware tool that's still installed. Try also to reset the TCP/IP stack... probably it will not resolve the problem, but you never know. Step by step instructions: https://wethegeek.com/reset-tcp-ip-stack-on-windows/ Kind regards

@after_lunch Hello! Before trying the system replacement you mention, please send us a system report, where Eddie might have logged everything happening while it tries to contact the bootstrap servers. From the main window click "Logs" tab, click the LIFE BELT icon, click the "Copy" icon (or send the report to our web sites) and paste either the whole report or the link to the report into your next message (or open a ticket to keep the system report private),. Also test what happens if you enter http://airvpn.org when Eddie asks for an alternative bootstrap server. Note that it's http and not https (then Eddie encrypts by itself the underlying HTTP data flow). If it fails too, try also .info in place of .org. Kind regards

Hello! Since the other machines work fine we can rule out any block by your ISP or by your own network (router etc.). Please check whether any of the tools you mentioned, if still active, may block packets by cURL or OpenVPN or Eddie, or maybe the IP addresses of our bootstrap servers. Since you notice overblocking toward other legitimate destinations, this is an option to be seriously considered. A quick discernment test can be performed by simply disabling entirely every and each tool and check whether the problem gets resolved. Also remember that multiple antimalware and packet filtering tools running at the same time can cause unpredictable conflicts and behavior. If the above doesn't solve the issue, try to re-start Eddie from scratch: delete (or rename) the configuration file C:\Users\xxxx\AppData\Local\Eddie\default.profile (do it while Eddie is NOT running). Then re-start Eddie (you will need to re-enter your AirVPN account credentials). In the event that the configuration file is corrupt, this procedure should resolve the issue. Kind regards

@blackSP Hello! WireGuard lacks a lot of basic features and uses the profile name for the virtual network interface name itself. An interface name characters limit is 15. Hence the error "interface name is longer than 15 characters". Just rename the profile into a name not longer than 15 characters. Alternatively, consider to run Eddie if it's compatible with your distribution. By running Eddie you can connect via WireGuard and you don't need profiles anymore. Kind regards

Hello, as far as it pertains to gaming with prizes in money, even residents in various USA states (such as Arizona, Hawaii, Mississippi, Nevada, South Dakota) are forbidden to use the platform, it's stated here: https://www.checkmategaming.com/faq#region-restrictions-70 In general the platform does not operate in areas where its activity is illegal and/or where it does not have (yet?) mandatory licenses for gambling etc. (it may be questionable whether it's gambling or not, anyway some legal framework tends to frame this activity as such), and also it avoids to operate in "a jurisdiction where the awarding of a prize based on the participant’s results in the competition is prohibited, illegal, or restricted". Therefore it tries to block anything from those areas, to stay on the safe side, and anything not coming from an IP address assigned to a residential ISP. Free games with no fees and no monetary prizes are open to everyone in general. Kind regards

Hello! Currently the resolution of your *.airdns.org domain name is correct, it resolves into the exit-IP address of the VPN server you're currently connected to. We have checked the propagation on various public DNS servers on the Internet and they are all fine, maybe the one you query did not update? Consider that TTL is 1 hour, so on average you can expect 30 minutes updates. Kind regards

Hello! Sure, please see here: Happy Friday! Kind regards

@govegan3 Hello! After you have renewed client certificate/key, please log your account out and in again from Eddie main window (this is strictly necessary whenever you create or renew certificates and keys). Kind regards

@Rebelyouth Hello! We're not sure here, but one of the problems we see on your message might be a direct consequence of the infamous "translation" problem between iptables and nftables in a system based on nftables where rules are applied through iptables-nftables. In a few words, iptables-save-legacy generates a file which is wrong (some rules are translated with syntax errors). When iptables-save-restore reads the file, it detects the syntax error. Try to force Hummingbird to use nftables for the Network Lock feature with option --network-lock nftables (note: utility nft must be available to Hummingbird) Kind regards

Hello! We are glad to inform you that we support PeerTube by Framasoft as mécène. PeerTube is a tool for sharing online videos developed by Framasoft, a french non-profit, which allows you to create your own video platform, in complete independence. PeerTube also enables platforms to be connected to each other, creating a big network of autonomous and interconnected platforms. Moreover, PeerTube does not depend on any advertising and does not track users. https://joinpeertube.org/ Check out our mission page: https://airvpn.org/mission Kind regards and datalove AirVPN Staff

Hello! We have seen the Vilfo hardware and probably (if your network doesn't restrict UDP) you will get better performance with WireGuard (in Vilfo's documentation they say that WireGuard throughput in Vilfo routers is 2x higher than OpenVPN), so it's worth a test even before OpenVPN. Our Configuration Generator will generate any WireGuard profile you need (from your account "Client Area" click "Config Generator"). Kind regards

Hello! Eddie modifies the rules only when Network Lock is enabled. If you enable Network Lock in Eddie and you see that the problem persists, or in any case if you don't want to enable Network Lock, then you can consider to disable Shorewall before you run Eddie and re-launch it after you have finished working with Eddie, or modify Shorewall rules in a way that they do not enforce the mentioned blocks on packets to and from the tun interface. Kind regards

Hello! Bluetit developer's manual https://gitlab.com/AirVPN/AirVPN-Suite/-/blob/master/docs/Bluetit-Developers-Reference-Manual.pdf shows how to integrate any software with AirVPN infrastructure, including dialogue with the bootstrap servers. If the developer may use directly Bluetit's set of classes the job gets easy since all the classes and tools of the AirVPN–SUITE have been designed and developed by using standard C++ 11 classes and convention. For the developer who can't or doesn't want to do it, the integration can be ported from the original classes and by reading the documentation. It saves a lot of time because an API or other interaction with the web exposed AirVPN tools for end users are no more necessary, as they were, on the contrary, in the past, for example when Qomui was developed, due to the lack of documentation at that time. After that, the actual VPN connections can be handled as usual either by a WireGuard or OpenVPN compatible software (or through other Bluetit classes of course). Kind regards

@squidf Hello! Yes, it was the firewall, example: janv. 11 17:01:20 cbct-desk kernel: OUTPUT REJECT IN= OUT=tun0 SRC=10.10.182.75 DST=10.10.182.1 LEN=57 TOS=0x00 PREC=0x00 TTL=64 ID=20318 DF PROTO=UDP SPT=56553 DPT=53 LEN=37 It was blocking everything on the tun interface to the VPN gateway IP address. Maybe when Eddie was working fine with WireGuard, the firewall did not block the specific WireGuard subnet? By the way, we're glad to know the "culprit" causing the problem has been found. Kind regards

@squidf Hello! OK, at least we know that the route check failure was not a "false positive". Anything else which might interfere with OpenVPN while working in UDP, in your system? Does OpenVPN work fine in TCP? Please try specifically entry-IP address 3 to port 443, in TCP. Kind regards

@squidf Hello, OpenVPN reports a successful connection but then the route check fails. Since WireGuard connection is fine we can rule out any UDP related problem. Please verify whether the route check failure is a false positive by disabling both route check and DNS check in Eddie's "Preferences" > "Advanced" and "DNS" windows, respectively. When you disable them both, the connection should be claimed as successful; at that point test the tunnel and check whether you can normally access the Internet or not. Kind regards

@squidf Ok, we are replying on the other thread for that's a different problem. Kind regards

@squidf Hello! Yes, you need to change a setting. From Eddie's main window select "Preferences" > "Advanced". Uncheck "Use Hummingbird if available" and click "Save". Kind regards

@squidf Hello! Please use OpenVPN 2.x in the meantime when you run Eddie beta version. We are working to implement missing directives in our OpenVPN3-AirVPN library fork as we did in the past.: we have decided that again we can't wait for the implementation in the mainline. Specifically, the directives which are causing a critical error are "ping-exit" and "pull-filter" in your case. However, "pull-filter" is extremely useful in a wide range of cases, so a complete implementation is necessary from scratch (currently the code from the mainline we brought in ignores some pull-filter syntax and throws errors in other cases). Kind regards

Hello! Please see our previous reply in this thread and also the following one, where we explain more thoroughly our point of view and some facts: https://airvpn.org/forums/topic/50724-two-new-1-gbits-servers-available-us/?do=findComment&comment=216468 Just a brief addition: your above quoted sentence imply that protecting privacy in an agnostic network means supporting net abusers, which is an inadmissible and shameful idea that we strongly reject. This concept is one of the "moral" or "ethical" justifications to pervasive surveillance in virtually all countries controlled by human rights hostile regimes, and in a few "Western" countries too: since someone somewhere someday might commit a crime via the Internet, let's enforce blanket data retention and pervasive packet inspection for everyone, so Internet will be a "safe place" for the "law abiding, conforming" citizen. Your consideration has been and is the founding argument for power groups having the hidden agenda to expunge the right to privacy from the list of fundamental rights. Consider that one of the strictly necessary conditions for any dictatorship to survive is the effective suppression of the right to privacy. Kind regards

Hello! The blocks you mention have nothing to do at all with torrenting or copyright notices. If they were, then yes, it would be trivial indeed to offer special servers with the aims you describe as exceptions to our mission. The main three factors causing black listing are spam e-mails, attacks to web servers via HTTP POST etc., and false positives (we include here the widespread blocks against entire IP ranges when only one IP address in that range is flagged). The first problem can be strongly mitigated, if not solved, by blocking outbound ports 465 and 587, the second problem can be resolved by blocking outbound ports 80 and 443, therefore making the server unusable to reach web sites and send out e-mail. It's easy to guess that this type of service wouldn't be used by anybody as without e-mail and the World Wide Web nobody would feel on the Internet for real, but we could add servers with this limitation for free to our customers, as a free and optional bonus outside the service (in order not to cause a contractual breach) just to test how many would use them and for which purposes (maybe something interesting will come out). Another form of mitigation would be deep packet inspection to discard any packet with malformed queries and potentially malicious purposes according to pre-defined algorithms, data set etc. (needless to say it would be a contractual breach even on a bonus server, so it's not realistic to think of it). Please note that, according to latest reports, about 1 out of 12 Windows machine in the world is infected, so in various (many?) cases the activity causing IP address black-listing is performed without the knowledge of the computer owner. Another approach, which is actually more realistic and followed by most providers, is monitoring the customer's traffic, identify the customer at least via IP address at each connection, block immediately the account when something suspicious goes on and report the customer's IP address to competent authorities (this last step becomes legally mandatory on most countries when a provider monitors the traffic and comes to know that a potential infringement has been committed).. Then it's all up to the competent authorities, end of the story for the provider. This type of service is surely possible (and in reality it has been followed in secret by several VPNs in the recent years, together with personal data harvesting) but (leaving aside our contractual breach this would cause) why then would you need a VPN? Since the traffic would be monitored anyway, most customers might just decide to let their ISP monitor their traffic, rather than shifting this "duty" to some VPN operating company or entity. Then there's another type of block (block enforced against anything that does not come from IP addresses assigned to residential ISPs - for example BBC follows a similar policy), but that's outside the scope of your complaint, we guess, since to bypass those blocks renting IP addresses assigned to residential ISPs become necessary. This is not impossible, but only in some specific countries, and we will be working on it. Kind regards

Hello! Problem resolved server-side, please try again! Kind regards

@zsam288 Hello! It seems a bug of the WebView when passing the name of the file to be downloaded to the system's DownloadManager used by Downloader app. It looks resolved in our various Fire* devices. Can you tell us the exact FireOS version your device is running? Let's make a comparison. @GreyGold In nVidia Shield TV, the problem persists even with the most up to date system. Shield TV users may consider to save time by downloading the file with any browser with a built-in downloader. For example TV Bro is a light-weight, open source browser for Android TV featuring a built-in download manager, so it doesn't rely on system's DownloadManager. It has been tested successfully to download various apk on our nVidisa Shield TV. Then the apk can be installed with X-plore. nVidia Shield TV users have of course a variety of additional options: side loading from an USB stick where a computer has stored the Eddie APK, or get the APK directly from the local network. We have opened an investigation aimed at providing the most practical solutions for FireOS and Android TV users. EDIT: resolved. We can circumvent the bad behavior by WebView in some Android TV devices by setting a different Content-Type header with a dedicated MIME type for APK. Kind regards