Staff

Hello! No, it seems wrong. Consider that Comodo evaluates rules from top to bottom. So your first rule allows everything to/from anywhere. Kind regards

Hello! You need to right-click the Air client tray icon and select "Preferences". You'll see a "Proxy" section where you define the type of proxy (http or socks), proxy IP and port. Kind regards

Hello! You are of course free to pick any plan duration you like (3 days, 1 month, 3 months, 6 months, 1 year). Kind regards

Hello! Yes, it is right. They can know because the Bitcoin account code you deliver the payment to is unique. Bitcoin allows an infinite number of account codes per wallet. Kind regards

Hello, have you inquired your university network administrators about that? If you can't do that, can you please try OpenVPN over SSL for testing purposes? Performance will be lower, but it is a good test to discern whether it's the university network the one that disrupts OpenVPN or not. https://airvpn.org/ssl Kind regards

Hello, thank you! In the provided link you claim that Air has no API, in fact this is not true: https://airvpn.org/topic/9612-what-is-api/ Which functions would you need to speed up your script? Kind regards

Hello, your system resolves airvpn.org to a secondary frontend (probably you have edited your hosts file). It is fully working, but in your case you might like to try the primary frontend 95.211.138.143 Please also check that some antivirus or security program is not blocking airvpn.exe packets. Kind regards

Hello! It's superfluous, the function is already accomplished by "redirect-gateway def1" push. You can have that option disabled or enabled, it makes no difference. Kind regards

Hello! Your English is just fine. Yes, that's all. Not entirely, you need "...format=web..." and "...&service=disconnect" (i.e. without the ">" and " When you enter your actual api key, remember not to put the > and So: https://airvpn.org/api/?format=web&key=blabla&service=disconnect where blabla is your key. We understand the problem with explicit-exit-notify (please note that we can reproduce this issue on Windows only: on Linux there are no such problems; we do not have a rational explanation for that at the moment). The API can help you greatly when you hibernate or put to sleep your device. Alternatively you can connect on TCP (which does not need any exit notification), but you will get probably lower performance than UDP. Kind regards

Hello, the problem: Tue Nov 19 14:31:52 2013 UDPv4 link remote: [AF_INET]84.39.116.179:53 Tue Nov 19 14:31:52 2013 MANAGEMENT: >STATE:1384871512,WAIT,,, Tue Nov 19 14:32:52 2013 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) A possible explanation, assuming that nothing in your system is blocking OpenVPN UDP packets, is that your ISP (college) does it, or maybe hijacks packets to 53 UDP to its DNS servers (a shameful practice we detected on Vodafone). However, if the same configuration works with your iPod on the very same network, then it MUST be something in your system. Please try also connections to ports 80 TCP and 443 TCP. Kind regards

Hello! a) You can find the entry-IP address of a server by generating, with the Configuration Generator, the configuration for that server and looking (with any text editor) at the line "remote" of the .ovpn file. Or just ask us. The rules are ok both for UDP and TCP. Anyway, you might like to eliminate all that logging, it may be useless and also slow down the system. b ) Probably not. The rule: "allow log UDP to 255.255.255.255" should be "allow udp from any to 255.255.255.255". Even "allow ip from any to 255.255.255.255" is ok. The rule "allow log ip from 127.0.0.1 to any" is risky. It's safer something like "allow ip from 127.0.0.0/8 to 127.0.0.0/8" Additionally, you need to communicate with your internal network devices (at least with your router) so you should also add: "allow ip from 192.168.0.0/16 to 192.168.0.0/16" or maybe (it depends on your subnet) even a more restrictive "allow ip from 192.168.1.0/24 to 192.168.1.0/24" could be fine. However this rule will allow DNS queries to your router and that could lead to a sort of DNS leak if your router re-transmits the query to your ISP. In this case, block outbound port 53 in the subnet: "deny ip from 192.168.0.0/16 to 192.168.0.0/16 53 out" c) ip is Internet Protocol and includes TCP, UDP, ICMP etc. d) 192.168.0.0/16 "covers" the range starting from 192.168.0.0 and ending to 192.168.255.255, so you're just fine. e) Impossible to say in advance, you can't determine the entry node in the TOR network by default. One of the strong points of TOR is establishing different circuits. You're ok with the already mentioned rules, because if you connect OpenVPN over TOR, you want that the final destinations (of your physical network card packets, not of the packets in the tun adapter of course) are the entry-IP addresses of Air servers. Kind regards

