Staff

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

Hello! Can you please send us the total set of your Comodo rules on the machine that has issues? Does something change if you set Comodo firewall security to "Disabled"? Kind regards

Hello! Kernel routing table and network interfaces look ok. You can launch "sudo openvpn" with the --log-append directive to store the logs where you wish. Can you please also send us the content of your /etc/resolv.conf ? Kind regards

Hello! We don't detect this problem on Sirius. Which port do you connect to? Can you please send us the logs, the network cards DNS (if you're on Windows) and the routing table, and check whether there's any difference with other servers? Kind regards

Hello! Yes, the same thing. The difference between "downloading" and "viewing" YouTube video is a big lie, maybe prefabricated by deranged copyright fundamentalists OR, on the contrary, to please them. In order to support the lie, all kind of stuff is in place in an attempt to prevent videos downloads after you have downloaded them. In general it's not possible to discern that. The video file is sent anyway. Retrieving it from your cache or copying it while it's coming down are activities not related to the network. Kind regards

Hello! They have no legal value, nothing changes from what already written. The difference is that they are not take down notices in the strict sense, they are an attempt to steal money via a private settlement. According to how the data have been collected, those notices may also configure a criminal infringement performed by the data collector and eventually by the ISP, if it gave away the personal data of a customer to the claimant in the absence of a magistrate order. For their nature, those notices are aimed to private citizens, in the hope to scare them and make them pay, and are totally irrelevant for mere conduits. Kind regards

Hello! Absolutely normal. Comodo will not define new network zones if an IP address already belongs to a network zone. Ideally, you might have one single network zone for the VPN, with IP range [10.4.0.0 - 10.9.255.255] if you don't want Comodo defines a new network zone for each VPN IP address which is found outside previous network zones. In this way you can keep your Comodo network zones much cleaner, but pay attention if you connect to another network in the same network zone, you might not want the same behavior you have for AirVPN, especially if you are in a public hot-spot subnet. This happens and it's totally normal because our network zone, for each port, have a 255.255.0.0 mask, therefore allowing 65534 different possible IP addresses for clients on each port, while Comodo can't know it, and defines a new zone with a netmask 255.255.255.252. So if your device is DHCP-assigned an IP, say, 10.4.0.45, and the next time (on the same 443 UDP) port) the assigned IP is, for example, 10.4.1.100, Comodo will define a new zone for it, while if you are assigned, say, 10.4.0.46, Comodo has already that network zone defined, no need to create a new one. See also https://airvpn.org/specs Kind regards

Hello! Castor will come back for sure! Kind regards

Hello! Thank you. Just checked YouTube from Leporis and unfortunately you're right, while the access to the website works, the video download is inhibited. It may be an IP problem, yes. Leporis is very young, so chances are that it has been assigned an exit-IP address which caused abuses from the previous "owner". We'll look further into it and investigate YouTube policies to see whether it is possible to apply for IP-block removal. Kind regards

Hello! About EU servers, there is of course neither USA jurisdiction nor USA applicable law. About USA servers, this is a matter exclusively between us and our provider, or between us and the claimant, in no stage our customers are involved. DMCA notices with regard to p2p are allegations from private entities based on non-specified monitoring techniques, so in the worst case they will cause tension between us and our provider and in a worst-worst scenario cancellation of connectivity for our server. This may be not uncommon given the fear that trolls, clowns, fundamentalists and other copyright monstrous parasite creatures strike into some hosting/housing providers, but all in all it's a part of our job. You might like to read this if you are interested in USA DMCA procedures: http://dmca.cs.washington.edu/ Kind regards

Hello! Can you please send us the connection logs and your Comodo rules? It was fixed. If you still have issues they are most probably on the client side. The logs will help troubleshooting. Kind regards

Hello! The Windows client uses the very same Cygnus entry-IP address. 37.220.11.106 is the entry-IP, 107 is the exit-IP. So your configuration is correct. First of all, please check the client certificate field, just in case the initial blank line which is visible in the screenshot creates issues. Also, try to disable LZO compression and modify the MTU size. Start with 1560 then go down to 1500, 1400, 1300, 1200. For each value please re-test the connection with and without LZO compression. Finally please enable and send us the logs, they may be very useful for troubleshooting. Kind regards

Hello! No, there's no law forcing that. Not even for ISPs. Wikipedia is just right about it: http://en.wikipedia.org/wiki/Telecommunications_data_retention#United_States VPN services that retain users' connection logs or any other data in the USA do it for their own choice, not because they are obliged to. Kind regards