Jump to content
Not connected, Your IP: 216.73.216.129
AirVPN

Staff

Staff
 View Profile  See their activity

  • Content Count

    11774

  • Joined

    ...

  • Last visited

    ...

  • Days Won

    2115

Everything posted by Staff

  1. Staff
    @huntergatherer Hello! Please send us at your convenience: - your network zones - your global rules - your application rules - Comodo Firewall events logs - the output of the command "ipconfig /all" (launch this from a command prompt) Kind regards
  2. Staff
    Hello! This will help you: http://openvpn.net/archive/openvpn-users/2004-11/msg00044.html Ping the entry-IP address of the server you wish to connect to in order to have a quicker approximation of the size you need to set with mssfix. Kind regartds
  3. Staff
    Hello! Excellent, thank you for the information. You can fine-tune the parameter trying to lower (or increase) it in small steps and test each time whether the performance improves or gets worse. Do not exceed 1500, of course. Our servers are configured with default OpenVPN MTU size in order to provide best performance with UDP in case of no or low packet loss/fragmentation. Probably a guide is necessary for clients which have fragmentation issues in order to mitigate the issue on the client side only, we'll be working on it (not difficult, the OpenVPN community wrote a lot about it). Kind regards
  4. Staff
    Hello! Some DNS servers listen to ports 53 UDP and port 53 TCP as well. If Windows sent out queries toward port 53 TCP, the above rules would not prevent DNS leaks and the TCP rule should be modified into "Allow TCP In/Out From In [Home Network] ... Where Destination Port Is Not 53". However, from Microsoft documentation this is not the case, queries are sent always toward 53 UDP. After step 3, Windows was resolving the names through the DNS Resolver Cache filled during step 1, 2, 3 (and possibly before). When you tried resolutions of names that were not in the resolver cache, your system was unable to send out a proper DNS query to the VPN DNS, or was unable to receive the reply from the server (did it happen with all servers?). In order to ascertain the reasons, you should check whether the OpenVPN server DNS push is accepted correctly by your client. If this does not help, monitor the DNS queries with Comodo. If you need deeper analysis, you can use Wireshark. Please note that in some OpenVPN releases there were some bugs pertaining to the TAP-Win32 Adapter which may cause this problem. The bugs affected only Windows and have been fixed with 2.2.2. Please note that if you upgraded to 2.2.2 but the installer failed to upgrade the adapter driver, you might still have issues. http://openvpn.net/index.php/open-source/documentation/change-log/425-changelog-for-openvpn-22.html Good workaround. It would be interesting to see what happens in your system if you force the VPN DNS on your physical card (for example 10.4.0.1 if you connect to 443 UDP, see https://airvpn.org/specs). Kind regards
  5. Staff
    Hello! Can you please make sure that in your hosts file you have the line 85.17.207.151 airvpn.org On a standard Windows installation the hosts file is located in the directory C:\Windows\system32\drivers\etc You can edit it with any text editor like NotePad. You need to launch the editor with administrator privileges. When you add the line, make sure to press ENTER at the end of it. Also, please check that your home network IP range is correct (if in doubt, you can safely expand it in the rules to [192.168.0.0 - 192.168.255.255]) Also, you might like to delete the rule Allow IP In/Out From In [192.168.1.1 - 192.168.255.254] To In [192.168.1.1 - 192.168.255.254] Where Protocol Is Any and replace it with the three rules reported in step 11 here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142#3405 in order to prevent possible DNS leaks. The other rules are just fine. Please feel free to report whether the above solves the problem. Kind regards
  6. Staff
    Hello! Thank you for your post. However, the quoted part is not correct. The recommended Comodo rules will prevent even in this case leaks, see step 11 on https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142#3405 The crucial rules are: Allow TCP In/Out From In [Home Network] To In [Home Network] Where Source Port Is Any And Destination Port Is Any Allow UDP In/Out From In [Home Network] To In [Home Network] Where Source Port Is Any And Destination Port Is Not 53 Allow ICMP In/Out From In [Home Network] To In [Home Network] Where ICMP Message Is Any Probably you have missed the editing of the post to include this case some time ago. EDIT: to avoid confusion, the original guide has been modified and the problematic rule has been deleted, because the three above rules can be applied anyway. Also, even without those rules, it's incorrect to state that "any DNS queries will go from your adapter (= your real IP) to the router". This will happen only when Windows "leaks", that is when it does not respect the routing table and its metric pushed by our servers, sending (or possibly duplicating) a DNS query outside the tunnel. Thank you again. Kind regards
  7. Staff

    Ipblock, etc

    Staff replied to a topic in General & Suggestions

    Hello! Some references: http://dmca.cs.washington.edu Kind regards
  8. Staff
    Hello! Yes, of course. In case of problems, you can also rely on switching Comodo back to "Safe Mode" or disable it completely. Also, the Firewall Event Logs are very useful for troubleshooting, in order to check whether Comodo is blocking something that you meant not to be blocked (just enable the logging for every block rule). If your DHCP server IP address coincides with all the DNS IP addresses configured/pushed for your computer physical network card(s) (you should check this both for primary and secondary DNS) and your DHCP server is your router then your computer will suffer no DNS leaks. We're sorry, we're not in the position to suggest an antivirus. The first thing you should check is the compatibility of an antivirus with Comodo. Some antivirus for Windows come in suites which might conflict with Comodo Defense+ and/or firewall. According to our experience we highly recommend both Comodo Firewall and Comodo Defense+ so it may be desirable to pick an antivirus that runs nicely with them. Comodo lets you run programs in a sandbox and Defense+ set to "Paranoid Mode" is a good defense for a Windows system. Comodo Antivirus obviously does not conflict, but we don't know anything about its effectiveness. Thank you! This forum is getting more and more interesting thanks to a fantastic community. Kind regards
  9. Staff
    Hello! So speedtest.air is correctly resolved and reachable, but the browser can't fetch it... can you please try also wget speedtest.air in order to see what happens to http requests inside the VPN... ...and outside: ping google.com ping 173.194.67.104 wget google.com Let's see the above http requests to determine if it's a problem related to the browser only (which browser is it? can you try another one?). We're looking forward to hearing from you. Kind regards
  10. Staff
    Hello! While you're connected to Virginis, can you please perform the following tests (from a shell) and send us the output of the commands? ping 10.4.0.1 ping speedtest.air Also, try to open speedtest.air with a browser. Additionally, can you please make sure that you have nothing that might block communications with Virginis from/to the tun0, such as LittleSnitch, some firewall rules... Kind regards
  11. Staff

    Staff replied to p3leceyfj's topic in General & Suggestions

    Hello! Linux-based systems are not affected by DNS leaks (as long as their OpenVPN client accepts the push from our OpenVPN server), since they have a global DNS. The "DNS leak" is a problem which normally torments only Windows systems which lack the concept of a global DNS. Anyway, you might like to secure your OpenVPN connection in Linux against any leak, including leaks in case of unexpected VPN disconnections: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&limit=6&limitstart=30&Itemid=142#2010 Kind regards
  12. Staff
    Hello! You have probably blocked communications with your DHCP server. If so, this method has another significant side effect besides the ones you noticed, which may be good or annoying according to your tastes, that is your computer will not be able to get any connectivity at the boot (it will not even be able to connect to your router), because it can't communicate with any DHCP server. If you don't like this, you can anyway set a suitable static IP address for your computer network adapter. Make sure that you pick it inside your home net IP range and that it does not overlap with any other address in the network. Generally speaking, be aware that this method does not necessarily prevent DNS leaks, so if you set a static IP and static DNS servers to render DHCP pushes superfluous, re-check carefully for these leaks while you're connected to the VPN. Yes, it is necessary because the Air client needs to resolve airvpn.org in order to handle the login, display the list of servers and download files before giving control to OpenVPN. But with the recommended Comodo rules we have blocked DNS queries outside the tunnel. And the tunnel is not yet existing. So we need to allow "airvpn.org" resolution internally, that is exactly the purpose of the hosts file on any system. Playing with the hosts file is not dangerous, as long as you know what you're doing. On the contrary it becomes an extremely dangerous issue if some malware is playing with your hosts file, because it can hijack your connections (you type a hostname, you think you are accessing a certain service or website, while in reality you're on a fake one). So having a look at the hosts file after all is beneficial, not dangerous. Kind regards
  13. Staff
    Hello! Try to force your router to use the VPN DNS as primary, for example 10.4.0.1 if it connects to 443 UDP https://airvpn.org/specs Kind regards
  14. Staff
    Hello! This is very puzzling, because you can connect and exchange data without problems on any other server, and Virginis configuration is just the same. Can you please tell us whether you see in the logs this very same line (near the DEBUG lines) when you connect to a server that works for you? *Tunnelblick client.up.tunnelblick.sh: ServerAddresses '10.4.0.1' ignored because ServerAddresses was set manually Kind regards
  15. Staff
    Hello! Glad to know that the problem is solved. Probably the XML was corrupt and the autofix procedure did not work properly for some reason. About the version, forget the question. The version is specified at the beginning of the logs that you correctly pasted, you are using 1.7 (currently the latest version). Kind regards
  16. Staff
    Hello! Probably you have not followed step 1. Guides and tutorials are already available. We have now added two links in our guide (see them in step 1) which point to official Comodo Help tutorials. They should take you just a couple of minutes each. There are approximately 368000 tutorials (including dozens of videos) on Comodo firewall currently available on the web. Probably just another tutorial would have the same significance of a tutorial on how to perform copy and paste on a computer. We are confident on the intelligence of our customers and users and we'll never treat them like idiots. In the fields of security and privacy it's definitely better to push someone into studying 5 minutes more than giving pre-packaged solutions which may be dangerous and give a false sense of security. If this approach is not appreciated (but at this point we can safely say quite the opposite), then the HMA and other VPNs disasters have taught nothing. Kind regards
  17. Staff
    Hello! Probably it's not related to Comodo. Anyway you can be sure of this by setting Comodo firewall and Defense+ to "Disabled". Try to delete the file C:\Users\Alex\AppData\Roaming\AirVPN\Air\1.0.0.0\AirVPN.xml (while the Air client is not running). The Air client will re-generate it at the next run (you will have to enter again your login). Are you using the latest Air client version (1.7)? Kind regards
  18. Staff
    Hello! You have enormous latency and probably packet loss, unfortunately. If it's not a hardware problem, then there are major peering issues between your ISP and all the servers you have tested. In order to see which bandwidth you can obtain with our servers with normal peering and no packet loss, please see the table "Top 10 Users Speed" on the right of the following page: https://airvpn.org/status Kind regards
  19. Staff
    Hello! That's fine, as it is just as expected from the logs (DNS push ok). We asked however for the "ipconfig /all" output (feel free to delete of course possible sensitive data), just to check the DNS of your physical adapter(s): if your system keeps refusing to send DNS queries to 10.4.0.1, you can force it by setting 10.4.0.1 as primary DNS in your physical interface. See also https://airvpn.org/specs Kind regards
  20. Staff
    Hello! Your system did not use the VPN server DNS: speedtest.air is resolved only by them. Can you please send us the output of "ipconfig /all" while your computer is connected to a VPN server? Kind regards
  21. Staff
    Hello! Although unlikely (since all the other servers work fine with your client) can you please check whether it's a DNS problem? http://code.google.com/p/tunnelblick/wiki/cConnectedBut#If_OpenVPN_is_connected_to_the_server_but_you_can%27t_access Kind regards
  22. Staff
    Hello! When you define that rule, in the "Destination Port" tab of the Network Control Rule just select "A Single Port", specify 53, and tick the "Exclude" box (i.e. the "NOT" Comodo operator). Please note that your real IP address must NOT be visible, regardless of Comodo usage or not, when you're connected to a VPN server. Please send us your client logs if you have this problem. Kind regards
  23. Staff
    Hello! You need to delete "route add -p 85.17.123.26 mask 255.255.255.255 192.168.67.2 metric 1" To achieve your purpose to prevent leaks in case of unexpected VPN disconnection and prevent any leak while connected, you may set up the appropriate firewall rules in your VM (assuming that it's in bridge mode). You may also consider to change the approach: connect your host machine to the VPN, connect the guest with NAT (instead of bridging). This will allow you to connect multiple VMs with just one Air account (used by the host). Finally, secure the connection with a firewall only on the host. Kind regards
  24. Staff
    Hello! Yes, that route addition allows OpenVPN client connection to Leonis but prevents any communication inside the VPN. Kind regards
  25. Staff
    Hello! The logs look just fine. Are the devices which connect to the router forced to use some particular DNS? EDIT: please also check this, just in case: http://www.dd-wrt.com/phpBB2/viewtopic.php?p=680573 Kind regards
×
×
  • Create New...