Staff

Of course. The re-activation was performed and then the account was suspended again for further infringements. In the meantime the user refused the re-activation in any case, but that's irrelevant as you correctly notice. Kind regards

Exactly, and that will not be tolerated. Thread stands anyway for a while, waiting for documentation supporting the claims.

Hello, our client pings all VPN servers to assign a rating from your node which includes round trip time. Ping is based on ICMP. Our VPN servers are inside datacenters owned or operated by some of the companies you cite. The option can be disabled, but it is normally quite useful. In absence of a documented justification for the claims you wrote, they must be considered defamatory and your message will soon be deleted. These forums are aimed to community support from the community and must remain crap-free. Kind regards

Hello and welcome! That's because authentication is not based on username/password but on certificates/keys. user.crt is the client certificate while ca.crt is the CA certificate. They are embedded in the .ovpn file(s). To generate split files please tick "Advanced Mode" > "Separate certs/keys from .ovpn files" in the CG. Kind regards

Unfortunately there are two good reasons... Eddie is an OpenVPN frontend. It has tons of additional commodities but the core security of the tunneling, connection and packets handling (and more) remains to OpenVPN/OpenSSL/PolarSSL. Forking OpenVPN to support something different would be a paramount task, not to mention the huge security risks related to the operation... Kind regards

Hello, to make it realistic, you should keep the wish list limited to OpenVPN supported digests and ciphers only... Kind regards

Hello, no, there is no such logging at all. The case is different when an attack is brought against an Air server. When an Air server is attacked, the attacking IP address(es) may be logged to defend the server (although it could be perfectly useless in case the IP addresses are spoofed), this is quite ordinary and has nothing to do with traffic logging, customers IP logging etc., which is not performed as usual. In the exceptional case in which an Air server is attacked by a customer connected to an Air server (either the same server or a different server), then of course we have a very unexpected option to locate easily the attacking source and mitigate or solve the attack. The investigation starts because an Air server is attacked, not for some other reason. It's physically impossible that the activities you describe can configure an attack to an Air server (VPN server, web server...). You can imagine the surprise to see that someone attacks the very same infrastructure he/she is connected to. Apparently it makes no sense, so it is possible that the attacking system is infected (as we said to the attacker) or this behavior has been followed only to fabricate a case, who knows. Kind regards

Hello, we're very patient when our systems are attacked, but patience is not a synonym of stupidity. The redacted ticket history is quite self-explaining, as well as the language you have used. Here it's just worth mentioning that if you attack an Air VPN server from another Air VPN server you will face consequences. Your behavior can also be configured as a criminal infringement in most, if not all, European Union countries. Even if you come from a country where such attacks are not covered in the legal framework, you must anyway comply to the Terms of Service you accepted. If you don't, face the consequences and go elsewhere. We have moved this thread in "Off Topic" because we find that it does not find place in any other forum of ours. Please note that your message is also recorded in case of any criminal prosecution against you from any action initiated by us or any other attacked entity, since you have been so dumb to make your potentially criminal infringements partially public. EDIT: we confirm that customers traffic is not logged and that there are no traffic limits. However, if a VPN server is attacked, it's the VPN server itself that takes countermeasures and can of course log IP addresses of the attacker(s). This case is quite unique since an Air VPN server has been attacked by your system through another AirVPN server. Kind regards

Hello, please follow the instructions for iOS in our webs site. If you need no communications when VPN connection goes down for leaks prevention etc., please enable "Seamless tunnel" option on openvpn-connect and also activate option to run and connect at system startup. Kind regards

Hello, that's correct, "Enable Network Lock at startup" enables Network Lock at software startup, not immediately and not at the start of a VPN connection. If the description is ambiguous, we could change it into "Enable Network Lock at software startup", to clearly differentiate it from "VPN connection startup". Anyway we don't think that "at startup" can be easily confused with "immediately". You have a huge button in the middle of the main window, frankly we don't see it as a problem. Kind regards

Understood... if there's no limitation on the source IP address or network, it would not be possible anyway for us. Since each additional connection slot is sold at 1 USD, this is similar to selling independent accesses at about 1 USD for the whole duration of the main subscription. Not sustainable with our bandwidth allocation commitment and quality of service we are currently providing, and we don't frankly believe it could be sustainable for any VPN service that wish to provide at least 8-16 Mbit/s per connection (with no VPS and using almost every time datacenters with good or excellent peering). Feel free to check: make your calculations based on the cost of bandwidth nowadays in the countries we have servers in... Kind regards

It looks like that different IP addresses cause different behavior (or access different backends, or something like that). From Netherlands VPN servers the long-awaited "time menu" is finally visible, but sometimes it does not work well and usually does not work at all. From non-NL servers, the menu seems not acccessible at all (at least at the moment of this writing). Kind regards

