Jump to content
Not connected, Your IP: 18.227.102.162

Staff

Staff
  • Content Count

    10933
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1843

Everything posted by Staff

  1. Staff

    UK - Virgin

    We cross-checked the reports of dozens of our customers with Virgin Media UK, asking them to resolve "airvpn.org" on two of Virgin DNS servers. Since all the reports matched exactly throughout one year, we can safely assume that the reports are reliable. It is also worth mentioning that DNS poisoning of airvpn.org is intermittent, and when contacted directly about the issue, Virgin Media responded to us that it was a technical problem, totally unintentional. How are we supposed to know? All in all even the cyber workers of the government of China are interested in our web site, not only with DNS poisoning but also IP blocking. Who knows, maybe it's really just an obscure technical error that re-occurs periodically. Kind regards
  2. Hello, the Data Channel cipher for packets authentication is HMAC SHA (edit: note that there is no GCM support for the data channel yet... it will be probably implemented in OpenVPN 2.4). Perhaps your libraries do not support DHE-RSA-AES256-GCM-SHA384 with TLS 1.2 (also listed as "TLS-DHE-RSA-WITH-AES-256-GCM-SHA384" in OpenVPN 2.3.8). In this case use "TLS-DHE-RSA-WITH-AES-256-CBC-SHA". Edit: note that there is absolutely no rational reason to rush to SHA384 and drop HMAC SHA1 which is NOT vulnerable to SHA collisions. We often read (even in our forum) a confusion pertaining to SHA1 vulnerabilities, which are thought (with an unexplainable mistake) to be extended to HMAC SHA1. See also here: https://crypto.stackexchange.com/questions/26510/why-is-hmac-sha1-still-considered-secure Back to the Control Channel, which is the subject of this topic. By default, OpenVPN 2.3.3 or higher will first choose TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 if available, over TLS-DHE-RSA-WITH-AES-256-CBC-SHA, so if you needed an explicit directive for the first, very probably your system does not support it. So, at the end of the day, you normally do not need any additional directive, OpenVPN will pick automatically the best cipher between those available both in your and our systems. See also "openvpn --show-tls". One more edit: please see also here https://security.stackexchange.com/questions/92638/openvpn-cipher-vs-tls-cipher , in particular: Kind regards
  3. Hello! Ok, anyway, if you prefer so, probably you have noticed that since some weeks ago you can use (provided that your OpenVPN and OpenSSL or PolarSSL supports it) the following TLS cipher: DHE-RSA-AES256-GCM-SHA384 with TLS 1.2. The RSA keys are of course the same (4096 bit) as well as DH keys (4096 bit). If you feel that HMAC SHA1 is not adequate for the Control Channel (but we see no reasons for that) you can use the above cipher. Kind regards
  4. Hello! The boxes are displayed on most, if not all, of our web site pages. This is a very light one https://airvpn.org/aboutus Kind regards
  5. @just-me & others Hello! It looks like Eddie behaves correctly and properly. By default, it appears that Windows Firewall is disabled in your system. When you enable Network Lock in Eddie, it activates the firewall. You can see here that your firewall was disabled and Eddie enables it: ! 2015.10.15 22:47:17 - Activation of Network Lock - Windows Firewall ... . 2015.10.15 22:47:21 - Shell of 'cmd.exe','/c netsh firewall set notifications mode=disable profile=DOMAIN' done sync in 218 ms . 2015.10.15 22:47:21 - Shell of 'cmd.exe','/c netsh advfirewall set private state on' done sync in 219 ms . 2015.10.15 22:47:21 - Shell of 'cmd.exe','/c netsh firewall set notifications mode=disable profile=STANDARD' done sync in 218 ms . 2015.10.15 22:47:22 - Shell of 'cmd.exe','/c netsh advfirewall set public state on' done sync in 219 ms . 2015.10.15 22:47:22 - Shell of 'cmd.exe','/c netsh firewall set notifications mode=disable profile=CURRENT' done sync in 218 ms . 2015.10.15 22:47:24 - Shell of 'cmd.exe','/c netsh advfirewall firewall delete rule name=all' done sync in 1903 ms . 2015.10.15 22:47:24 - Shell of 'cmd.exe','/c netsh advfirewall firewall add rule name="AirVPN - ICMP V4" dir=in action=allow protocol=icmpv4' done sync in 172 ms ... ... Then, when you either disable Network Lock or shut down Eddie, Eddie restores the firewall to its previous state (which was DISABLED): ! 2015.10.16 07:43:40 - Deactivation of Network Lock . 2015.10.16 07:43:42 - Shell of 'cmd.exe','/c netsh advfirewall set domain firewallpolicy ,' done sync in 1498 ms . 2015.10.16 07:43:42 - Shell of 'cmd.exe','/c netsh advfirewall set private firewallpolicy ,' done sync in 171 ms . 2015.10.16 07:43:42 - Shell of 'cmd.exe','/c netsh advfirewall set public firewallpolicy ,' done sync in 188 ms . 2015.10.16 07:43:44 - Shell of 'cmd.exe','/c netsh advfirewall import "C:\Users\Anon\AppData\Local\AirVPN\winfirewall_rules_backup.wfw"' done sync in 1669 ms . 2015.10.16 07:43:44 - Shell of 'cmd.exe','/c netsh advfirewall set domain state off' done sync in 218 ms . 2015.10.16 07:43:45 - Shell of 'cmd.exe','/c netsh advfirewall set private state off' done sync in 234 ms . 2015.10.16 07:43:46 - Shell of 'cmd.exe','/c netsh advfirewall set public state off' done sync in 1279 ms Kind regards
  6. Hello! If you had Network Lock enabled in our Air client, you have always prevented "WebRTC leaks", as well as any other packet out of the tunnel sent by any process binding to your physical network card. https://airvpn.org/faq/software_lock/ Kind regards
  7. Hello! We remind you that we use 4096 bit keys for DH and unique primes on each VPN server. Kind regards
  8. Hello, in several cases it's not enough that a second firewall is disabled. Conflicts can arise anyway according to our experience with Comodo and Windows Firewall. Kind regards
  9. Hello! We inform you that a rack relocation of servers Aquilae, Tauri and Velorum (DE) will occur during the night between October the 19th and the 20th (UTC). We will shut the servers down at: 10-19-15 21.00 UTC We expect to bring the servers back on line approximately at: 10-20-15 05.00 UTC Kind regards AirVPN Staff
  10. In this case there is a pinned topic on this very same forum. Kind regards
  11. Hello, probably it has nothing to do with Network Lock feature. It's not unusual that public WiFi hot spots block UDP. Maybe that's the cause of the problem. Try a connection in TCP, or even "SSL Tunnel - Port 443" to see whether it solves the problem. In Eddie you can change connection mode in "AirVPN" -> "Preferences" -> "Protocols". Kind regards
  12. Dozens of reports throughout 2014 and 2015 show that in Virgin network DNS poisoning is (probably intermittently) used against https://airvpn.org Solution: use a publicly accessible, not poisoned DNS, for example OpenNIC https://opennicproject.org or contact us to know alternative domain names to access various https front ends in our infrastructure.
  13. A report dated September 2015 shows that it is not possible to use OpenVPN in UDP mode. Possible interference/disruption. Solution: connect in TCP.
  14. Hello! We're very glad to inform you that a new 100 Mbit/s server located in Ukraine is available: Procyon. 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 "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Procyon supports OpenVPN over SSL and OpenVPN over SSH. 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 Team
  15. Hello, just an idea: please check the OpenVPN socket buffers sizes in the router (you can see how they are set for example in the OpenVPN logs). When you run the client, it tells OpenVPN to set buffers of 128 kB. Buffers smaller than 64 kB may slow down performance significantly when required throughput exceeds 20 Mbit/s. The directives for OpenVPN are (respectively for the send and the receive buffer): sndbuf n rcvbuf n where n is in bytes (so set them to 131072 to have 128 kB buffers). Kind regards
  16. Hello, the performance looks bad even without VPN. By the way do not trust our speed test (or any other speed test) and make sure to test different servers in different countries. How are the OpenVPN socket buffers sizes set? Kind regards
  17. Hello, not reproducible on any testing machine. Never reported by thousands of customers using Eddie with Windows every day. It must be something extremely peculiar and specific to your system. Can you provide complete details of your system setup (including any antivirus, firewall and packet filtering/inspection tool installed) and exact steps to reproduce the issue? Kind regards
  18. Hello, BBC geoblock our UK server "Carinae". We have inserted Carinae to Geolocation routing and now don't redirect to bbc.com. Kind regards
  19. @bobber6 We do not comment on laws that our lawyers have not read in their entirety and we won't comment on draft laws because they can be modified hundreds of times or dropped. We know of similar laws that are already enforced in various Western countries, for example France and USA, where intelligence personnel can wiretap a private citizen without a mandate from a magistrate or judicial overview, or where mass surveillance is routinely performed by competent agencies (think about NSA). We usually find EDRi comments and articles enlightening so we re-direct you there for analysis of such laws. This is a page you should be interested in: https://edri.org/theme/security-surveillance We already wrote years ago about how to defeat a particularly powerful adversary under specific conditions (for example that your system is not compromised) so we will not comment again on that. It's bad that you spend time to write here without having searched our forums. Here it is, for your comfort: https://airvpn.org/topic/54-using-airvpn-over-tor/?p=1745 About other parts of the laws we cited, we remind you once again that it's not our competence and it's not the purpose of our service to protect your system against malware, including spyware installed surreptitiously by intelligence or other entities. When a system is compromised by such spyware, usage of a VPN, Tor etc. is totally irrelevant. Kind regards
  20. Hello! We're very glad to inform you that a new 1 Gbit/s server located in Paris (FR) is available: Marfic. The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accept connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Marfic supports OpenVPN over SSL and OpenVPN over SSH. 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 Team
  21. Hello! We're very glad to inform you that a new 1 Gbit/s server located in Munich (DE) is available: Mesarthim. The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accept connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Mesarthim supports OpenVPN over SSL and OpenVPN over SSH. 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 Team
  22. Hello, you're right, except of course for the packets from/to your node to/from the VPN server. Kind regards
  23. Hello, where did you get this idea? It is designed specifically NOT to do it, for important reasons (think about headless servers remotely administered). Leaving your system isolated from the Internet while the Air client is not running is your sole responsibility and can be achieved very easily in a few seconds (see how Netwok Lock works to understand how). It would be an enormous design flaw to allow the Air client to do that. The client RAM footprint is minimal and can be loaded in a fraction of seconds. If the client needs two minutes to run, it is certainly some problem in your system. If you mean that it's OpenVPN that needs two minutes to connect, then it's again a problem in your system. Note that the Air client is an OpenVPN wrapper. That's not "corruption" of your network and restoring to a prior savepoint is not necessary. It's an obvious consequence of killing the client without grace, because in such a case you prevent the client to restore your previous firewall and DNS settings. That's a blatant absurdity, see above. Implementing Network Lock through plug-ins which use firewalls is intentional. The good part of it is that it is modular and allows any third-party to support their firewall (Eddie, including the Network Lock plug-ins, is free and open source). The excellent part of it is that it defers packet filtering to already established, peer-reviewed tools developed in decades, instead of starting from scratch with subsequent security problems. For these reasons, writing an own firewall would be a terrible mistake and your recommendations are not only not acceptable, but even a list of "awful things to avoid at all costs in software design". You seem to follow the perverted vision of monolithic applications which try to do anything by themselves, which is a vision that, when implemented (it had some crazy followers some years ago, actually, and someone is still convinced of the goodness in it), has brought to catastrophic consequences. Or perhaps your post has been influenced by major problems in your system, so feel free to open a ticket to try to investigate on them. Kind regards
  24. The problem arises in very rare cases, when no NAT device is present, for example when you connect an ethernet port from your cable modem to your LAN adapter directly, and your ISP assings you public IPs by defailt. In this case, your reported WebRTC IP would be not internal, but external, potentially exposing your original IP address. But this setup is very rare these days, most people have Wi-Fi's, which automatically implies usage of a router with NAT mechanism. Nissemus is right, the external, public IP address is immediately found even if you're behind a NAT. The application binds to the physical interface which sends packets outside the tunnel to the router which routes them in the usual ISP route. The receiver that asked for STUN service will receive packets coming from the customer real IP address. Network Lock will of course prevent this, as you know, just like it drops any other packet out of the tunnel coming (for example) from processes binding to the physical interface. As a side note, see also how STUN is able to traverse NAT: https://webrtchacks.com/stun-helps-webrtc-traverse-nats/ Kind regards
  25. Hello! Can you please upgrade to Eddie 2.10.3? There are some issues between Eddie 2.9.2 and Yosemite. Although these issues seem unrelated to your problem, it's worth to upgrade and perform a test anyway. Changelog available here: https://airvpn.org/services/changelog.php?software=client&format=html Kind regards
×
×
  • Create New...