Hello, the reported Tunnelblick vulnerability (affecting 3.2.8 and earlier versions) was quickly addressed already in Tunnelblick 3.3experimental, and has been ultimately fixed on Tunnelblick 3.3beta22 on 12-Sep-2012, i.e. just a few weeks after the notification. http://code.google.com/p/tunnelblick/wiki/RlsNotes About Viscosity, on the very same page which you provided the link of, it is written that Jason Donenfeld reported the vulnerability to the vendor on 11-Aug-2012 and the vendor corrected it on 30-Aug-2012. You should never run obsolete program versions: vulnerabilities are discovered every day and it's important to address them expeditiously. Also keep your OS X up to date (although Apple is sometimes slow in addressing vulnerabilities): dozens of vulnerabilities are discovered every month. The work of those who discover vulnerabilities and notify the programmers about vulnerabilities is invaluable. Kind regards

Hello, this connection drops for this timeout: 12/11/2013 - 11:23 AM read TCPv4_CLIENT: Connection timed out (WSAETIMEDOUT) (code=10060) 12/11/2013 - 11:23 AM Connection reset, restarting [-1] If you're connecting via WiFi, please try to get a stronger signal. If you are connecting via cable, there's not much you can try (apart making sure that the cable is not damaged). Kind regards

Hello, Tunnelblick is an OpenVPN wrapper but it does not support every OpenVPN feature. In particular it does not support connections over a proxy. Therefore you need to run OpenVPN without this wrapper in the middle. Please see here: https://airvpn.org/topic/9325-development-of-os-x-airvpn-client/ Kind regards

Hello, we have had a momentary problem for some minutes which caused the issue (only to the Air client), we deeply apologize for any inconvenience. Kind regards

Hello! If your client disconnects without notifying the server (for example because the connection is suddenly lost) and OpenVPN is on UDP, there's no way that the server can know that the client disconnected. Therefore, the system will "release" the client only after the timeout. When you click the "Disconnect Now" button, the system executes the command even if the page does not refresh. After you issue the forced disconnection command by clicking the button, please allow 10 seconds and then re-try a connection. We see that your account is currently connected and successfully exchanging data, so we presume that the problem was solved before this reply, is it correct? Kind regards

Hello! This is pasted from caduber's ticket, to readers' comfort: Hello! In most cases this problem is caused by wrong permission/ownerships in the system folders. Please run the Disk Repair Utility and perform a "Repair Permissions" on your boot drive, it should fix the issue. P.S. Please see also here http://bit.ly/1dfrWtg

Hello! That's correct: since there's an NL Netflix version, the re-routing to Netflix USA has been canceled on the NL servers, otherwise we would have rendered Netflix NL inaccessible. Kind regards

Hello! For OS X, as long as our client/OpenVPN graphical wrapper is not ready, direct OpenVPN usage is necessary to connect OpenVPN over a proxy. Which setup to pick depends on your needs. With OpenVPN over TOR our VPN servers can't see your real IP address and the TOR nodes can't see your traffic. Your system is visible on the Internet with the VPN server exit-IP address. Your ISP sees TOR traffic. With TOR over OpenVPN our VPN servers can't see your traffic. Your system is visible on the Internet with the TOR exit-node IP address. Your ISP sees OpenVPN traffic. Both solutions imply a significant performance hit. OpenVPN over TOR offers the option for additional hopping. For example you could run TOR in a Virtual Machine to have, in the VM, traffic over TOR (circuit 1) over OpenVPN over TOR (circuit 2). This solution will result in a formidably strong anonymity layer on the Internet, at the price of a critical performance hit. Kind regards

Hello! We're sorry, Tunnelblick does not support any OpenVPN connection over SSH/SSL or proxy. Kind regards

Hello, even that would be insufficient to remain anonymous if, in the action, you use an identity that can be exploited to reveal your real identity. Kind regards

Hello, it looks correct, anyway try not to remap to a different local port: try the same port everywhere. Kind regards

Have you considered malware or hijacks from within your system? Kind regards

Hello, the rules are correct, provided that your home network is in 192.168.0.0/16 (please check). Another rule should be added to allow DHCP, if you need it (probably so), you need to allow anything in UDP to IP 255.255.255.255 (to know why, please see how DHCP discovery works). Kind regards

Hello! One of our DNS servers run there, yes, as failover DNS. It's not a privacy risk, because DNS queries come from the VPN servers. Kind regards