Staff

@BKK20 Step 1 is almost correct: please remember that our VPN servers have different entry and exit-IP addresses The relevant DNS record must be set to the exit-IP address. Step 2 is correct.. "after that" is not correct. The proper URI for your browser would be http://www.example.com:34567 or https://www.example.com:34567 (http or https according to your web server settings). Also remember to access your web server running behind a VPN server from a machine that's not connected to the same VPN server. Kind regards

@Stalinium Thank you! The problem has been resolved with the domain name. However, we still have issues with three servers in Dallas, including Pegasus, which have been closed (so they will not be picked for names resolution or by our software). We are working on them. EDIT: problem resolved. Kind regards

@JBronson Hello! The 1st problem was here: Sep 25 05:19:21 mostfantasticfox bluetit[2260]: Bluetit is already running or did not exit gracefully on its last run or has been killed. Exiting Sep 25 05:20:23 mostfantasticfox bluetit[2164]: Requested method "bluetit_status -> Bluetit is connected to VPN" Bluetit was in a dirty status and refused to proceed. However, when queried about the status it replied with the wrong message "connected to VPN". This is a bug we need to fix, thank you for having found it out, which explains why no tun interface was up when Bluetit misleadingly reported it was connected to the VPN. Later on, Bluetit does not detect anymore a dirty status but the nameserver remained set to a VPN DNS address, which is inaccessible from outside the VPN. Maybe you have tried to recover the network settings manually and you forgot to restore DNS? We ask because suddenly Bluetit does not detect anymore a dirty status and refuses to perform a network recovery: Sep 25 05:33:09 mostfantasticfox bluetit[1648]: Requested method "recover_network -> " Sep 25 05:33:09 mostfantasticfox bluetit[1648]: Requested method "Bluetit does not need a network recovery." Therefore, the subsequent connection attempts are doomed: Sep 25 05:28:21 mostfantasticfox bluetit[1441]: Allowing system DNS 10.7.58.1 to pass through the network filter Sep 25 05:28:31 mostfantasticfox bluetit[1441]: WARNING: Cannot resolve ca3.vpn.airdns.org (Temporary failure in name resolution) and Bluetit enters an infinite loop of re-connection attempts which don't succeed for the same reason. In order to resolve the issue, please make sure that Bluetit has exited cleanly and is not running, then manually modify DNS settings. Pick your favorite, publicly accessible, nameservers. Kind regards

Hello! Yes of course. Maybe you have missed the answers twice, please check them: https://airvpn.org/forums/topic/49776-own-webhosting-port-fowarding-set-a-record/?do=findComment&comment=169233 https://airvpn.org/forums/topic/49776-own-webhosting-port-fowarding-set-a-record/?do=findComment&comment=169282 Kind regards

Hello! 1. Thank you very much for your tests and bug report! We will check and fix. 2, Yes. Next version (either alpha 3 or beta 1, we'll see) will offer a range of options to start Eddie and have your device connected to AirVPN even without profiles, when the Master Password is disabled, during the bootstrap. Kind regards

@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