Staff

@tlc See our previous reply. Your traffic to airvpn.org is hijacked and either your ISP, your DNS or some malware in your system try to send you to some fake/bogus airvpn.org web site. Since the problem disappears when you are in the VPN, we would rule out that a malware is the "culprit", because it would hijack your traffic even inside the VPN. The browsers are doing their job and good for you that we implemented HSTS. If you wish so, can you contact us in private and tell us your ISP and DNS? Kind regards

Hello! It's a packet ID error: a packet failed authentication. Only one packet error every minute is irrelevant for practical purposes, it means that only one packet per minute needs to be re-transmitted. Bad packet IDs suggest: - replay attacks (OpenVPN is very strong against replay attacks, impossible to inject forged packets) - bad line - MTU size (of your network interface) that can't fit TCP packets inside the UDP stream. "mssfix" is supported (*) (*) "mssfix n", where n is in bytes, is a directive which tells OpenVPN to split (in the UDP flow) TCP packets larger than n bytes. You can try for example "mssfix 1400" and check whether packet errors disappear or become less frequent, then go down at little steps if necessary. Anyway if you get only one error per minute maybe you don't need it. The lower the mssfix value, the more you can harm performance, as you enforce packet splitting of smaller and smaller packets. Kind regards

Hello! Keep in mind that even Windows, like any other Operating System, offers "cron jobs". Search for "task scheduler". Example: https://stackoverflow.com/questions/7195503/setting-up-a-cron-job-in-windows#7195722 Kind regards

Hello! Problem resolved, enjoy! Kind regards

Hello! Please see here: https://airvpn.org/forums/topic/28795-what-about-eddie-for-ios/ Kind regards

@hawkflights Hello! Can you please tell us your exact Linux distribution version? @colorman Hello! TLS Crypt encrypts the whole OpenVPN Control Channel. Therefore DPI can't detect anymore any typical OpenVPN "fingerprint", thus can't trigger traffic shaping against OpenVPN, or similar. TLS Crypt in an agnostic network does not improve or affect negatively performance, as most of the time is spent on encryption and decryption of the Data Channel. Therefore, if you experience a better throughput with TLS crypt, a plausible explanation is that your ISP enforces traffic shaping. @inc Hello! Should the re-keying errors re-appear, can you tell us your exact Linux distribution version? @funkoholic Hello! Connection over Tor is not planned for the next major release, which is focused on creating an Hummingbird daemon and two different frontends, one of them in Qt, without adding major new features at least for the first release cycle. Connection over Tor is a special case of the more general connection over a SOCKS proxy, with the addition of communications with Tor to obtain the Tor entry-node IP address and route it outside the VPN, preventing the infinite routing loop problem. Hence, we need to review the code of the library pertaining to connections over a proxy, which we did not touch. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in Siauliai (LT) is available: Tarf. The AirVPN client will show automatically the new server; if you use any other OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP. Just like every other "second generation" Air server, Tarf supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.2 and tls-crypt. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check the server status as usual in our real time servers monitor: https://airvpn.org/servers/Tarf Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

@Air4141841 Hello! key-direction 1 when you use TLS Auth key (i.e. you connect to entry-IP addresses 1 and 2). Omit it when you use TLS Crypt (i.e. you connect to entry-IP addresses 3 and 4), because it's not pertaining to TLS Crypt. For an explanation, look for secret file [direction] and –key-direction in the manual https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/ If you run OpenVPN 2.4 or higher version, TLS Crypt is recommended because it encrypts the whole Control Channel, with the important side effect to make OpenVPN "fingerprint" not detectable by Deep Packet Inspection (some ISPs, when they detect OpenVPN "fingerprint", enforce traffic shaping). Kind regards

