-
Content Count
11386 -
Joined
... -
Last visited
... -
Days Won
1978
Everything posted by Staff
-
ne-year membership is the only option now?
Staff replied to ander35's topic in Troubleshooting and Problems
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 -
ANSWERED payment with BTC via coupon from bitcoincodes.com
Staff replied to tammo's topic in Troubleshooting and Problems
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 -
Really strange issue with qBittorrent and AirVPN
Staff replied to Helios210's topic in Troubleshooting and Problems
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, 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
-
ANSWERED Just a (beginner!) question to API ...
Staff replied to tammo's topic in Troubleshooting and Problems
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
-
Block IP and DNS leaks - WaterRoof - *Rules not working
Staff replied to lambrinoul's topic in Troubleshooting and Problems
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 -
Viscosity or Tunnelblick security risk?
Staff replied to lambrinoul's topic in General & Suggestions
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 -
AirVPN keep disconnect and reconnect!!
Staff replied to weijie7's topic in Troubleshooting and Problems
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! 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
-
Running server behind complex setup...
Staff replied to Toops's topic in Troubleshooting and Problems
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
-
Block IP and DNS leaks - WaterRoof - *Rules not working
Staff replied to lambrinoul's topic in Troubleshooting and Problems
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
-
Hello, that was the problem we faced even before building up AirVPN. Without entering a debate about the confusion you make between security and anonymity, an adversary needs to control different networks and must have the ability to correlate traffic in order to crumble the anonymity layer. For example an adversary with the power to wiretap simultaneously your line AND the VPN server (the server, not the datacenter lines: in this case timing correlations become necessary and the task becomes overwhelming for every single client) you're connected to has this power. Mitigation is possible by picking servers outside your country and by rotating servers, but in order to defeat completely an adversary with such power (and even some higher powers) you need partition of trust: https://airvpn.org/topic/54-using-airvpn-over-tor/?do=findComment&comment=1745 Of course, if you mix identities, and one of these identities is your real identity or can anyway be exploited to reveal your real identity, no service and no technique and no partition of trust in this world can 100% protect you. Remember that a VPN protects your line, not your behavior. A very trivial example is using a VPN connection to log in Facebook with an account which is related (or has been related at least once in the past) to your real identity. Kind regards
-
Hello, very interesting for us and useful to Virgin customers as well as potential Virgin customers, thank you very much for your feedback. Kind regards