Staff

Hello and thank you! We're glad to hear that the problems is fixed. Please do not hesitate to contact us for any further information. Kind regards

thigger wrote: Again, correct! Just in case, any second guess? Congratulations! We couldn't think of an obvious second attack - the rewritten header is encrypted until it reaches the AirVPN user so shouldn't be vulnerable en-route; the only places to see the header rewritten but unencrypted are at AirVPN (but you guys have access to the un-rewritten header too) and on the AirVPN user's machine - so we figured the only person losing information by the rewriting is the AirVPN user. I think that's why we found it confusing - we'd assumed any changes were to protect the anonymity of AirVPN users rather than the anonymity of TOR or other users connecting to a service run by an AirVPN user! Hello! That's also important, since "other users connecting to a service run by an AirVPN user" might be AirVPN users too. Furthermore, some Air users might be malicious users. Anyway, there are further considerations. The packets with final destination the entry-IP server address a client is connected to are sent outside the encrypted tunnel. This is a correct behaviour; however, when the entry and the exit-IP are the same, in the event in which two or more users are connected to the same VPN server and try to exchange data between their services (maybe even unaware of that), one of them or both would send out unencrypted packets. A not uncommon situation is a p2p environment, in which the VPN server IP address and the port forwarded by the client are inserted in the DHT table and/or in a tracker peerlist. The torrent client of some (other or the same) VPN user sharing the file identified by the same torrent or magnet link would see that IP address:port as a good IP address:port to try a connection to, and would perform at least one connection attempt which would be routed outside the tunnel (if the user's firewall is not properly configured to prevent that). Our servers (and hopefully any server of any VPN service which offers remote port forwarding) always dropped those packets for security, otherwise a copyright troll could just subscribe to the service and start seeding something apparently tasty to disclose the real IP address of the VPN users who did not set properly their firewall. However, this is not a completely satisfactory solution, because a malicious entity which wiretaps locally the connections of a user could realize that he/she is using a certain protocol. Not a relevant information, but you never know when you deal with repressive regimes. Furthermore, some rotten ISPs perform bandwidth caps against p2p: in this case a single packet outside the tunnel might trigger the cap for seconds or even minutes. With separate entry and exit-IP addresses, we solve simultaneously both this issue and the issue you noticed, without requiring our users any additional firewall rule and with no need to renounce to remote port forwarding. Thank you from the techies! Kind regards

CatsAreGods wrote: Hello! We have checked that your account is authorized to access all the servers. In the moment of this writing, your account is connected properly to one of the VPN servers: is the problem solved? About the helpdesk, we don't detect any problem with Chrome. Your ticket on the Helpdesk has been submitted and received properly. We're looking forward to hearing from you. Kind regards

thigger wrote: Hello! Don't worry, security through obscurity is a very dangerous path, so we try to avoid it. A little bit unclear... if you refer to a packet coming "from the Internet" with destination the exit-IP of a VPN server, it is not (necessarily) encrypted, it depends on how and by whom that packet was sent. If a client of ours sends a packet to the exit-IP of a VPN server (for example a client with a service which listens and replies), it is encrypted on the client side together with the payload before it gets out of the client machine. The unencrypted new header will have, as destination, the entry-IP of that VPN server. Yes, that's right. Again, correct! Just in case, any second guess? Congratulations! Kind regards

blknit wrote: Hello! Excellent! It was our problem on SNAT. While Windows and Max OSX appear to accept to send replies inside the tunnel to incoming connections (TCP) from the entry-IP address of VPN servers (further investigations on this are in progress, since this does not appear a "good" behaviour, because it seems to override on the client side the push route commands sent by our server), Linux does not. Therefore listening services (behind our servers) based on Win and Mac worked. These facts put us on the wrong track, pointing us to a client side problem, while it was not, and causing the huge delay in solving the problem. Now incoming connections packets arrive from the exit-IP of the servers, solving the root of the problem. Linux behaviour is the "correct" behaviour, in the sense that it fully complies to OpenVPN directives and commands sent from our servers. Please do not hesitate to contact us for any further information. Kind regards

epoair wrote: Hello! Contrarily to most VPN providers, we guarantee a minimum allocated bandwidth for each customer and we provide a real time monitor of the servers to check the available bandwidth on each of them. The speed you reach with BitTorrent is ok (12.5 Mbit/s you reported on the previous message), while speed with other protocols seems too low. Anyway the speedtest you reported on your first message with speedtest looks fine. First of all, to wipe out any doubt about torrent client leaks, please perform the test available at http://checkmytorrentip.com/ while you are connected to one of our servers. You can see the IP you are visible on the Internet looking at the central bottom box of our webpages. Check carefully that there's no IP leak: during the test, the site and the tracker must never see your real IP address, instead they must report the exit-IP address of the VPN server you're connected to (the IP address you see in our webpages after the connection is established). The test will take you just a couple of minutes. We're looking forward to hearing from you. Kind regards

thigger wrote: Hello! Yes, you're 100% right: forget the previous incorrect statement. And yes, a nice side effect of the setup is to make correlation attacks much more difficult. We'll also add in the FAQ your suggestion for uTorrent which can improve performance. Technically, we don't do masquerading (in the meaning of MASQUERADE in iptables), but DNAT and SNAT (which is a form of masquerading according to some older definitions; in some literature, dynamic NAT is also called masquerading). Thank you for your cooperation! Kind regards

triad575 wrote: Hello! We detected and fixed an issue with UDP packets. Now KAD works properly (just please be aware that, randomly, eMule says "Firewalled" even though it's not true). The problem lied in the source of the UDP packets when we added the exit-IP and entry-IP rules. They came from the entry-IP instead of the exit-IP, causing the answer packets by eMule to be routed outside the tunnel and be dropped. For all the details, see this tasty thread: https://airvpn.org/index.php?option=com_kunena&Itemid=55&func=view&catid=3&id=1276 Kind regards

thigger wrote: Hello! Problem detected and fixed on all servers. Now you'll see incoming packets from the exit-IP, not the entry-IP. In this way the UDP reply will be routed inside the tunnel (if the reply was routed to the entry-IP, it would go unencrypted outside the tunnel to the entry-IP, and then dropped by the VPN servers - this was the cause of the problem). We apologize for the inconvenience. Of course, you will still be able to see real IP sources and destinations by capturing packets on the tun interface. Thank you for your cooperation and let us know if everything's fine now! Kind regards

thigger wrote: That's the case with all VPN connections - but what I was wondering about is the specific feature of AirVPN where incoming packets on the tun0 interface (not the underlying eth0 interface) are masqueraded to appear to be coming from the vpn entry ip as mentioned above: I've had a look into it, and it appeared my torrent client was rejecting incoming tcp connections because they had the same ip address as previous ones (and not getting any udp ones, but that's in my previous post). The solution for uTorrent was to enable 'bt.allow_same_ip' in the advanced preferences; then you can see multiple incoming connections - all appearing to have the ip of the vpn server's entry point. Hello again! That does not appear normal at all. uTorrent should be working swiftly with bt.allow_same_ip set to "false". On the other hand, a web server could not work if the encrypted packets header were overwritten with the VPN server address, because the webserver would not know to which IP address to answer (while your web server behind AirVPN works fine even on Sirius, right?). Is it possible that your uTorrent tries to listen to your ethernet or wireless adapter, trying to bypass the tun interface on the incoming connections? Can you please do packet capture on your TUN/TAP interface to verify whether the packets come from the correct IP address (you should see packets coming from addressess different of the VPN IP addresses). Kind regards

thigger wrote: Hello and thanks! Ok, so we are going to investigate about case 1. We'll keep you posted! Kind regards

epoair wrote: Hello! No, Bittorrent clients are not able to bypass the TUN/TAP interface with their default configuration. uTorrent might try to do that with various systems (which can be disabled, like uTP), but all our tests have showed that it does not succeed. In a non-throttled, ideal environment, and on big swarms rich of seeds, you should normally have better performance with p2p than any other protocol. Better performance and higher efficiency are of course among the strongest features of BitTorrent. Anyway, for additional security, please perform a check on this website: http://checkmytorrentip.com/ You should carefully check that your real IP address is never leaked during the test. We're looking forward to hearing from you. Kind regards

thigger wrote: Hello! Thank you for the warning. Remote forwarding is enabled both for TCP and UDP ports. You should be able to see that TCP packets for your web server have the correct header when they reach it (confirmed by the correct web server answers). We'll anyway look into this. Which server are you connected to? Can you please elaborate about UDP packets? UDP is a connectionless protocol, and http and https are not expected to be run over UDP, so why should your web server receive UDP packets? We're looking forward to hearing from you. Kind regards

thigger wrote: Hello! Sorry, this question remained unanswered in the previous message. Torrent clients and any other listening service are not getting multiple connections from the same IP address, they see the real origin IP address. When you see packets coming from one of our VPN servers, the "original" header is encrypted together with the payload (otherwise your ISP could see the real origin with DPI). That's why you observe all packets coming from the entry-IP address of the VPN server you're connected to. The packets are decrypted by your OpenVPN before they arrive to the listening service. You can easily verify by monitoring the traffic on your TUN/TAP interface, instead of your Ethernet or wireless interface. An excellent tool to do that is Wireshark. Kind regards

Hello! Yes, it's normal. You connect to a VPN server IP address (entry-IP) and you are visible on the Internet with another IP address (the exit-IP of the same server). It is not mandatory for OpenVPN (or any VPN in general) to have its clients connected to an IP address and get out with another (i.e entry-IP and exit-IP may be the same, as it happens in almost every VPN service), anyway this is an addition, completely transparent for clients, that we have made few months ago to enhance the anonymity layer (it makes correlation attacks harder and has the benefit to avoid out-of-the-tunnel unencrypted transmissions between two clients connected to the same server which communicate to each other). NAT and masquerading do all the job, so that your listening services (web server, torrent client...) are reachable from the outside (on the forwarded port(s)) and can respond properly to the incoming packets. When you receive an incoming TCP connection, you should see a packet directed to your TUN IP address (assigned by the VPN DHCP - see also https://airvpn.org/index.php?option=com_content&view=article&id=74&Itemid=141). Just a question, why do you say that you see connections coming from an address "similar to the entry-IP"? The incoming connections to your TUN interface should come from the entry-IP address. For example, on Lyra, you should see TCP IN of the type 62.x.x.85:-->10.x.x.x: (you can see your exit-IP just watching at the address reported in the bottom central box of our website while you are connected to a VPN server). Do not hesitate to contact us for any further information. Kind regards

Kitnick wrote: Hello! Very well! Please do not hesitate to contact us for any further information. Kind regards

Hello! The logs look ok, perhaps there's too much lag between our german server and the TOR relay. Try changing server. Also, can you please test a connection over an external http-proxy? See this thread for details: https://airvpn.org/index.php?option=com_kunena&Itemid=55&func=view&catid=3&id=1256 Kind regards

Hello! Yes, Air over TOR has been successfully tested repeatedly. Please make sure that you use a TCP port for connection to an AirVPN server (check the line "proto tcp" in the configuration file). Can you please send us the logs of failed connection attempts? Kind regards

@Kitnick Ok, support from now on transferred to e-mail. You'll receive a reply soon. Kind regards [EDIT] Please note that the problem has been detected from your log files. Unfortunately you gave an invalid e-mail address, so we can't send you via e-mail the solution. We paste it here: The first part of the log shows an "AUTH_FAILED" problem (maybe the connection was too lagged, it may happen with an http proxy) which anyway is solved in the second connection attempt displayed on the log. The second part is significant because it shows a failure in the "route.exe add" Windows command. If the command fails, like it happened, your traffic can't be routed inside the encrypted tunnel (you can see the failure on all the lines reporting "route addition failed [...] accessis denied"). FlushIPNetTable failed as well for the same reason. Under Windows, this problem usually is caused by a lack of privileges for OpenVPN. Please make sure that you launch OpenVPN with administrator privileges (so that it can modify the route) and also that OpenVPN was properly installed (the installer must be launched with administrator privileges too). Finally, please check that the TUN/TAP adapter has been properly installed (Windows might complain about unsigned drivers). Kind regards

@daicec Hello! You are not authorized to access the VPN servers. You need a premium subscription: https://airvpn.org/index.php?option=com_content&view=article&id=70&Itemid=132 We also accept Bitcoin: http://bitcoincodes.com/index.php?unit=store&op=browse&cat=10 and Liberty Reserve (please contact us for LR payments). Kind regards

@kitnick Hello! Attempt #3 failed because you specified a proxy which was not running (127.0.0.1:8118). Attemp #4 and #5 failed because of misplacement of user.crt, user.key and ca.crt files. When you put them in a different folder you have to specify the path on the corresponding .ovpn configuration file. Our configuration generator creates an .ovpn file which expects to find those files in the same directory you put the air.ovpn file itself. Attempt #6 failed because you specified a proxy which was not running (127.0.0.1:8080). Attempt #7 is ok. Our server sees you connecting from the http-proxy 78.133.146.136, while the proxy sees encrypted traffic from you directed to the VPN server, or coming from the VPN server and directed to you. You get out to the Internet with the VPN server exit-IP address. You can check this by browsing our website and watching at the address shown in the central box in the bottom part of the home page. Attempt #2 and #8 failed perhaps because of the http-proxy being down or too lagged. Now let's get a step back to see why Attempt #1 failed. Please try a connection only with the OpenVPN GUI (no TOR, no proxy) and please send us the complete logs. Please do not send an edited version, like the final part only. Then, try a connection with the AirVPN client alone (no proxy, no TOR, do not run OpenVPN GUI) and send again the logs (you can access the logs by right-clicking on the dock icon and selecting "Logs"; then you can copy them to the clipboard by clicking on the "Copy to clipboard" button in the middle of the bottom part of the logs window). We're looking forward to hearing from you. Kind regards

Kitnick wrote: Hello! First of all, can you please try a direct connection to one of our servers, just to see if it goes through without TOR? If it fails, please send us the logs of the attempted connection. If you can connect directly, when you wish to connect over TOR please make sure that when you have the "proxy" option enabled, you connect to a TCP port (you can pick the connection port by selecting the "Modes" tab in the Air client main window). If the above fails too, can you please try to connect directly with the OpenVPN client in order to determine whether it's a problem related to the Air client in your system? Just generate the appropriate configuration in the website with menu "Member"->"Connect without our client". Make sure to compile the "proxy" option, download the air.zip file, copy all the files inside it and paste them into the OpenVPN configuration directory (on Win 7 C:\Program Files (x86)\OpenVPN\config in a default installation). After you have launched OperaTOR (or any equivalent setup for TOR), run OpenVPN GUI, right-click on the dock icon and select "air"-->"Connect". Finally, the following is a currently working http proxy to perform connection tests without TOR: IP address 78.133.146.136 port 8080 Just insert in the air.ovpn configuration file the following line to make tests (do not launch OperaTOR, this is just a connection of AirVPN over http-proxy): http-proxy 78.133.146.136 8080 and make sure that you have the line proto tcp in the configuration file. We're looking forward to hearing from you. Kind regards

swami28 wrote: Hello! Can you please give us the exact error messages? What is your OS? Instructions for connection can be found in menu "More"-->"Access with...". Pick the appropriate entry according to your operative system. Looking forward to hearing from you. Kind regards

balthazett wrote: Hello! Thanks for the feedback. A few hours ago Sirius OpenVPN daemon on port 443 UDP suffered a problem. Therefore Sirius was reachable on ports 53 TCP/UDP, 80 TCP/UDP and 443 TCP, but not 443 UDP. Now it is fixed. Please do not hesitate to contact us for any further issue. Kind regards AirVPN admins

srajbr wrote: Hello! You need to subscribe a premium plan, please see https://airvpn.org/index.php?option=com_content&view=article&id=70&Itemid=132 Do not hesitate to contact us for any further information. Kind regards