Staff

Hello! The problem is not related to the Comodo general rules published in our guide to prevent any leak. The problem arises when it is necessary to connect over OpenVPN over TOR, in which case you need to authorize TCP packets to outbound port 443 (otherwise TOR can't work). In this case, if the VPN connection drops AND you're using a browser to connect to an https web site, Comodo will not prevent a new connection to that site. Kind regards

Hello! We're sorry, we don't accept physical cash in mail. If you pay with PayPal yes, we can correlate that an account has been activated through a PayPal payment (this is essential for PayPal refunds). The information is stored by PayPal itself (just like in any transaction of any other financial institution or bank does) both in the customer PayPal account and in our accounts. Neither the customer nor us can delete that information. On the contrary if you pay with Liberty Reserve or Bitcoin there is no correlation between the account and the payment. Kind regards

Hello! As clarified in the very same thread you linked, that's totally false. Either you provide the piece of code which, according to you, is a security threat, or you stop at once making such nasty insinuations. The new OpenVPN 2.3.0 solves many issues with Windows drivers and includes some new features which are useful. The stable version has been peer reviewed and such threat has not been found, as well as no other vulnerability. The source code is open so you can check yourself. As usual, you can use any OpenVPN version you like since 2.1.3 or higher. Your message is questionable because it contains a false statement, not our security policy habit. Please prove your claim as soon as possible providing the piece of code or a clear description of a successful attack according to which you can prove the presence of your alleged backdoor or your message will be categorized as FUD and also as defamatory against OpenVPN community and against our team. Regards

Hello! Correct, you can set 10.4.0.1 as primary (preferred) DNS and 10.5.0.1 as secondary (alternate) DNS on your physical network interface. In this case you must be aware that, when disconnected from the VPN, you system will not be able to send out DNS queries, so you should enter the following lines in your hosts file to allow connection to our VPN servers (only if you use the Air client, because it needs to contact airvpn.org): 85.17.207.151 airvpn.org 212.117.180.25 airvpn.org On most default Windows installations the hosts file is in the following directory: C:\Windows\system32\drivers\etc Kind regards

Hello! Customer service for Premium members usually responds in a few minutes or a few hours, according to the complexity of the problem. Responses to non-customers regarding questions that are already answered in the FAQ or that do not make sense can take longer or can never be sent. Kind regards

That was the first thing I tried but my dns was still leaking. Hello! That's impossible, which DNS IP addresses did you set? Ok, that's another good solution. You might like to prevent any leak (especially leaks in case of unexpected VPN disconnection) with your firewall (see our guide for Comodo, the most reliable firewall for Windows): https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 All these information are reported in the welcome e-mail which is sent automatically at each new subscription and also in the FAQ, please feel free to inform us if you found something unclear in the FAQ and/or in the welcome e-mail. Kind regards

Hello! You can publish the link and/or the site name if you wish. Prohibition of advertisements does not include helpful and informative links. Kind regards

Hello! You don't need to open any inbound port on your system to access our service (why did you think so...?). On the contrary it may be good that those ports are closed. Can you please try with both your firewall and antivirus disabled? Can you please send us your client logs? Kind regards

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