Staff

Hello! DNS leaks are a typical problem of Windows only, which has never had and still lacks the concept of global DNS. We will address the issue in the next release of the Air client (for those who wish to use it). Anyway our guides for Comodo prevents any leak, including DNS leaks. Alternatively (but only for DNS leaks, not other leaks) you can just set VPN DNS IP addresses in your physical network card. We prefer general solution which do not bind you to use any proprietary client like ours. Kind regards

Hello! The dock icon with two small screens belongs to OpenVPN GUI (a graphical user interface for OpenVPN). If you use the Air client, let's just leave it apart for the moment, you don't need it because the Air client is just another OpenVPN graphical 'wrapper' with additional commodities for our service. Normally you can't use simultaneously OpenVPN GUI and the Air client. In order to let us provide you proper support please do the following: - make sure that the OpenVPN GUI is not running (if it is, right-click on its dock icon and select "Exit") - run the Air client and start a connection just like you described in your message (log in, pick a server and click "Enter") - after a couple of minutes, right-click on the Air dock icon (a white cloud on a blue sky if connected, a white cloud on a gray sky if disconnected) and select "Logs" - a window will pop-up; you'll see at the bottom of the window the button "Copy to clipboard", click on it - paste on the forum, so that we can see the logs which can provide precious hints for troubleshooting Kind regards

