Staff

Hello! Did you set any application rule? When Comodo evaluates the rules, for incoming connections the global rules take precedence over the application rules. For outgoing connections, on the contrary, application rules take the precedence on global rules. In the case of web browsers, they don't need an incoming connection, because they establish an outgoing TCP connection and communicate through the established socket. MISLEADING: the global rules will be evaluated anyway after the application rules. Please check that you don't have application rules, especially that Chrome is not a trusted application or is anyway authorized to establish outgoing connections. In case of any doubt, please do not hesitate to send us a screenshot of your application rules. EDIT: The recommendation is wrong, sorry. Although application rules take precedence over global rules for outgoing packets, this is an evaluation precedence only. No application rule can jump to "accept" before the global rules are also evaluated. So an outgoing connection must pass both the application rules and the global rules to be established. Therefore, this can't be the problem. Chances are that some other firewall or antivirus is interfering with Comodo. Kind regards

Hello! The 11% of Chrome (or any other application) is normal. All the applications will communicate with the outside, but passing through the tunnel, except OpenVPN. However, Comodo will correctly display the percentage on the total communications, on any network card. So that 11% refers to communications of Chrome to/from your TAP-Win32 card AND/OR to/from airvpn.org. Important: when you disconnect from the VPN your applications will be anyway authorized to communicate with airvpn.org (and with the VPN servers specified entry-IP addresses, of course), according to the global rules. This is to allow the Air client to connect. If you don't like this behavior, you can delete the allow rules for 46.105.19.36, and connect via OpenVPN directly or via the OpenVPN GUI, which don't need to contact airvpn.org. You can perform a quick check even without tools like Wireshark. Open the Comodo "View Active Connections" while you're connected to the VPN, and check that all the applications, except openvpn.exe, are connecting from 10.*.*.*. If some application is connecting from 192.168.*.* (assuming this is your home network zone) to the outside world, then there's something wrong. Then, disconnect the VPN and check that the only communications comply with the global rules. For example, try to open with Chrome any website except airvpn.org, you should be unable to reach it. We're looking forward to hearing from you. Kind regards

Hello! You need to copy the content of the zip archive. The ca.crt, user.crt and user.key files are always the same. "You can put more than one .ovpn or .conf file together with its key and/or certificate files into the ~/Library/Application Support/Tunnelblick/Configurations folder. Tunnelblick interprets each .ovpn or .conf file in the ~/Library/Application Support/Tunnelblick/Configurations folder as a configuration file for a different connection; each of the connections will be available in the drop down menu and shown as a separate tab in the "OpenVPN Log” window. " http://code.google.com/p/tunnelblick/wiki/UsingTunnelblick#Using_More_than_One_VPN_Connection Please do not hesitate to contact us for any further information. Kind regards

Hello! The global rules look fine, there are just some duplicates but they are inessential, for example the following three rules are the same according to your Network Zones configuration: Allow IP In/Out From IP In [10.4.0.0 -10.9.255.255] To MAC Any Where Protocol Is Any Allow IP In/Out From In [AirVPN] To MAC Any Where Protocol Is Any Allow IP In/Out From MAC Any To In [AirVPN] Where Protocol Is Any Anyway, this is not the cause of the problem. The blocks you can see in Comodo logs are ok. Please make sure that the Comodo firewall security policy is set to "Custom Policy" and that you don't have any other firewall running. Please close all your applications (close browsers, disconnect from VPN etc.), set Comodo to "Custom Policy", reconnect to the VPN, start normal Internet activity then disconnect from the VPN and check that you don't have anymore connectivity outside your local network. We're looking forward to hearing from you. Kind regards

@jasonc Hello! We have just checked that your account is authorized to access all the servers and we don't detect any problem with it. Please note that an account can connect only to one server at the same time. You can switch servers as many times as you wish, but you can't be connected to two or more servers simultaneously. Please do not hesitate to contact us for any further support. Kind regards

Hello! The Comodo logs show a block to the operating system in the DHCP "negotiation". Please make sure that you have the global Allow rule specified in step 11a: Allow IP In/Out From MAC Any To IP 255.255.255.255 Where Protocol Is Any and that your network areas are correctly defined according to the previous message. As a possible consequence, the TAP-Win32 interface does not come up, this is the reason for which you establish a tunnel but you don't tunnel anything inside it: no access to the TAP-Win32 interface is possible. If the TAP-Win32 still does not come up after the changes reported here above, please make sure that you launch the Air client with administrator privileges (it is set by default to be launched with those privileges, but you will have to authorize it if you have the default Win7 UAC active). If that does not solve the problem, you should uninstall OpenVPN. When you re-install it, make sure that you authorize it to install all the drivers it asks you for authorization. Kind regards

Hello! The [Loopback Zone] Network Zone is wrongly defined, it must be [127.0.0.1 / 255.0.0.0] The [AirVPN] Network Zone is wrongly defined, it must be IP range [10.4.0.0 - 10.9.255.255], or [10.0.0.0 / 255.0.0.0] The [Home Network] Network Zone is wrongly defined, it must be AT LEAST [192.168.0.0 / 255.255.255.0], however please check your DHCP server (your router probably). A safe definition may be [192.168.0.0 / 255.255.0.0] to cover 192.168.*.*. The [LAN] Network Zone will go to overlap with the [Home Network] Network Zone, so you can just delete the [LAN] Network Zone in order to avoid confusion and conflicts and be consistent with your global rules. When you have fixed the Network Zones, store the changes, please re-launch the Air client, re-connect to Cygnus, test the connection and if you have further problems please send us the Comodo logs and the Air logs. We're looking forward to hearing from you. Kind regards

