Staff

Hello! We don't detect any problem with DNS. Can you please check the DNS push from Sirius on port UDP 443 and send us the output of "ipconfig /all" for the TAP-Win32 adapter? If the DNS push is successful, you should see the address 10.4.0.1 as DNS server of the adapter. If not, please check that the adapter accepts the push. Kind regards

Hello! We don't detect any problem with Sirius port 443 UDP. We have been testing the server and the port since the time of your writing. Previously and currently more than 60 OpenVPN clients have been finely exchanging data on it. Can you please check your routing table after the connection? Kind regards

@rbuilder Hello! Jinsong is right, probably your ISP shapes some or all UDP ports so you get better performance with TCP. This is becoming a common practice because these ISPs see UDP packet shaping a way to: - increase overselling without investing in infrastructures - hide anti-competitive practices to make their own content and service delivery to their customers more attractive than those of their competitors (VoIP, A/V streaming etc.) - test their customer base for acceptance of walled-gardens, a business model aimed to dismantle the open Internet. Apple huge success, which shows that majority of people will support enthusiastically a company that actively fights to dismantle the open Internet and open source software, this model is now very attractive. Kind regards

Hello! Given your peak bandwidth without VPN (300 kB/s), the performance you obtain is normal (assuming you mean kB/s, not kbit/s). Either your ISP always caps all ports or, more probably, it does not cap at all but is incapable to give you more than 300 kB/s down. Kind regards

Hello! After you have followed the instructions reported in the FAQ https://airvpn.org/faq to optimize p2p performance, please make sure that: - the listening port of your torrent client matches [one of] the port you have remotely forwarded from your control panel - the remotely forwarded port(s) are set to TCP & UDP and are not remapped to any local port - no firewall is blocking your torrent client on any network (this is important especially for Windows firewall: authorized applications in some networks may be not authorized to receive packets on other networks) Then "launch" a torrent and check whether you obtain a green token. If you have further issues, please send us information about the system you use, the configuration of your torrent client and the Air servers you connect to. Kind regards

Hello! OpenVPN handshake has a typical fingerprint, easily identifiable with DPI (it does not look like real SSL). We are preparing a system to mitigate this problem, stay tuned in the next weeks. Currently you have some systems (with Air) to evade a lot of controls: connecting to port 53 UDP (all Air OpenVPN servers accept connection on 53 UDP), or (in countries/ISPs which do not block TOR) connecting Air over TOR. Another system is connecting Air over any public socks or http proxy which is not blocked, this system is currently quite effective. Kind regards

Hello! Yes, such a query would be sent from your physical network card unencrypted and your ISP would know which resolutions you want to perform. A DNS leak, in our case, is an unencrypted DNS query which does not respect the routing table pushed by an OpenVPN server. Basically it happens on Windows system because every card can have its own, different DNS and svchost.exe runs with highest privileges, taking the unjustified freedom to send out DNS queries from any interface if the previous query from the correct interface does not receive an answer within a short time limit. Not at all. First, the encrypted DNS queries go out from your tun network card, which has a push to use the Air DNS. Second, even if you, in a momentary lapse of reason, forced the tun adapter to have your ISP DNS (we are talking only about Windows here, which is the only system which, for some reason, allows different DNS for different cards, which is the main source of all DNS leaks), and even if those queries could go out of the Air servers, and even if the ISP had completely open DNS (which is normally not the case), the ISP DNS would see the queries coming from our servers and would respond to our servers. Kind regards

Hello! If you use the Air client, after you have picked a server please select the "Modes" tab, pick a port and click "Enter". Please see the instructions for additional details. If you use OpenVPN directly or the OpenVPN GUI, please generate the appropriate configuration file with our configuration generator (menu "Member Area"->"Access without our client") and follow the instructions for OpenVPN for Windows. https://airvpn.org/windows Kind regards

Hello! A "lock" on bandwidth is a strong hint suggesting traffic shaping. If you notice a constant maximum bandwidth, chances are that the outbound port you're connected to is shaped by your ISP. Please try connections on different ports: 443 TCP, 80 TCP, 53 UDP to check. Kind regards

Hello! The Comodo global rules (not the application rules, of course) we recommend in order to prevent leaks do not block DNS queries from svchost.exe or from any other application. They prevent any packet to go outside your internal network, including therefore DNS queries, if and only if there is no connection to one of the Air servers. Nothing in the rules prevents to send out encrypted DNS queries in the tunnel by any application when the device is connected to an Air server. Please do not hesitate to contact us for any further information. Kind regards

Hello! From inside Castor: PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_req=1 ttl=51 time=16.5 ms 64 bytes from 8.8.8.8: icmp_req=2 ttl=51 time=16.7 ms 64 bytes from 8.8.8.8: icmp_req=3 ttl=51 time=16.8 ms 64 bytes from 8.8.8.8: icmp_req=4 ttl=51 time=16.8 ms 64 bytes from 8.8.8.8: icmp_req=5 ttl=51 time=16.8 ms 64 bytes from 8.8.8.8: icmp_req=6 ttl=51 time=17.0 ms 64 bytes from 8.8.8.8: icmp_req=7 ttl=51 time=16.8 ms 64 bytes from 8.8.8.8: icmp_req=8 ttl=51 time=17.6 ms 64 bytes from 8.8.8.8: icmp_req=9 ttl=51 time=17.0 ms 64 bytes from 8.8.8.8: icmp_req=10 ttl=51 time=17.0 ms 64 bytes from 8.8.8.8: icmp_req=11 ttl=51 time=17.9 ms 64 bytes from 8.8.8.8: icmp_req=12 ttl=51 time=16.7 ms 64 bytes from 8.8.8.8: icmp_req=13 ttl=51 time=16.7 ms 64 bytes from 8.8.8.8: icmp_req=14 ttl=51 time=16.8 ms which might hint at a problem somewhere between you and Castor, not between Castor and 8.8.8.8. Kind regards