Hello! Our servers will accept connections from any client based on OpenVPN version 2.1.3 or newer. Older versions might work but we have not tested them with our directives (all in all we're talking of at least 7 years old software). On Windows XP SP3 we would recommend to try OpenVPN 2.2.2 or the latest OpenVPN 2.3.0 which fixes a lot of issues and glitches with the tun/tap adapter driver. Old versions are available here: http://openvpn.net/index.php/open-source/downloads/471-old-releases.html Kind regards

Hello! A possible cause might be a packet filtering program in your system that wrongly identifies the UDP traffic flow from our VPN servers as an UDP attack. When you connect to an UDP port, your system receives exclusively UDP packets on your physical network card, regardless of the underlying "real" packet header which is still encrypted when arrives to your system physical network card. If you receive a lot of traffic, some misconfigured or excessively prudent packet filtering program might think of it as an UDP flood and start dropping packets. Kind regards

I am not using a router to do this. I am just doing configuration tricks on my PC. That was the point of my first post. I should point out here that I am confident that AirVPN has their IPTables (firewall) rules set up on each server to prevent any other user from connecting to my PC via the VPN, after connecting to the server themselves. Dose "admin" have any comment on this? In other words, I am am assuming that I can trust the server as I would trust a router, to provide an adequate firewall. If I start to fear that this trust is unwarranted, then I may also start using a router with OpenVPN on it. Hello! Yes, confirmed, no client can communicate with another client INSIDE the VPN. Some special notes: when you remotely forward a port, the server will forward packets directed to the : to your system local port, so it's up to you to check your security if you run services behind the VPN. By default NO ports are forwarded. Additionally, you can't be reached directly from the entry-IP address. Finally a side note, not very relevant in this context: we have a cone-NAT (p2p friendly) so be aware of programs which perform NAT punching, because we allow that. Kind regards

Hello! Apparently something is blocking outgoing OpenVPN packets. Please make sure that the new openvpn.exe you are running is not blocked by your firewall or any other program. Kind regards

Hello! Just run OpenVPN directly (no GUI, no wrapper) https://airvpn.org/linux If you access the server from a ssh, you might like to launch OpenVPN from a "screen" session. Kind regards

Hello! OpenVPN, offering (besides other features) exactly what you define a coding on layers 4-7, does protect you against DPI. DPI can only understand that you're using OpenVPN, nothing else. In order to prevent even that, we'll be launching OpenVPN over SSL and over SSH in the next weeks, so that DPI will identify your traffic as "SSL" or "SSH", not OpenVPN. Kind regards

Hello! The output shows that your connection is successful and your system correctly exchanges packets with our VPN servers. Also, your system is able to resolve names. Kind regards

Hello! No problems at all are showed by all the data you sent us. Try to set 10.4.0.1 as primary (preferred) DNS IP address in your physical network card. Leave the secondary (alternate) DNS IP to your favorite DNS in order to allow names resolution when disconnected from the VPN. Kind regards

Hello! Which Tunnelblick version and which OS X version are you running? Kind regards

Hello! Can you please send us, just after your system has connected to the VPN, your client connection logs and the output of the commands (issued from a command prompt): ping 10.4.0.1 tracert google.com tracert 8.8.8.8 Kind regards

Hello! Please send us your client logs (just after a connection to the VPN) at your convenience. What do you mean with "Google the IP address"? Kind regards

Hello! The explanation is basically correct if you can't dig into technical details. About her confusion, you should make clear that the OpenVPN connection ports have absolutely nothing to do with ports inside the virtual private network. Let her consider them as belonging to two completely different sets of ports in different networks. Going just slightly into more technicalities, OpenVPN encrypts and encapsulates all the traffic (so you can have all combinations such as UDP over TCP, TCP over UDP, UDP over UDP, TCP over TCP...). The real incoming/outgoing packet headers and payloads are still/already encrypted when they pass through her physical network interface. Her ISP will see only traffic to/from one IP and one port (again, a port which has nothing to do with the ports inside the virtual network), because the real underlying outgoing packet headers and payloads are encrypted by her client and decrypted by our servers, while incoming packets headers and payloads are encrypted by our servers and decrypted by her OpenVPN client AFTER they have passed through her computer physical interface. NAT is performed transparently by OpenVPN server and client through the tun adapter (a network interface used by OpenVPN). This gives the huge advantage to allow to use any higher-layer protocol over OpenVPN without having to configure programs. Kind regards

Hello! Yes. Yes: already established connections will not be tunneled. Make sure to launch the applications you want to be tunneled AFTER you have connected to the VPN. It is safer, yes, against potential attacks which try to correlate different activities of yours on the Internet and potentially creating a link between your real IP address and the VPN IP address. It can happen, it is not uncommon that ISPs have short-time black-outs and dynamic IP re-assignments. We have guides to prevent any leak in case of unexpected VPN disconnection. Kind regards

Hello! Usually that error is triggered by PayPal security systems which check your IP address, are you trying to perform the payment while connected to PayPal from a proxy, TOR, I2P or a VPN? Kind regards

Hello! There's no difference. To no program in particular, they are General Rules that will be evaluated for every and each packet. Our OpenVPN servers push default gateway and routes so that all the traffic in the device where the OpenVPN client runs will be tunneled. The rules are global, therefore they are evaluated for every and each packet. Kind regards

Hello! Maybe some program is blocking incoming packets for Vuze. Can you test with your firewall disabled? Check also any other program which might interfere (antivirus, PeerGuardian, PeerBlock...). Kind regards

Hello! Please bind Vuze only to eth9 (TAP-Windows Adapter V9), this will also prevent leaks in case of unexpected VPN disconnection. Kind regards

Hello! The port is correctly forwarded, both TCP and UDP, so the packets are forwarded to your system. Can you please check: - that the configured port in Vuze matches the remotely forwarded port - that Vuze has a bind to the correct interface (the tun adapter) Kind regards

Hello! Ok, now a port is forwarded, can you please test again? Kind regards

Hello! At the moment of this writing there are no forwarded ports for account "stkkts". Can you please forward a port, configure it in Vuze, and try again? Kind regards

Hello! Apparently everything is ok. Your home network Ip range does not seem to overlap with the VPN one (can you please confirm that it is 10.102.0.0/255.255.0.0 ?). Can you please send us also the output of the following commands (while connected to the VPN): tracert 10.4.0.1 tracert airvpn.org tracert google.com Kind regards

Hello! The logs are fine. After the connection is established, from a command prompt can you please issue the commands: ipconfig /all route print and send us the output? Kind regards

Hello! Yes, 10.4.0.1 is the correct DNS IP address pushed by our servers when you connect to port 443 UDP. See also https://airvpn.org/specs Setting a different DNS on your tun interface is ok (the DNS queries will be encrypted and tunneled), but you will not use Air DNS, so you will not access internal services (currently only http://speedtest.air ), you will not bypass ICE censorship and you will not be able to use our experimental service aimed to prevent geo-IP based discriminations (for example with our DNS you can use BBC iPlayer even from non-UK servers; or access CBS from non-US servers). Kind regards