Staff

Hello! Unfortunately not, OpenVPN does not scale well, and each instance will use one single core. This is an important limitation that will be probably overcome only in the next major release 3. Kind regards

Hello! mage1982 is right. We just wish to add that we are focused on VPN services at the moment, so we have no immediate plans to provide a public DNS service. Kind regards

Hello! That's right, there are no DNS leaks on Linux. Can we see the content of your /etc/resolv.conf file before and after a connection to a VPN server, with method "Renaming"? Maybe your system sends to your ISP IPv6 DNS queries. Kind regards

Hello, SlyFox is right, this is perfectly normal. Your router CPU processing power can't handle more than 10 Mbit/s AES-256 throughput (AES-256-CBC is the cipher of our OpenVPN Data Channel). Use a powerful enough pfSense box or connect directly from your computers (up to three simultaneous connections form different devices are possible with the same account) to bypass your router bottleneck. Kind regards

Hello! Our service is based on OpenVPN and OpenVPN connections are disrupted in most China residential lines. This is possible because OpenVPN packets headers (not payload, which are of course encrypted) have some additional information for packet re-ordering that make them discernible (with DPI) from pure TLS/SSL connections. PPTP with insecure authentication (not supported by us) is not disrupted (that's why you could use other non-OpenVPN based services, probably), maybe because it's not a problem for Chinese authorities (they can break it and decrypt the traffic flow very quickly and easily). In order to bypass the block, OpenVPN over SSL is necessary. The first SSL tunnel encrypts the OpenVPN "fingerprint" to make it not detectable. The method has been tested as successful since more than a year ago from various China areas, including Shanghai and Beijing. Unfortunately, OpenVPN over SSL is available for Linux, Windows and OS X only. It is not working on Android and iOS for limitations of the openvpn app. Anyway, many mobile networks in China do not block OpenVPN, so this is a relatively minor problem. Our client Eddie (for Linux, OS X and Windows) implements OpenVPN over SSL, that can be activated with a click. All of our VPN servers accept this connection mode. On Eddie, click "AirVPN" button, select "Preferences", click "Protocols" tab, select "SSL Tunnel - Port 443" and click "Save". As you can see from the logs, Eddie client is perfectly capable to establish a connection even if your system can't reach our web site. Please contact us in private (open a ticket) if you want to access our web site even without VPN. Kind regards

Hello! ipleak.net queries commercial MaxMind database (and we pay for it), which is wrong as well. We'll think about your suggestions and a solution! Kind regards

Well, might be that a bit risky, don't you think? For instance, what happens when you receive DMCA complaints (probably you just remove the torrent), but what if they go beyond that.... Don't you are more responsible with the content that you seed because you purchase the server directly from the datacenter, instead having a 3rd party that takes a bitt of risk themselves by offering this kind of services. Hello, seedboxes are dedicated to share files that are not necessarily protected by restrictive copyright. Ideally a DMCA complaint in the USA should be received only if there is a copyright infringement (yes, we know there are so many mistakes with wrong notices and copyright trolls around, but that's another story). Given the initial message of this thread, it should not be assumed that a seedbox is used in any illegal way. For clarity purposes we should keep this thread focused on technical usages (or installation) of seedboxes and reviews of services, while a voluntary infringing usage of seedboxes should be discussed elsewhere. Kind regards

Hello! It's not completely clear what you want to achieve. Perhaps some clarifications are necessary. First of all, it must be clear what a port (in networking) is. Wikipedia provides an outstanding, great, precise definition in article http://en.wikipedia.org/wiki/Port_%28computer_networking%29 : "In computer networking, a port is an application-specific or process-specific software construct serving as a communications endpoint in a computer's host operating system. The purpose of ports is to uniquely identify different applications or processes running on a single computer and thereby enable them to share a single physical connection to a packet-switched network like the Internet. In the context of the Internet Protocol, a port is associated with an IP address of the host, as well as the type of protocol used for communication. The protocols that primarily use ports are the Transport Layer protocols, such as the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) of the Internet Protocol Suite. A port is identified for each address and protocol by a 16-bit number, commonly known as the port number. The port number, added to a computer's IP address, completes the destination address for a communications session. That is, data packets are routed across the network to a specific destination IP address, and then, upon reaching the destination computer, are further routed to the specific process bound to the destination port number. Note that it is the combination of IP address and port number together that must be globally unique. Thus, different IP addresses or protocols may use the same port number for communication; e.g., on a given host or interface UDP and TCP may use the same port number, or on a host with two interfaces, both addresses may be associated with a port having the same number." Therefore, a port is said to be "open" when all the following conditions are met: 1) it exists 2) packets to it are not dropped or rejected by any packet filtering tool 3) the process identified by the port replies Condition 1 seems trivial but please think about it. If there is no process identified by the host by a certain endpoint, there is no endpoint at all. The port does not exist, period. In common language this is one of the cases for which we say that "a port is closed". When you remotely forward a port on our system, the VPN server will take care to forward packets to your VPN IP address:port number so you will be able to have listening services (i.e. processes identified by a unique endpoint) behind our NAT. Thus: - if your service does not run, our servers forward packets but your system will not reply because it does not know which process it should send the packets to: "the port is closed". - if your service runs, but a packet filtering tool on your system rejects or drops packets, the port does exist but it is again "closed" - if your service runs and your packet filtering tool does not reject or drop packets it, but the port is not forwarded on our system, the VPN servers will drop the incoming packets from the Internet: the port is once again "closed" (from the external "Internet point of view") - if your service runs, your packet filtering tool does not intercept packets to it, and the port is remotely forwarded on our system, the port is "open" The problem you cite with Windows is probably due to the fact that by default a lot of processes (identified by an endpoint on the host) run without the user awareness, therefore a lot of ports "are open" by default. If the process associated to the port has one or more vulnerabilities, it may become the target of an attack: by sending packets to that port (i.e. by communicating with the vulnerable processes) an attacker could exploit such vulnerabilities for various purposes, including taking root control of the machine where such process runs (with privileges escalation, or with some intentional overflow just to make two random examples). Hence the basic rule: not running processes that you do not need is the first, simplest way to "close a port", even before than setting up a packet filtering tool. When you're connected to our service, by default "all ports are closed". This means that the VPN server will not forward anything to your VPN IP. However, this does not mean that ALL of your host ports "are closed". For example, if your computer is behind a router NAT (very common case), AND you have processes running on the computer and listening to the physical network card AND you forward ports on your router matching the same endpoint of those processes, packets can reach those processes through that other forwarded ports. In general, when you are connected to a VPN server you should not forward ports on the router. Not only it is useless, because the VPN tunnel bypasses your router NAT as well as your ISP NAT (if any), but it is also potentially dangerous. In particular if you forward the SAME port numbers both on the VPN and on your router, and you have a process listening to those ports, correlation attacks become possible. Kind regards

Hello! You can verify that in the RIPE database all the Nihal IP addresses are correctly geo-located in Spain: https://apps.db.ripe.net/search/geolocation-finder.html RIPE NCC is one of the five world RIRs (for Europe, Middle East and some Asia regions) so everything is fine. We can't follow all the hundreds, or maybe thousands, of geo-location IP addresses databases that contain errors. Unfortunately maintaining such a database in good order is a hard task, and it is not uncommon that maintainers are unable to fulfill this task. Kind regards

Not my claim , but by Glasnost! Some hours ago udp tracker don't work under ssl, that's a fact. Hello, there is no difference for the server to reach UDP trackers, regardless of your connection mode, so the issue must depend on something else. In some cases it is good. For example (from your signature) with an Atom 230 it is quite good. Kind regards

Hello! What happens if you run a different BitTorrent software? Which server(s) are you experiencing the problem in? Kind regards

Hello! You claim "no traffic shaping" but the results you published point to the opposite direction. They strongly and clearly suggest MASSIVE traffic shaping from FastWeb. And the fact that you get higher performance with OpenVPN over SSL than with UDP direct is paramount. OpenVPN over SSL has nothing to do with UDP trackers. UDP is encapsulated as usual in the OpenVPN payload (so you have UDP over TCP over TCP). Kind regards

Thank you. We have been investigating this, it looks like a bug in Eddie, unfortunately we have been unable to reproduce the problem so far. Did anybody else see this "Tunnel not ready, interface status: Down" error message (it is a message coded in Eddie, not in OpenVPN)? If so, under which OS did it occur? Kind regards

Hello! OpenVPN will try to do that by default, assuming that reconnection to the Internet is successful at the wake-up. You should check what happens to Internet connectivity when you wake up your computer. Kind regards

Hello! Assuming that there's no traffic shaping or any other discrimination against UDP or OpenVPN itself, the most efficient mode is OpenVPN direct in UDP for sure. Kind regards

https://adium.im/ Jabber ID: @xmpp.airvpn.org Password: In Privacy remember to choose Encryption: Force encryption and refuse plaintext

Overview We host a XMPP (Jabber) server, with A-A security rating. We recommend to use only OTR compatible client. It's available for free to every member of this website. This forum is open to already available or new guides, tutorials or discussions (even about XEP). Recommended client OS X: Adium Windows, Linux: Pidgin Android: Xabber

https://www.pidgin.im/ Accounts -> Manage Accounts -> Add... Under Basic: Protocol: XMPP Username: Domain: xmpp.airvpn.org Resource: Password: Under Advanced ensure that Connection security is set to Require encryption.

Android XMPP (Jabber) client with OTR http://www.xabber.org/ Menu -> Settings -> XMPP accounts -> Add account Account type: XMPP Username: @xmpp.airvpn.org Password: Chat through TOR anonymity network and force TLS cryptographic protocol: if you wish so. By default it uses TLS if enabled. Click the created account, search TLS/SSL usage and force Require TLS.

Hello! As we announced repeatedly, there will be no kill switch on Eddie, because forced applications killing is not a safe method for several reasons. On the contrary, there will be a total leaks prevention, to prevent for example packets leaks in case of unexpected VPN disconnection. Eddie 2.5 will include this feature and will be released (unless unforeseen problems come out) during the first half of September (and probably it will be also promoted to "stable", no more beta). Kind regards

Hello! You understood everything correctly, AND the DNS record update was broken, thus "nl.vpn.airdns.org" always resolved to Propus entry-IP address, regardless of the "best" server rating calculated by the system, causing an overwhelming congestion to Propus yesterday. The issue has been fixed several hours ago and situation is quickly reverting back to normality. Note that this system has been implemented more than one year ago and this is the first serious malfunction. Kind regards

Hello! We confirm it. In the last hours we have solved the problem with OpenVPN over SSL in 25 servers. If you find anything wrong, please feel free to report the name of the server not accepting OpenVPN over SSL connections. Kind regards

Hello! Our certificates were not valid in 1899 so you will not be able to connect to any VPN server. Kind regards

Hello, since April 2014 you can connect simultaneously three devices from the same account to different VPN servers. Kind regards

Hello! We deny such issue. DNS servers have been working and are working just fine. @doodoo888 Please note that you're publishing invalid IP addresses. The addresses you published miss an octet. Kind regards