Staff

@JBronson Hello! Can you please check your system DNS settings while Bluetit is not running and while it is running? ICMP packets for IP addresses outside the local network are correctly blocked by persistent Network Lock enforced by networklockpersist. An option to consider is that Bluetit fails the connection during the bootstrap. Although Bluetit answers to bluetit-stats with "Bluetit is connected to VPN", it is clearly belied by ifconfig output which does not show any tun interface in your system. Please make sure that VM kernel tun support is available, check Bluetit log and feel free to send it to us: sudo journalctl | grep bluetit Kind regards

Hello! We see remarkable, intermittent packet loss spikes every other hour or so on most Dallas servers. We are investigating. Kind regards

@cannac Hi! country is a directive you can include in bluetit.rc file to tell Bluetit where your node is, while the connection scheme file contains connection lists. The file is read by Bluetit to determine a connection list according to the country your node is in. DEFAULT is the connection list used by Bluetit when it does not know your country and a quick connection is required. Therefore DEFAULT -> US does not block connection to US servers whatsoever, while country xx will prevent connections to country xx (due to the famous "safety rule") when a quick connection is required and no white lists are specified. Check the syntax, there is no "=" symbol in the directive, just separate directives and their arguments with space(s) or tab(s). Kind regards

@cannac It would be the same thing, yes. DEFAULT is not restricted to two entries: you can list more areas (countries, continents, USA states...). Kind regards

Hi, you can, but it should work either way. Kind regards

@cannac In the meantime you can efficiently resolve the problem by editing the connection scheme in /etc/airvpn/connection_priority.txt (as root, with any text editor). Find the line: DEFAULT -> NL,California and change it into (for your specific case): DEFAULT -> US,NL on all devices. Then differentiate the white lists in each device bluetit.rc file according to the previous suggestion (subsets with empty intersection). Kind regards

@cannac Hello! In reality the problems are caused by a much more subtle cause and a bug: Bluetit uses a global connection zone list, when the country is undetermined. When you enter a country with lowercase ISO code, Bluetit does not understand it, and doesn't know where you are. Therefore it consults default connection list, which includes the Netherlands and California. In your white list, you have included at least a California server (Aquila), thus Bluetit finds at least one valid server to connect to. On the contrary, when you entered "country US", Bluetit knew that your node is in the USA: the quick connection mode excluded all the servers in the US (in accordance with the safety rule which prescribes to avoid connections to servers located in the same country your client is too), and again no valid server was found in the white list. The above will be changed in the next release where the white lists will take priority in any case for the quick connection mode, regardless of the fact that Bluetit knows or not the country of your node. Kind regards

@BKK20 Hello! The user running the client (the browser in this case) must always type the remote port when it's not 80 or 443, which are added automatically if missing. Name and port must be separated by a colon. The port is an integral and mandatory part of HTTP URL since when it was defined in 1994, 27 years ago. More in general, an HTTP URL conforms, and has always conformed, to the generic URI syntax, see also: https://en.wikipedia.org/wiki/URL Kind regards

Hello! Your authorization to recurring payments from PayPal to us must be confirmed twice so you should have noticed when you confirmed it. You can cancel the authorization anytime with a few clicks: https://www.paypal.com/li/smarthelp/article/How-do-I-cancel-a-recurring-payment,-subscription,-or-automatic-billing-agreement-I-have-with-a-merchant-FAQ1067 Please open a ticket, if you haven't already done so, and the sales department will refund all the payments you unintentionally delivered in the last 30 days according to the Terms of Service. Kind regards

@Stalinium Thank you. "Renew" is correct and accurate while "Regenerate" is inaccurate if not wrong. See also OpenSourcerer message. That said you all are right, English is not the first language of any member of the AirVPN staff and only one founder has a University doctoral preparation in English language (in scientific English, not in English literature), but he can't read and fix every and each document written by the whole staff. We promise we will do our best to improve. Kind regards

Hello! Maintenance ended successfully. If you experience any issue with Dallas servers please do not hesitate to write here or contact our support team. Kind regards

