Staff

Hello! Can you please send us the Tunnelblick logs after the problem occurs? TCP and UDP are both supported and there's no significant difference between them under a security point of view. Please see also the FAQ https://airvpn.org/topic/9162-what-is-the-difference-between-tcp-and-udp-ports-which-port-should-i-choose Kind regards

This is what I do. And I thought I indicated this in the guide. Is it not clear? I will try to emphasize this when I next look at it. Hi, no problems, it's very clear! It was just re-stressed to suggest (not that it must be a good suggestion, it's just brainstorming) that maybe an ultra-quick solution (for Vuze inexperienced users only) that does not imply firewall settings and scripts could be welcome by someone who wishes to split traffic and secure the tunnel exclusively on a "torrent and non-torrent traffic" basis.However, the issue of tracker names resolution via DNS was overlooked, it was silently assumed that Vuze would work with DHT[+PEX], in a "trackerless mode". At a first glance and according to this writer, it is not a privacy/security concern. It is anyway to be considered, under a general point of view, that not using Air DNS servers will prevent usage of our anti-geo-location block system (for example to access Hulu from non-USA servers), which might be an inconvenience for those who rely on that, so it is good that the issue, for any possible case in which Air DNS servers are not used, is explicitly cited. Kind regards

Hello! Impressively detailed guide, rich of information on related topics, thank you! You might also like to include an alternative solution in part 2, much quicker, specific to Vuze (uTorrent lacks the bind to an interface option): insert "route-nopull" directive in the .ovpn configuration file (insert the line anywhere before the certificates and key)bind Vuze to the tun/tap adapter (menu "Tools"->"Options"->"Mode"->"Advanced"->"Connection->"Advanced connection settings" as showed in your screenshot) route-nopull tells the OpenVPN client to reject the routing table pushed by the OpenVPN server, while preserving the DHCP-push for the TUN/TAP adapter, making it ready to be "used" by applications bound to it. This solution has the advantage to take just a few seconds once and for all, it does not require scripts and firewall rules, but it has the disadvantage that it is applicable only with Vuze and that can't currently be achieved with the Air client for Windows. You'll need to use OpenVPN GUI or OpenVPN directly to connect to a VPN server with the "route-nopull" directive. The Configuration Generator has the ability to generate such configuration files. Kind regards

Hello! Please see also here: https://airvpn.org/topic/9487-the-underlying-connection-was-closed/ Kind regards

@g4life666 Hello, please send us at your convenience the commands you enter and their output. Kind regards

Hello! Run a command prompt with administrator privileges and type the command: notepad C:\Windows\system32\drivers\etc\hosts Edit the file, then save it. In case of any doubt, stop and send us the content of the hosts file (just copy from the notepad and paste here). Kind regards

Hello! Please check your hosts file. The entries of airvpn.org resolution must be either missing, or the following two: 95.211.138.143 airvpn.org 212.117.180.25 airvpn.org Make sure that no reference to 85.17.207.151 is there. Kind regards

Hello, first of all you should take note that the first three trackers you cite are no more working in http since a long ago, they only work in udp (for a very good reason). Actually, apart from the fact that using a tracker does not make any sense except for very special needs, there is not much sense in running an http tracker, due to efficiency reasons. We have checked the three trackers you reported as non-working in your first message right now (BUT in udp, of course) and we confirm they are perfectly reachable and working from Virginis. About "fr33dom" we don't know if it's still available in http, anyway an udp check was fully successful. It might be that the tracker is temporarily unavailable in http, or maybe it does not support http anymore, we don't know. The problem is therefore non-existent, we mark this thread solved but do not hesitate to contact us for any further information or issue. Kind regards

@Xiocus Hello, you need to setup a basic DNAT on your router (just a few additional iptables rules), please see here: https://airvpn.org/topic/9270-how-to-forward-ports-in-dd-wrt-tomato-with-iptables Kind regards

Hello, your account is currently connected to some Air server successfully, can you confirm it's all right? Kind regarss

Hello and thank you, GB2 is up and running as you correctly noted but the the routing is not working from several servers. We're investigating. Kind regards

Hello, first of all you can safely disregard the timer on the Air client, it has nothing to do with disconnections and does not affect the connection in any way. What do Shimo and OpenVPN logs say? Kind regards

Hello, just in case you'll need it in the future, you have to copy all the files and paste them in the OpenVPN configuration directory. At the subsequent OpenVPN GUI run they will show up as available connections when you right-click on the OpenVPN GUI dock icon. Remember to run OpenVPN GUI with administrator privileges. Kind regards

Hello, you might write a script to modify your routing table after the push from our server, so that traffic to some destination IP addresses will not be tunneled. However feel free to elaborate if we have misunderstood your needs. See here (for Windows, but the same applies to any OS with the due syntax modifications): https://airvpn.org/topic/3721-netflix/?do=findComment&comment=3724 Kind regards

Hello, no, don't worry. Torrent trackers are anyway useful for private services who need to quickly gather statistics and IP addresses (including copyright enforcement agencies - we remind you that such usage is strictly forbidden on our service according to the ToS), restrict the service according to seed/leech ratios, restrict the service to members and similar cases. Kind regards

Hi, why "partial"? Kind regards

Hello! Thank you for the information. We need to investigate and check. In the meantime enable DHT+PEX, you really don't need trackers. Kind regards

Hello, please use OpenVPN directly, OpenVPN GUI or any other OpenVPN wrapper while we investigate the issue. The files for those can be generated in "Client Area"->"Config generator". Kind regards

Hello, deletion of file C:\Users\XXXXX\Downloads\AirVpn\AirVPN.xml does not solve the problem? Kind regards

Hello! They show the current busy bandwidth for each server (updated every 60 seconds). 0% -> all bandwidth is free - 100% -> server is at capacity. Percentages above 100% show that the server "is bursting". Kind regards

Hello, problem solved with a new routing GB server, we could not wait for an inefficient provider. Kind regards

Hello! Can you please send us the Air client logs taken just after the problem occurs? Kind regards

Hello, the problem is shown here can you please check your Internet connectivity when that occurs? Kind regards

Hello, datacenter solved the problem on Pavonis. Useful tools to check the servers status are the Status page (click on "Status" on the upper menu) and the Ping Matrix (linked inside the Status page). Kind regards

Hello, the certificate SHA1 fingerprint you report 'from Sirius' is the airvpn.org certificate -expiring May-31-2013- fingerprint. The new SHA1 fingerprint, correctly reported by grc, is the fingerprint of the certificate expiring on May-31-2014. The old certificate is currently installed ONLY on our 'non-public' NL frontend. From Sirius DNS, and from any other AirVPN server DNS server, airvpn.org correctly resolves to 95.211.138.143, our primary and public frontend. Maybe you have multiple entries of airvpn.org (which is good!) in your hosts file which include the non-public frontend IP address. We will update the certificate in that non-public frontend within May-31-2013. Kind regards