Jump to content
Not connected, Your IP: 216.73.216.62

Staff

Staff
  • Content Count

    11395
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1982

Everything posted by Staff

  1. Hello, Air is based on OpenVPN. Is OpenVPN included in the router firmware? Kind regards
  2. Hello, it does not seem a DNS issue: the connection to the VPN server, according to the logs you sent us in the ticket, is not established at all for a certificate error (OpenVPN exits with fatal error because it can't read a certificate). Can you please re-check certificates and key? Please make sure that there's no mismatch between ca.crt and user.crt.Also, can you please send us a screenshot of your pfsense OpenVPN configuration page? Kind regards
  3. Hello, the logs are just fine. Maybe it's a DNS issue. Can you please open a command prompt with administrator privileges, issue the following commands and send us the output? ipconfig /flushdns ping 10.4.0.1 tracert google.com ping 8.8.8.8 Kind regards
  4. Hello, Chrome by Google is not open source software. Google Chrome takes a lot of code from Chromium, an open source browser developed by the Chromium Project. Initially Chromium was a Google project, but now it's maintained exclusively by the community. There are some important differences between the two browsers, apart the fact that Chromium is free and open source, while Chrome is not (it's freeware). Please see also here http://en.wikipedia.org/wiki/Chromium_%28web_browser%29 Kind regards
  5. Hello! Please make sure that your internal network is in 192.168.0.0/16, then try to add the following rules: pass out quick inet from 192.168.0.0/16 to 192.168.0.0/16 pass out quick inet from any to 255.255.255.255 The first rule allows communications within your local network, the second rule enables DHCP discovery and negotiation. Kind regards
  6. Why is not forwarding ports in the router "very important"? It would actually seem to be benign. When a VPN has been established, it will just be an open port in the router that won't get traffic because the IP address is not visible to a swarm. So please explain. Thank you. Hello! If the torrent client has no bind to the tun interface and you forward on the router the very same port that the torrent client listens to (and therefore the same remotely forwarded port as well), an adversary can get a reply (from the torrent client) to packets sent to your real IP AND to the VPN public IP on that port. For an adversary with the ability to monitor/wiretap your Internet line, it becomes therefore trivial to time-correlate your p2p activity (or any service running behind a VPN server) and discover your activities on the p2p swarm (or anyway discover that the service running behind the VPN is YOUR service). Kind regards
  7. Hello, port forwarding has nothing to do with connecting to a Bittorrent tracker. The tracker is contacted by the torrent client via http or udp and obviously the operation does not need any port forwarding on the client side. Port forwarding is a way to make a service that's running on a client machine behind the VPN NAT reachable from the outside. Please see our FAQ answers for more information. Kind regards
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
×
×
  • Create New...