@Air4141841 Hello! Upgrading OpenVPN implies disconnecting all users on a server; moreover any upgrade must be tested to be sure that it doesn't cause some unexpected problem. Therefore with the new version the operation is performed gradually on a small subset of servers at a time. Imagine what would happen if we disconnected everybody at once: 15000 disconnections with 15000 potential re-connection (TLS handshakes etc.) attempts in a matter of seconds. Even worse, what if some unexpected problem came out with the new version? Upgrading hastily and all at once would bring down the whole AirPVN infrastructure! An exception is when a discovered critical vulnerability requires emergency update. This is not the case with OpenVPN, at the moment. Staying on top of things also means not to upgrade blindly and/or hastily. Kind regards

With all due respect for an old time customer like you, comparing AirVPN with ExpressVPN is an insult we can't accept. ExpressVPN has always been perfectly aware that one of its executives was an American intelligence operative who helped UAE human rights hostile government in cracking operations. We do agree with Edward Snowden when he says that you must not use ExpressVPN. Incidentally, ExpressVPN is now part of a big group that, throughout the past decade, was an adware based business with shady privacy practices. Please check: https://www.vice.com/en/article/3aq9p5/expressvpn-uae-hacking-project-raven-daniel-gericke https://twitter.com/josephfcox/status/1438127822883729412 https://twitter.com/Snowden/status/1438291654239215619 https://www.theregister.com/2021/09/14/expressvpn_bought_kape/ Kind regards

@BKK20 Hello! DNS doesn't provide port numbers and DNS records do not listen to anything. It's some running software which "listens". And it's the client the one which picks the destination port to try. In a browser, if the port number is not specified, normally :80 for HTTP and :443 for HTTPS are added to complete the URL. The client must always specify the port as well, it's a mandatory field in TCP and UDP packets. Separate name and port with a colon. Example: http://somename.org:12345 As an additional option, you can also "re-map" your remotely forwarded port(s) to different port numbers. In this way packets reaching remote VPN server port will be forwarded to your node on another port number. Kind regards

Hello! We inform you that an emergency maintenance due to urgent hardware replacement will be ongoing on 2021-09-18 between 19 and 23 CEST on the Dallas datacenter. The maintenance will impact all of our VPN servers in Dallas: expected downtime is approximately 30 minutes. Kind regards AirVPN Staff

@BKK20 Hello! Not a problem: the listening port of your web server is decided by your web server, according to how you configure it. Domain names have nothing to do with ports. Please check: https://airvpn.org/faq/port_forwarding/ Kind regards

@cannac Hello! We can confirm the problem when "country" has a value (any value, not only US). Please comment out your country US line in bluetit.rc file and you should be fine: Bluetit will pick the "best rated" server between those included in the white list you specified. We will investigate with the developers the issue you reported in the near future, thank you. Kind regards

IMPORTANT CORRECTION TO THE PREVIOUS MESSAGE. If you define a "quick" connection mode at boot, Bluetit will consider and respect white and black list directives included in bluetit.rc during the connection at bootstrap. Therefore, the proposed solution is optimal and does not require Goldcrest: just remember to change connection mode to quick (and do not set it to country), and define white lists according to the conditions written in our previous message (i.e. three empty intersection subsets, one subset per device). Kind regards

@cannac Hello! You have related options in Goldcrest. If the white list must be global and respected by all users, superuser must define it in Bluetit run control file. If the white list can be decided each time by any user inside airvpn group, then superuser must not define it in Bluetit run control file. The related Goldcrest options, which can be specified on the command line only, and not in goldcrest.rc file, are: --air-white-server-list, -G : AirVPN white server list <list> --air-black-server-list, -M : AirVPN black server list <list> Please see also: https://airvpn.org/suite/readme/#controlling-goldcrest-client Kind regards

@cannac Hello! A solution which might meet your needs is partitioning the US Air VPN servers set into three empty intersection subsets, one per device, compiling airwhitserverlist directive with a unique subset in each device, and finally restarting the three connections via Goldcrest on the US country basis. and finally defining the connection mode in bluetit.rc as quick. If the connection mode is not defined as quick Bluetit ignores white and black lists but it does not warn you. A warning in the log and a clarification on the documentation will be implemented. By doing so you will never have two or more devices connecting to the same server. when the air-connect command for the same country is issued by different clients in different devices. If Bluetit connects during the machine bootstrap, remember to send disconnect first: enabled persistent network lock by directive networklockpersist ensures no traffic leak outside the VPN tunnel. In a future Bluetit version we might implement a new Bluetit run control file directive defining a white list for automatic connection at bootstrap so that you will not need to send a connection order via a client later on. Kind regards