Hello! Thanks for the link. Nice that they talk about it, while it's sad to see that some people "suspect" about something weird when the code is open and a simple diff will tell you everything, even in relation to the bug fixes and new features. If you read our forum you already know why the major changes and critical bug fixes are not in the main branch: AirVPN commits have been refused with pathetic motivations which have NEVER been technical reasons. Arne Schwabe even talked about coding standards when the code he (or OpenVPN 3 maintainers) approved previously is infested by "goto" (!!!), "break", wrong indentations and totally crazy stuff, while AirVPN code is very elegant even according to the Art of Computer Programming books. Therefore, now OpenVPN 3 library is bugged, obsolete, without CHACHA20 support and unusable in Linux (just verify the critical bug in re-connections inside a session, which has been patched by us), while OpenVPN 3 AirVPN fork has CHACHA20 support (in Data Channel too), ncp-disable, a new class to handle AEAD ciphers, and works nicely in Android, Linux x86-64 - ARM 32 - ARM 64 and macOS. Kind regards

IPv6 is fully supported on almost all of our servers since 2018, works perfectly and has always worked perfectly except for short black outs caused by datacenters. Currently we have no known problems with IPv6. Please note that Kitalpha (Swiss) does not support IPv6. The problem must therefore be on client side. In most cases it is simply caused by having disabled IPv6 either on some network interface (for example the tun interface) or at system level. Open a ticket if necessary. Kind regards

Hello! We inform you that all of our Lithuanian servers are being withdrawn and dismissed. The datacenter provider, Cherry Servers, has just asked for a block of all outbound ports except a few ones they called "standard ports" (sic) to prevent any possible future "copyright infringement" (to be noted: no infringement in the past has ever been proved). It is clearly an unacceptable request for us, and we guess for everyone, and it also reveals the true face of Cherry Servers datacenter as an enemy of the Internet. For us, it's also an option to finally get rid of the last servers still not supporting IPv6. Cherry Servers was one of our last providers still lacking IPv6 support, a fact that should have given us a "head up!" about Cherry Servers poor commitment to providing decent services. We will be actively looking for an alternative datacenter. We will be looking for datacenters where the concept of mere conduit is understood, and IPv6 infrastructure is available. In the meantime keep in mind that we offer several servers in the Baltic region as well as other, nearby countries. Kind regards

Hello! We contacted Paysafecard in 2013 and they confirmed that they did not accept VPN providers as merchants. It was a very well known issue and some journalists wrote about it. We remember an article on TorrentFreak for example: https://torrentfreak.com/paysafecard-begins-banning-vpn-providers-130825/ Our brief message exchanges with Paysafecard at the time confirmed fully that we were not allowed to offer Paysafecard as a payment method. Kind regards

@inc @hawkflights Hello! The remote, destination server connection is always logged. Of course it may report exclusively an IP address and not an FQDN with its resolution: that depends on the profile. In case of Air VPN servers, the CN can be either the server name or a generic "server" string (we need to make that consistent, yes). A full integration with the AirVPN "bootstrap" servers will come with the future frontend(s) directing the daemon we mentioned in our previous message (you may have a sort of idea by looking at Eddie Android edition source code). We will disclose an estimated release date of the Hummingbird daemon beta version soon. Your request has been well understood: in Linux several community members asked us to drop Mono and required software "10x" faster than Eddie, and we think that we have made some important steps in the right direction, according to the general feedback (thanks!). Remember, furthermore, that even Eddie 2.18.5 piece running as root is completely written in C++ and does not require Mono (Eddie GUI does). Please keep reporting the problem (we still think it has to do with the re-keying), and also a comparison with OpenVPN 2 from the very same system of yours, if you can and if possible. Kind regards

Hello! AirVPN does not. However all information is held both in your and AirVPN PayPal accounts, or in your credit card company records. Such information can not be deleted and will be maintained by PayPal or by your credit company for a very long time, according to the appropriate legal framework. We remind you that we accept a wide range of cryptocurrencies without intermediaries. Kind regards

@inc Hello! A GUI is planned, when the Hummingbird "backend" will run as a daemon. We are already working on it, right now. At the moment you can see the information you need on the standard output, and rightly so! Hummingbird 1 "branch" must remain a light and stand alone binary with no graphic requirement of any kind. If you need a GUI at the moment please run Eddie. The problem you mention looks like a failure to DHE. Do you notice a similar problem with OpenVPN 2.x or not? Kind regards