Hello! That's bizarre, to say the least. Can you please publish the complete log? We'll look into the issue immediately. Kind regards

Hello! The Cygnus entry-IP address is 37.220.11.106. In order to connect to Cygnus please just modify the IP of the "Allow" rule from/to IP 37.220.11.107. Change the IP to 37.220.11.106. Whenever you have some problem of this kind, it's convenient to check the Comodo logs to see immediately where the block occurs. Assuming that the network zones have been defined correctly, all the other rules look just fine. You might like to modify the rule pertaining to the Loopback Zone in Allow IP In/Out From In [Loopback Zone] To In [Loopback Zone] Kind regards

Hello! Where do you get stuck with the Comodo guide (which step)? If you need to block ONLY your torrent client please see here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&Itemid=142#1715 Kind regards

Hello! Yes, we can't reproduce the problem in any way. Can you please send us a couple of complete failed connection log? Small pieces don't help at the moment. Have you tried connections to TCP ports? Since we suspect this is a client-side problem related to high latency, TCP might really help. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in the United Kingdom is available: Cassiopeia. The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Member Area"->"Access without our client"). The server accepts connections on port 53, 80 and 443 UDP and TCP. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN admins

Hello! Since you have disconnection issues with UDP, your connection may have a very high percentage of lost packets. TCP fixes the problem at the price of a full-error correction, so the packet you lose are sent again, introducing a big overhead. Maybe you can have a better connection with different servers? If you have problems with all the servers, then it's a problem with your ISP or with home lines. About MTU size, it's 1500. You can try lower values to test. If you notice, in your logs, "Replay backtrack window occurred" when you're connected via UDP, then that might be the problem. Kind regards

Hello! None of the logs you linked pertains to TCP connections, they both show Vega / 443 UDP connections. While the second linked log shows problem in your connectivity, the first log is just fine, it shows that you could stay connected for hours, from 10:45 AM till 2:09 PM (the TLS renegotiation is ok, it happens every hour for additional security, with overlapping windows in order to cause no delays or latency). So the problem appears to be inconstant. Can you please try a connection to a TCP port to make a comparison? Kind regards

Hello! At the moment we prefer not to publish them in the forum. You can obtain them all at once on the configuration generator, selecting all the servers. Kind regards

Hello! Thank you for the information. What happens if you use OpenVPN directly? Is there anybody else reading who is able to reproduce the problem with network-manager restarted? Kind regards

Hello! That's not fine... it is not a server side problem, as far as we can see, but a nm problem. If you restart nm, does the problem occur again? If you use OpenVPN directly, does the problem occur? We have tested Ubuntu with OpenVPN (launched with sudo) and the problem does not seem to occur, pointing to a client-side, possibly network-manager, issue. Kind regards

Hello! It can't control the DNS the computer uses, but it can control DNS leaks. The "trick" is writing correct rules for svchost.exe, which is the responsible for DNS queries (and many other things). However, we recommend to set a more comprehensive set of rules in order to prevent ANY leak, not only DNS leaks, see here for instructions: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 DNS leaks have nothing to do with static IP. The SOLUTION recommended on that site to DNS leaks involves setting a static INTERNAL NETWORK IP address, so that it does not vary according to the DHCP-push of your DHCP server (your router, for example). Again, it has nothing to do with static or dynamic IP assigned by your ISP. Go with Comodo, no doubts. It's a better, more practical and more secure solution. Kind regards

Hello! That's just fine. Please see here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3488&Itemid=142 Kind regards

Hello! We can't reproduce the problem (Debian 6, Debian 7, OpenVPN with root privileges). Can you specify your setup and send us the logs of the failed connections? Kind regards

Hello! With the Air client, you can select the connection port in the "Modes" tab. Kind regards

Thank you for the information! We did not change anything... perhaps Windows messed up the network and a reboot fixed the issue. Kind regards

Hello! If a disconnection occurs, OpenVPN re-establishes the previous routing table and tries immediately to perform a new connection. The fact that you have to reboot might suggest that you have some crash in your system, especially considering the fact that nothing in our servers pushed routes affects your local network (unless you have a conflicting network in 10.4.0.0 -> 10.9.255.255). Can you please send us the Air client logs? Also, it's worth trying a connection to a TCP port (if you did not try it yet) in order to check whether it mitigates the problem. Kind regards

Hello, in the first part of the log in pic4 there's a TLS key negotiation failure (check your network connectivity). The TLS negotiation timed out after 60 seconds. The second connection attempt, on the contrary, seemed successful, did you have Internet connectivity after that? Kind regards

@5o52xwmftthyuq2gmdy6 Hello! The resolv interfaces order is correct. The network-manager logs look fine, please just check that you are running OpenVPN in "client mode" (do you use the configuration file generated by our generator or did you modify it?) and that all the certificates are accessible. Our clients DO require server certificate verification and our servers verify client certificates (double-certificate verification with ca.crt and user.crt so that no MITM is possible). Does the problem occur on Sirius only or on every server? Kind regards