Hello! Yes, of course, you get the same privacy protection enhancements in both connection types (provided that the VPN connection is established). In particular: your outgoing packets do not have anymore your "real" IP address when they get out of the VPN server (this is also why, in addition to privacy enhancement, we define our service as capable to provide "a layer of anonymity") you are no more subject to DNS poisoning, which is common practice with all ISP in the world including European ISPs the VPN tunnel protects you from injection of forged packets your ISP and anybody who wiretaps your ISP line can not see anymore which services you contact, which underlying protocols you use and which underlying applications you run, because of the encryption of outgoing and incoming packets between your client and the VPN server A caveat in cellular connections when it is used together with a device running iOS or Android. By Apple policy, Apple applications can bypass at will any VPN tunnel (and actually some of them already do it) Similarly, in Android systems, manufacturer's applications might potentially do the same. This is possible because you are not the administrator in Android and iOS systems and therefore you have no control on those important parts of the system which would prevent such "leaks". Therefore, when privacy protection is a priority, Android and iOS should not be trusted. What about the "anonymity layer" we mentioned earlier? The anonymity layer is provided by the first point of the list, together with the fact that we operate servers in countries where data retention is not mandatory, so we not only avoid inspecting traffic to remain a mere conduit, but we also do not log traffic metadata. So it's not an intrinsic property of a VPN, but it is related to how it is implemented in our systems. Now, this anonymity layer resists as long as we don't betray your trust AND our servers are not secretly wiretapped. How to defeat an adversary with the power to wiretap your line AND all the VPN servers you connect to? And what to do when you can't afford to trust our contractual commitment on "no logging"? This question has become relevant for more and more persons who are "high profile targets". Remember that everyone can become a "high profile target" simply by being an activist on certain matters. Every year, for example, hundreds of environmental activists are killed around the world and hundreds disappear mysteriously or suffer severe limitations on personal freedom or suffer major physical harm. And that pertains only to activism on environmental problems. Bloggers and journalists are imprisoned, as well as whistleblowers, or killed, in the so called "Western countries" too, simply for having told the truth. In certain areas of Italy, you must protect your identity even if you write a few substantiated rows anywhere on the web against some minor political figure in your tiny district when that political figure has ties with the organized crime, and we know that something similar happened in other EU countries. We could go on with plenty of horrendous exemplary cases, which took place even in "Western countries", where a more effective layer of anonymity would have saved, during the years, thousands of lives, but let's answer the original question on how to improve the anonymity layer and defeat a powerful adversary with this old article of ours: https://airvpn.org/forums/topic/54-using-airvpn-over-tor/?tab=comments#comment-1745 So, we wrote the above article many years ago, which may help high profile targets. Keep in mind that everything starts from the assumption that your system is NOT compromised. If it is, any VPN, Tor, Tor over VPN, will be useless. So we come to other important limitations you must be aware of: a VPN does not protect your device a VPN is useless if your device is compromised, and some systems such as Android and iOS may be compromised in a matter of minutes by a powerful entity that comes to know your IP address a VPN must not be meant as an anti-cracking tool: the only protection against some types of cracks is no remote port forwarding, which is mild a VPN can not hide your personal data or identity if you send out personal information inside your traffic flow and the recipient of such information is compromised, or if you send it out in public a VPN does not prevent correlations when you mix identities, i.e. it can't protect you from your own behavior, therefore take care not to mix identities inside and outside the VPN. Trivial, maybe stupid, example. if you have used an e-mail account without VPN, and then you use it from the VPN, the mail provider and other entities can still come to know your real identity via IP address of your past connections on record or other data. a VPN does not hide your system and browser fingerprint. For highly sensitive information transmission when your identity must not be disclosed, avoid the WWW completely (recommended solution). However, if you are compelled to rely on the WWW, at least use the Tor Browser Kind regards