Hello! Windows 8 and 10 can freeze processes. The established connections of those processes, apparently, remain frozen too. Network Lock protects you from traffic leaks outside the tunnel when such processes are unfrozen. Just to be 100% positive about that, we have reproduced exactly what you report with the Telemetry Service and no data pass through or outside the VPN tunnel in any case: when the system is not connected to the VPN and the process is frozen and then unfrozen, it can't communicate; and when the system is connected to the VPN and the process get unfrozen no packets get out of the tunnel. You can verify with Wireshark for example. Kind regards

@Giddy169 Yes, a port is just an abstract construct to represent how a host identifies a running process, so that from 2 specific bytes on IP packets the host knows which process must receive those packets payload. If the process does not exist you can't even talk about "open" or "closed" port, simply the port does not exist. However, it's true that a non-existing port is often called a "stealth port" or even "closed port", but that's a sort of language abuse if you think of the actual definition of "port". Kind regards

@inc @colorman Hello! Do you both confirm that the tunnel remains active, data flow continues regularly and connection is not lost? Can you also please confirm that your system time is correct, with a maximum discrepancy of just a couple of seconds? Kind regards

Hello! Currently you need to build Hummingbird directly on your system. Please follow the instructions in GitLab: https://gitlab.com/AirVPN/hummingbird#building-hummingbird-from-sources Kind regards

@Giddy169 Hello! Also make sure that the camera software is listening to port 8000 and not binding to the physical network interface, and that you try to access the camera on the correct exit-IP address of the VPN server, and the proper port (the port you have remotely forwarded and that you remapped to your local port 8000). Furthermore, make sure that no firewall blocks packets to/from the software when the system is connected to the VPN and that you try to access the camera software from a device that's not connected to the same VPN server. Kind regards

@inc Hello! It looks like the client fails to negotiate the new Data Channel key after the old one has expired (in our service PFS is implemented and DHE occurs every 60 minutes by default). Since the old key is kept in use until the re-negotiation is not finished, the connection is not broken, but the Data Channel uses always the same encryption key. How frequently do you get those errors? Did anybody else notice them? Kind regards

Hello! Netflix USA and only USA is accessible from AirVPN servers as usual if and only if your system queries AirVPN DNS (which happens by default with our software). EXCEPTION: the following servers can not reach Netflix USA at the moment;: Kruger Sneden Fang Nahn Sham Also note that Netflix application has been reported as maliciously bypassing system DNS or exploiting other techniques to disclose your real location. You will be blocked if you are not in the USA in Netflix' app belief, but it's not a fault of our system. Deleting application's cache and then running it only and uniquely when the device is connected to the VPN has been reported as solving the problem in various cases. @giganerd Connecting through a VPN to stream Netflix USA when you are in the USA makes sense in any case (check the wars of major USA ISPs/transit providers against Netflix to get paid by Netflix in order to not block its traffic). Unfortunately Netflix at the end of the day sided with those who have contributed to dismantle the Internet and Net Neutrality in some countries of the world and in this sense it's just another enemy of that very same infrastructure and technology that made its fortunes. Kind regards

@Giddy169 Hello! Can you please recheck your tun interface name with command ifconfig or ip link show from a telnet or ssh connection to your router? Just in case it's not "tun11". Check also whether "br0" is correct or not. Moreover, what is that destIP in the script you pasted, in FORWARD and even in the PREROUTING chain of the nat table? "destIP" must be replaced with the actual IP address you want to pre-route and forward packets to. Kind regards

@jx35552zza Hello! The connection is lost without chance to recover it (fatal error). It's expected when the network interface is turned off to save power. Eddie then "locks" the tunnel to prevent leaks. If you have Android 9 or 10 you can disable the "VPN lock" option from the "Settings" and enable Android's features "Always on VPN" and "Do not allow traffic outside the tunnel" to prevent traffic leaks AND give Eddie the option to re-connect safely after any unrecoverable connection error. Kind regards

Hello! What are the features of the sleep mode? Specifically, is the network card turned off, applications frozen and/or the whole system hibernated? Kind regards