Hello! We think that three simultaneous connections from any network / IP address without any limitation on each connection slot is enormously more valuable than five simultaneous connections only from the same network. what do you think?

https://duck.co/forum/thread/1678/filter-search-results-by-date But keyword "sort:date" does not work, apparently. https://duck.co/help/features/dates This again relies on Google, it's not a solution...

so if you live in a country which tries to disrupt vpn technology, the state just needs to cache all exit ip adresses of popular vpn services and you are done, right? No: blocking exit-IP addresses would have an impact only on services inside that country, but would allow a citizen to connect to our VPN servers and go out on the rest of the world. They would need to harvest different IP addresses (entry-IP addresses of course, and many other ones that of course we will not mention here). Additionally, you can easily imagine a way to circumvent even this block if you think about all the connection abilities of OpenVPN, even cited in this thread... Kind regards

@coconuts What exact Debian distribution version are you running? Kind regards

You need to tell Linux to use the AirVPN DNS server. Or set things up to make the change whenever the OpenVPN connection is started or stopped. See: https://airvpn.org/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf/ In the past, staff have called this a "misconfiguration" (or something like that), rather than a "leak". The difference between Linux and Windows is that for Linux you do it once in one place. For Windows you have to do it for each interface. Arguably an absurd feature, responsible for the labeling of Windows as suffering from DNS leaks. Exactly, it is factually and definitely not a leak, under any possible point of view. Global DNS stands so even if OpenVPN client doesn't accept (in GNU/Linux) OpenVPN server DNS push, your DNS queries to DNS servers outside the local network will be "tunneled" in any case. This is a really remarkable difference between a system where global DNS is implemented and a system where global DNS is not implemented and default gateway for each interface is considered in DNS queries. Windows makes both things, that's why in Windows so called "DNS leaks" are real, physical leaks (packets not encrypted and routed via the "wrong" gateway). There is probably a way to configure a GNU/Linux system to emulate Windows DNS implementation, for didactic or exotic purposes, and force DNS queries go outside the tunnel regardless of the routing table, but this is an intentional "corruption" so it is not taken into consideration. Kind regards

That's based on the detected "fingerprint" by the final service, when packets are all out of the tunnel. It is a different issue than hiding OpenVPN between your node and the VPN server (typically where your ISP observes you). See WITCH for the original code http://witch.valdikss.org.ru/ At the moment you can make WITCH unable to recognize OpenVPN usage in UDP by selecting unusual mssfix parameters. Interesting to compare with this: https://airvpn.org/topic/17709-netflix-how-to-accessuse-it-when-vpn-is-connected/ Kind regards

You can quickly copy the logs to the clipboard by clicking (from Eddie main window) "Logs" > "Copy to clipboard". Alternatively enable logging to file in "AirVPN" > "Preferences" > "Advanced" > "Logging" and then access the log file, for example with any text viewer or editor. Kind regards

It compares your system IP address with all the Air VPN servers exit-IP addresses. Kind regards

Such Windows messages are ambiguous and sometimes over-agonizing, are you sure that it was not just a DNS problem? Windows diagnostic tool will shoot alarming error messages even when the only problem is that the system can't resolve names. And sometimes it will suggest to revert to some previous system wide restore point just because of a simple problem in network interface DNS settings that could have been solved in a matter of seconds. Have a look here and make sure to always shut down the Air software properly (don't kill it without grace, or it will not be able to restore your system settings until the next run): https://airvpn.org/topic/14829-can-only-connect-to-the-internet-browser-through-airvpn/?do=findComment&comment=30509 Kind regards

While Tania passed the tests successfully for days and days, as soon as we put it public it started having a bunch of problems, including high packet loss with most of our other servers. Then, it became unreachable from most of the Internet. We are waiting for datacenters technicians investigation, anyway we are ready to withdraw it if the problem is not solved in the near future. Kind regards

Hello! Please see here: https://airvpn.org/topic/11208-in-what-order-the-client-choose-recommended-servers/ Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in Dallas, US-TX, is available: Auva. The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Auva supports OpenVPN over SSL and OpenVPN over SSH. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Which leads me to my next question. If VPN servers use your current network as a passthrough to another network, why is the passthrough network the one that takes it up the ass when it comes to legal issues? Usually it does not. Apart from considerations of liability exemptions due to mere conduit status, safe harbors and similar terms used in other legal frameworks, usage of a VPN tends to reduce to zero any liability of the original "passthrough" network, because traffic is encrypted and any third-party entity sees any infringement coming from the VPN, not from the "passthrough", physical network. Usually, as far as we can understand, different reasons lead to protocol/applications blocking: marketing reasons (for example profiling purposes, ads through packets injections, DNS poisoning for a myriad of reasons - all of them become impossible with a VPN) and traffic management (effective traffic management becomes virtually impossible with a VPN). Kind regards