Hello! Of course. That's the risk with WebRTC: the disclosure of the "real" IP address when you don't want that. The "noble" purpose is allowing two or more peers to connect directly with each other for video chats and so on. Each peer must know the public IP address of the other ones to accomplish the task. WebRTC (when it is active) provides developers with an API which can disclose it. See https://webrtc.org/getting-started/peer-connections and following docs. https://webrtc.org/getting-started/peer-connections As long as the local address is private and assigned by your home router, that's the only case of no concern. With OpenVPN, disclosure of the tun address is not a concern, right, because we are unable to correlate a VPN IP address to a user when the connection is over. But it's not all good in general, unfortunately: with Wireguard, disclosure of the tun address (the VPN IP address) is risky too, because of the bijection between client keys and static VPN IP addresses which Wireguard also mandates to replicate in a file on every server. Under this respect we can only mitigate the problem by randomizing IP addresses assigned to keys and deleting periodically the file entries when we suppose a client is no more connected (Wireguard lacks even the disconnection notification feature by explicit design). But in the whole time between deletions, we know who is who, and we must provide this information for example after a court order, which could also include prohibition to delete relevant data whereas it is an ACTIVE action that we (and not some third-party app) perform in spite of lack of technical necessity. Kind regards

Hello! In this case just send us, if you have time and will, the crash message from Eddie 2.20. An important suggestion: you should never use VPNetMon. it is insecure by design, not able to prevent most types of leaks (wrong binding, UPnP, NAT-PMP... by your torrent software) and it's dangerous, as it may kill forcefully applications causing their data corruption in your HDD/SSD. Furthermore it is not able to prevent leaks, not even in ordinary disconnections if it can't detect them, if the CPU has a high load, or if the app hangs. Use Network Lock instead. Activate it before you start a connection by clicking the big button on the main Eddie window. Network Lock prevents any type of leaks, even if Eddie or OpenVPN crash, because it is a set of firewall rules. Eddie was not stuck, it was just waiting for the application to return an exit code. You can tell Eddie to not wait and go on as we wrote. In this case Eddie will run the application only, and will immediately forget it and move on. When you define the command for an event, the window shows "Wait end of process". By default it is ticked. You can de-tick it in order to make Eddie not wait for the end of the process. We don't see how we could make it "a bit more user friendly"... anyway, now you know. Kind regards

@airsupportusertempforum @cannac Hello! Those problems you mention should be different and unrelated. When Bluetit gets stuck in a loop of re-connections caused by OpenVPN3-AirPVN inability to reconnect to the same server, no --recover-network should be necessary, provided that you stop Bluetit properly, or you just send a disconnect command. Then you can send an air-connect command or what you need. The OpenVPN3 inability to re-connect when you abruptly disconnect, and later re-connect, the Ethernet cable will be investigated. As far as we can see it may occur with OpenVPN 2 too and we suspect to know why. In such cases anyway a disconnection followed by a connection resolves the issue both with OpenVPN3-AirVPN and OpenVPN 2. The problem mentioned by @cannac has not been reproduced unfortunately. and we have no clues or suggestions at the moment. Can you tell us your Linux distribution name and version and describe the problem which forced you to change the symlink? Kind regards

Hello, Eddie can run scripts and binaries when certain events take place and: wait for the script/binary/whatever run by the event to return an exit code, OR run & forget & move on (no wait, defined as asynchronous mode in the documentation) From your description you needed solution 2, with a kill to the same process at the next suitable event. About the kill, do as @OpenSourcerer wrote in a previous message. Yes, the feature you want was implemented in 2014 or so, but it needs to be documented.for the GUI. Currently it's documented on the CLI guide and on the man. Anyway now you know and it's quite intuitive, enjoy! https://eddie.website/support/cli/ See: event.app.start.filename - Filename of the script/executable to launch on event. event.app.start.arguments - Arguments of the script/executable. event.app.start.waitend - Use True if the software needs to wait the end (synchronous) or False to be asynchronous. Default: True event.app.stop.filename - Filename of the script/executable to launch on event. event.app.stop.arguments - Arguments of the script/executable. event.app.stop.waitend - Use True if the software needs to wait the end (synchronous) or False to be asynchronous. Default: True etc. You can achieve all of the above in the GUI too. Can you verify whether the unexpected crash (we can't reproduce it) persists with Eddie 2.21 beta version? If so, would you be so kind to send us the whole crash message? To download Eddie latest beta version please see here: https://airvpn.org/forums/topic/49638-eddie-desktop-221-beta-released/ Kind regards