@Someone Else Hello! Ignore the previous reply if you received it via e-mail (it did not take into consideration a different timezone). We'll further look into the issue. Kind regards

Hello! This is because you are still, really connected to the previous server. It has been possible to determine this with absolute certainty for a stroke of luck because we don't keep logs, however your account is still connected and exchanging successfully data to another server (we don't report it here for privacy). The connection to that other server began well before the time of the logs you report. So, assuming of course that you did not give your user.key to anyone, please check the disconnection procedure of your client, it seems that you think to be disconnected while in reality you are still connected. Kind regards

Hello! Speedtest can give you a relative index about which server to use, not an absolute one. Also, can you please repeat all the tests for port 443 TCP, 80 TCP and 53 UDP and publish the results, at your convenience? Thank you in advance. Kind regards

Hello! The recent attacks against the good old Draconis and the new Leporis are performed by some entity with good capacities (>3.5 Gbit/s flood, >50000 flows/s) and that also knows the entry-IP of our VPN servers (so they have been lurking in the website or subscribed to the service - not difficult for free trials, discussions in the forum etc.) . These attacks are outside the reach of most entities so we highly doubt they can be capable to bring down more than one server at a time, unless there's some very big entity behind them (very unlikely). Even in this case, the attackers were not able to sustain the attack for more than 20 minutes. Currently Leporis is ok, but we'll bring it back online at due time. And yes, Castor is back. Kind regards

Hello and thank you! So, Comodo was right since the beginning. You can see in a previous message that we detected that [AirVPN] Network Zone was wrong, and since then we assumed that you corrected it. Unfortunately you inserted a Netmask which covers almost the entire IPv4 range, authorizing your system to communicate with almost every single IP address on the Internet! The definition of the AirVPN Network Zone must be [10.4.0.0 - 10.9.255.255]. Please note the difference between "-" (IPv4 range) and "/" (CIDR NetMask). Once you have corrected the [AirVPN] Network Zone, apply the changes, bring back down the block rule below all the allow rules, re-perform the test with and without VPN. There could still be some problem, if it's the case do not hesitate to report again, we'll do our best to solve them. Kind regards

Hello! Great job! Can we see again the definition for your [AirVPN] Network Zone? Also, can you please send us the output of the command "ipconfig /all"? Kind regards

Hello! Leporis, although up and running, has suddenly lost connectivity with large parts of the Internet. We are investigating. UPDATE: Leporis is under a DDoS attack and the provider was rightly forced to null-route the targeted IP address. We will keep you posted. UPDATE: Leporis is up. Kind regards

Hello! No problems, of course you can test when you wish and when you have time. Now, there is a time-consuming test which you can perform if you wish to. Put on top only the allow rule: Allow TCP or UDP Out From MAC Any To IP 255.255.255.255 Where Source Port Is Any And Destination Port Is Any in order to allow DHCP "negotiation", reboot and check again whether you can browse (without VPN connection, always). If you can, please report. If not, move down the block rule only one line at a time, and each time check whether the connection is re-established. This will help identify which rule causes the malfunctioning. When you detect the "guilty rule", try various combinations of the already existing allow rules to determine the set of rules which are causing the leaks. Also, feel free to send us your exact Windows configuration, in order to help us reproduce your system as near as we can. Once again, please re-check that you have no other firewalls and/or antivirus running, or any other monitoring system which can run with administrator privileges and interfere with Comodo. Kind regards

@nzbob Hello! Thank you for the report. The various "xx" that are visible in the logs on the "VERIFY OK" lines have been put by you (i.e. you edited the logs) or are those the unedited logs? Does it happen only with Vega on port 443 TCP, on all Vega ports, or on every server? Kind regards

Hello! We don't provide PPTP access. Please refer to the Synology customers' support. Kind regards

Hello! We can't reproduce the behavior. Please move up your main blocking rule to the top, reboot and perform again the test. If you still have connectivity, please report to Comodo support team for major bug. Kind regards

Hello! We're sorry, as far as we know the Synology NAS is not fully compatible with OpenVPN in client mode because it does not support double certificate+key authentications. Please refer to the Synology customer support. Kind regards

Hello! This is a different problem, your TAP-Win32 adapter is inaccessible: 8/26/2012 - 9:07 PM CreateFile failed on TAP device: \\.\Global\{6EFF04E6-FB49-4CD4-9334-9DCD69EA3CA0}.tap 8/26/2012 - 9:07 PM All TAP-Win32 adapters on this system are currently in use. Please make sure that: - no other OpenVPN instances are running - the Air client is launched with administrator privileges - the TAP-Win32 adapter is enabled In order to enable the TAP-Win32 adapter: Windows XP: Open Control Panel->Network and Internet connections->Network Connections. Right-click the adapter "TAP-Win32 Adapter V9" and select Enable. Windows Vista: Open Control Panel->Network and Internet->Network and Sharing Center->Manage network connections. Right-click the TAP-Win32 Adapter and select Enable. Windows 7: Open Control Panel->Network and Internet->Network and Sharing Center->Change Adapter Settings. Right-click the adapter TAP-Win32 Adapter and select Enable. Kind regards

Hello! We're sorry, we don't know Shakespeer. Does it have configurable listening ports? Kind regards