Jump to content
Not connected, Your IP: 216.73.216.40

Staff

Staff
  • Content Count

    11483
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    2020

Everything posted by Staff

  1. Hello! Currently an outage in a high volume Leaseweb core network router may cause low bandwidth availability on Lyra and Leonis. We will keep you updated. UPDATE 15.23 CET+1 - Problems on Lyra and Leonis appear to be fixed. We are currently facing issues with Leporis (low bandwidth). UPDATE 15.32 CET+1 - High volume router crash is affecting Leporis, Leonis, Lyra. You may most probably notice low bw on these servers. UPDATE 15.35 CET+1 - High volume router stabilized. While redundancy is being restored, the problem should vanish. UPDATE 15.59 CET+1 - All problems are solved Kind regards
  2. Hello! Yes. Please check also that the DNS push from our VPN servers is successful, you should see the same 10.4.0.1 DNS server IP address on your TAP-Win32 adapter (Windows lacks the concept of global DNS servers, it needs that DNS servers are specified for each adapter). Kind regards
  3. Hello! Either you have a DNS leak (which is a privacy risk) or you're tunneling DNS queries to your ISP DNS (which is not worrying). About the first case, your computer can communicate to your router, so please check whether DNS queries are sent to your router IP address. Chances are that your router then queries your ISP DNS servers (obviously out of the tunnel), causing the leak. If it's the case, just replace your rule pertaining to your Home network in order to block packets toward port 53 UDP with 2 or 3 different rules: For example: Allow TCP In/Out From In [Your Home Network Zone] To In [Your Home Network Zone] Where Source Port Is Any And Destination Port Is Any Allow UDP In/Out From In [Your Home Network Zone] To In [Your Home Network Zone] Where Source Port Is Any And Destination Port Is Not 53 OPTIONAL, only if you need it: Allow ICMP In/Out From In [Your Home Network Zone] To In [Your Home Network Zone] Where ICMP Message Is Any Kind regards
  4. Hello! That's perfectly normal, it's how TCP works. Kind regards
  5. Hello! Please see the permanent links in the announcements section of the forum in order to secure your connection according to your OS. We provide instructions for Comodo (Windows), pf (*BSD, Mac OS X), ipfw (*BSD, Mac OS X), iptables (Linux). Kind regards
  6. Hello! Mail received and we confirm that Comodo configuration is all right. The Google DNS you see in the test are fine. You should never see your ISP DNS IP addresses. Should you see them again, further tests will be necessary. Kind regards
  7. Hello! Are you sure you're still connected when it happens? What is your OS? Can you please check whether it's a DNS problem? When the problem occurs, try to browse to: https://46.105.19.36 If you can reach our website, then (assuming you're still connected to a VPN server) it's probably a DNS problem, the causes of which will have to be investigated. Furthermore, is there anything helpful in the client logs? Can you please send them to us when the problem occurs? Kind regards
  8. Hello! We would recommend that you use our DNS, because after our internal resolution against censorship and for internal services, the queries will be sent to Google DNS anyway. In order to determine it please see here https://airvpn.org/specs Your system can send DNS queries to Google in two ways: directly, in which case they are going out unencrypted (and that's not good) or tunneled through our servers, in which case they go out in the encrypted tunnel, you will not be using our DNS but you won't have leaks anyway. In your specific case the test does not tell anything useful: you can't discern whether the detected Google DNS servers are reached by unencrypted queries, encrypted queries or through our DNS. Please note that our servers will always push DNS to clients. However a system can be forced to use another DNS and ignore the push (this might be your case). Kind regards
  9. Hello! The Global Rules showed in the provided link block DNS leaks. If your ISP DNS IP addresses appear in the leak test, either there's actually a leak (therefore some mistake in the rules or network zones), or your provider has public DNS and your device is forced to use them. In this case, the DNS queries are tunneled and your provider will see the queries coming from our VPN server, so the leak is not real. Please feel frees to end us your Global Rules and the definition of you Network Zones for a check. Kind regards
  10. Hello! OpenVPN can't access the TAP-Win32 adapter. Please make sure that it is enabled: On Windows XP: Open Control Panel-->Network and Internet connections-->Network Connections. Right-click on "TAP-Win32 Adapter V9" and select "Enable". Windows Vista: Open Control Panel-->Network and Internet-->Network and Sharing Center-->Manage network connections. Right-click "TAP-Win32 Adapter V9" and select Enable. Windows 7: Open Control Panel-->Network and Internet-->Network and Sharing Center-->Change Adapter Settings. Right-click on "TAP-Win32 Adapter V9" and select Enable. If you find that the TAP adapter is already enabled, select "Disable", apply the change, then select "Enable". Please feel free to let us know whether the above solves the problem. Kind regards
  11. Hello! If the problem occurs again, please feel free to send us the connection logs. As far as we understand you use the Air client, so in order to send us the logs please: - right click on the Air dock icon - select "Logs" - click on "Copy to clipboard" - paste here or where appropriate Kind regards
  12. Hello! According to uTorrent documentation, you should be able to reach the WebUI at the following address: http://Username:Password@<Air server exit-IP>:<port>/gui http://www.utorrent.com/help/guides/webui Kind regards
  13. Hello! We confirm that "speedtest.air" is reachable from Sirius (port 443 UDP). This is a strong hint suggesting that your router is not sending DNS queries to the VPN DNS IP address (see here https://airvpn.org/specs). Chances are that your router and/or the device from which you perform the test are forced to use different DNS servers. Can you please check? Also, you can also perform a DNS leak test for double-check: http://www.dnsleaktest.com Kind regards
  14. Hello! Can you please try again on Tauri at your convenience? Kind regards
  15. Hello! At least the quoted rule is wrong. Since your home network is in 10.0.1.0/24, you can't even simplify the allow rule with 10.0.0.0/8, because it would overlap authorizations for different networks (your home network and the Virtual Private Network). jessez did not foresee this particular case. The quickest solution is setting 6 different pass out rules to replace the above quoted rule: pass out quick inet from 10.4.0.0/16 to any flags S/SA keep state pass out quick inet from 10.5.0.0/16 to any flags S/SA keep state pass out quick inet from 10.6.0.0/16 to any flags S/SA keep state pass out quick inet from 10.7.0.0/16 to any flags S/SA keep state pass out quick inet from 10.8.0.0/16 to any flags S/SA keep state pass out quick inet from 10.9.0.0/16 to any flags S/SA keep state To understand why please see here: https://airvpn.org/specs Kind regards
  16. Hello! Can you please try a connection and send us the logs? Kind regards
  17. Hello! All servers are up and running. You can connect ONLY to Lyra? If so, can you please send us attempted connection logs to a couple of servers (for example Cassiopeia and Bootis, which are your highest priority)? Logs can be very helpful for troubleshooting. We're looking forward to hearing from you. Kind regards
  18. Hello! In the PC which fails the connection, OpenVPN is trying to connect over a proxy which is not responding. Either you don't need to connect over Air over a proxy, or your proxy is misconfigured. In the 1st case: please disable proxy connection on your Air client. In order to do so, please right-click the Air dock icon, select "Preferences" and set the Proxy Type combo box to "None". In the 2nd case: please make sure that your proxy is running AND listening to port 9050. If you tell us which proxy you're using, we might help you with that. We're looking forward to hearing from you. Kind regards
  19. Hello! No, your torrent clients don't have to use any proxy. Please do not hesitate to contact us for any further information. Kind regards
  20. Hello! Please see here https://airvpn.org/faq#p2p and do not hesitate to contact us if you have issues on any suggested step. Kind regards
  21. Hello! Did you insert login and password on the configuration file? If so, please remove them. The authentication is performed through double certificate and personal key. Please make sure that the configuration file points to the correct files (ca.crt is the server certificate, user.crt the client certificate and user.key the client key). Our configuration generator builds all the files according to your instructions (menu "Member Area"->"Access Without Our Client"). Kind regards
  22. Hello! You should check with their programmers. Anyway we observe that Skype is able to continue working without DNS resolution. Generally speaking no, because there are very many possible leaks which do not require DNS resolution. It can't be and should not be considered a secure solution. Kind regards
  23. Hello! Unfortunately not, in general that will prevent only DNS leaks, not every leak. You may have the impression that the Internet is totally inaccessible because your system can't resolve anymore domain names. However, all the programs which do need a DNS resolution (for example a torrent client) will start to exchange data, leaking the real IP address. Kind regards What about instant message programs such as Trillian and Skype? Hello! Exactly. Sorry for the typo, the sentence " all the programs which do need a DNS resolution (for example a torrent client) will start to exchange data, leaking the real IP address" must be read "all the programs which do NOT need a DNS resolution (for example a torrent client) will start to exchange data, leaking the real IP address" Original message edited to correct the typo. Kind regards
  24. Hello! Comparing this log with your previous logs, it's unclear why OpenVPN tries to modify the routing table with "ip route" etc. instead of "route". Do you need multiple routing tables? Assuming that your kernel supports policy routing (you run an Ubuntu distribution, right...?), please check group permissions: http://ubuntuforums.org/showthread.php?t=1867166 See in particular post number 5 by "Jonathan L". Kind regards
  25. Hello! OpenVPN can't access the TAP-Win32 interface and can't modify the routing table. Please make sure that: - you launch OpenVPN GUI with administrator privileges - there are no other OpenVPN instances running - the TAP-Win32 adapter is enabled Kind regards
×
×
  • Create New...