Jump to content
Not connected, Your IP: 3.12.73.149

Staff

Staff
  • Content Count

    11048
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1867

Everything posted by Staff

  1. Hello, your account is authorized to access all the VPN servers and actually it is currently connected successfully to some VPN server (at this very moment). Please do not hesitate to open a ticket or feel free to confirm or deny here that everything is fine. Thank you for your subscription! Kind regards
  2. @flat4 Hello! Try anyway, because a Celeron CPU, even with other routing tasks in pfSense, should be able to encrypt/decrypt a 10 Mbit/s AES-256-CBC cipher data flow, maybe even more. Kind regards
  3. @Ace3342 Hello! That's possible because HMA implements a rudimentary OpenVPN authentication (which should not be used if security is required). It would not work with our system due to TLS Auth and double certificates authentication, for DHE for PFS... currently, as far as we know the only way reported as working to connect a ChromeOS device to our service is https://airvpn.org/topic/9785-using-service-via-chromebook/?do=findComment&comment=20105 (crouton needed). Kind regards
  4. Hello, you could have prevented the leak by enabling "Network Lock". About preventing modifications to the tap driver, it is not our competence to protect your system against malware. A software injecting code into a system driver without your knowledge falls into the category of malware. However, you probably meant manipulation of the tun/tap interface properties. In order to do so, the program must be authorized by you to have administrator privileges... we'll hear our Windows experts to know if some protection against programs running with administrator privileges is possible or not. Kind regards
  5. Hello! We're waiting for a reply from the datacenter. Kind regards
  6. Hello! Please make sure that you type in the client your exact username and not your e-mail address. Feel free to keep us posted. Kind regards
  7. Hello! Assuming that you run Windows, the system with DNS leaks problems due to lack of global DNS concept, please make sure to tick "Force DNS" in our client "AirVPN" -> "Preferences" -> "Advanced" menu. Then, disable IPv6 in your system, when you're connected to the VPN (our service supports only IPv4). Microsoft provides tiny utilities to enable and disable IPv6 with a click: http://support.microsoft.com/kb/929852 IPv6 is perhaps the reason of the difference you observe between ipleak.net and the other web site. Since ipleak.net does not support IPv6, it should be used only for IPv4 tests. EDIT: that does not seem very plausible, could you tell us whether ipleak.net still does not detect all the DNS nameservers IP addresses or if it works correctly now? Kind regards
  8. Hello, unfortunately Hulu blocks all of our servers. It has nothing to do with anonymity layer or similar arguments. Kind regards
  9. Hello, you'll like to know that since April 2014 three simultaneous connections per account to different VPN servers are allowed. Kind regards
  10. Hello! It's totally unnecessary. In case the information is not gathered for any reason VAT must be paid in the country of the company, according to European Commission guidelines. Kind regards
  11. Hello, to hide to Air VPN servers your IP address you could connect OpenVPN over Tor: https://airvpn.org/tor Kind regards
  12. Hello! Please follow our guide which is sufficiently generic to be applied to your Comodo version. https://airvpn.org/topic/3405-windows-comodo-prevent-leaks/ A radical alternative would be using our Eddie client "Network Lock" feature to achieve the same purpose with a click. However, "Network Lock" uses Windows Firewall, so you would need to disable Comodo Firewall during your VPN usage. Kind regards
  13. Hello! Is the service running and listening to the correct port when you perform the test? Also make sure that some firewall does not block packets to and from the service: in some cases a firewall might block them when the system is inside the VPN. Check the firewall both on the host and the VM. When testing is over, you should not forward that very same port on the router to prevent potential correlation attacks. Kind regards
  14. Hello! It's not a disconnection, it's a TLS re-keying through DHE. See also Perfect Forward Secrecy: https://en.wikipedia.org/wiki/Forward_secrec The re-keying occurs with overlapping windows: until the re-keying has not completed, the old key pair is used to encrypt the Data Channel, so no interruption of the throughput occurs and there's no time pressure. You can't disable this feature, otherwise you would suffer a disconnection every hour. You can lower the key expiration time, although we believe that one hour already provides a fair security. Kind regards
  15. Hello, it is totally ok to use OpenVPN over SSH, although under normal circumstances (i.e. no traffic shaping) the performance will be lower than direct UDP, because of the overhead caused by a tunnel inside another tunnel and because OpenVPN must work in TCP. For this very reason, the symptoms you report are quite a proof that your ISP performs traffic shaping. Take note of the differences you have with the other VPN provider, it would be interesting to see why it does not get throttled. It might be because they use a different port, or because they don't use OpenVPN for example. Test also direct UDP connection to port 53, if you haven't already done so, and feel free to keep us posted. Kind regards
  16. Hello! Very well. Just as a side note, about the failure you mention, if you're running a Linux system make sure that in the DNS Switch mode combo box (in AirVPN->Preferences->Advanced) you select "Renaming", not "Resolvconf" or "Automatic", in order to prevent any possible conflict between your up directive and the up directive that the client will need to accept DNS push through resolvconf-related script. Kind regards
  17. Hello! If confirmed it will be fixed in the next Eddie version. Work-around: add the "up" directive as a custom directive, in "Custom" field of Eddie "AirVPN" -> "Preferences" -> "Advanced" -> "OVPN Directives" menu/window. Remember to add "script-security 2" as well, in order to tell OpenVPN that your own scripts are authorized. From OpenVPN 2.3.x manual: --up cmd Run command cmd after successful TUN/TAP device open (pre --user UID change). cmd consists of a path to script (or executable program), optionally followed by arguments. The path and arguments may be single- or double-quoted and/or escaped using a backslash, and should be separated by one or more spaces. The up command is useful for specifying route commands which route IP traffic destined for private subnets which exist at the other end of the VPN connection into the tunnel. For --dev tun execute as: cmd tun_dev tun_mtu link_mtu ifconfig_local_ip ifconfig_remote_ip [ init | restart ] For --dev tap execute as: cmd tap_dev tap_mtu link_mtu ifconfig_local_ip ifconfig_netmask [ init | restart ] See the "Environmental Variables" section below for additional parameters passed as environmental variables. Note that if cmd includes arguments, all OpenVPN-generated arguments will be appended to them to build an argument list with which the executable will be called. Typically, cmd will run a script to add routes to the tunnel. Normally the up script is called after the TUN/TAP device is opened. In this context, the last command line parameter passed to the script will be init. If the --up-restart option is also used, the up script will be called for restarts as well. A restart is considered to be a partial reinitialization of OpenVPN where the TUN/TAP instance is preserved (the --persist-tun option will enable such preservation). A restart can be generated by a SIGUSR1 signal, a --ping-restart timeout, or a connection reset when the TCP protocol is enabled with the --proto option. If a restart occurs, and --up-restart has been specified, the up script will be called with restart as the last parameter. The following standalone example shows how the --up script can be called in both an initialization and restart context. (NOTE: for security reasons, don't run the following example unless UDP port 9999 is blocked by your firewall. Also, the example will run indefinitely, so you should abort with control-c). openvpn --dev tun --port 9999 --verb 4 --ping-restart 10 --up 'echo up' --down 'echo down' --persist-tun --up-restart Note that OpenVPN also provides the --ifconfig option to automatically ifconfig the TUN device, eliminating the need to define an --up script, unless you also want to configure routes in the --up script. If --ifconfig is also specified, OpenVPN will pass the ifconfig local and remote endpoints on the command line to the --up script so that they can be used to configure routes such as: route add -net 10.0.0.0 netmask 255.255.255.0 gw $5 --up-delay Delay TUN/TAP open and possible --up script execution until after TCP/UDP connection establishment with peer. In --proto udp mode, this option normally requires the use of --ping to allow connection initiation to be sensed in the absence of tunnel data, since UDP is a "connectionless" protocol. On Windows, this option will delay the TAP-Win32 media state transitioning to "connected" until connection establishment, i.e. the receipt of the first authenticated packet from the peer. Kind regards
  18. Hello! Since your VM is attached via NAT to your host you need to forward that very same port from your host to your VM. Virtualization software like VirtualBox nowadays handle very well port forwarding to VMs attached via NAT. Kind regards
  19. Hello! ECC is not in OpenVPN main branch. Additionally, there are some unsolved questions and doubts, see Bruce Schneier for example, that we feel to take into highest consideration. We will take ECC into consideration only when it's in the main branch and if implemented without being based on parameters/constants which could have been manipulated by NSA to insert artificial weaknesses, i.e. only curves not based on the NIST recommended parameters etc., because they have been created by Solinas working for NSA and because there are some weird choices which trigger our... paranoia...? See also this interesting discussion: https://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters Before going into ECC, you ought to be sure to use non-influenced by NSA elliptic curves. Ideally, you should also know how and to which extent NSA influenced the development and implementation of ECC through NIST standards and recommendations. Is there any reason for which you are going into ECC with such a light heart, almost "unconsciously" we would dare to say? Which curve parameters is the service you cite using? About performance, there can't be substantial operative difference between elliptic curves and integer discrete based ciphers for the Data Channel, and even less for the Control Channel, so any performance gain or loss can't be caused by that. Kind regards
  20. Hello! Problem solved via ticket (of course we can't publish the code here ). Thank you very much! Kind regards
  21. Hello, you should just put country Netherlands in the black list. Click "Countries" tab, select "Netherlands", click the icon "Blacklist". Kind regards
  22. Hello, SkyGo is accessible (to subscribers) from all of our VPN servers provided that your system queries the VPN DNS. It is perfectly legal, you're a subscriber! Kind regards
  23. Hello! Eddie client can run on OS X Mavericks and Yosemite only. Older OS X versions should run Tunnelblick, which is free and open source as well. Instructions for Tunnelblick are in the usual OS X page, in our web site click "Enter" -> "Mac OS X". You might even consider to upgrade your system, if possible. Kind regards
  24. Hello! We will consider this option in the near future. In the meantime, you could connect both devices to the same server, provided that you don't need remote port forwarding. Just connect the devices to different ports to prevent conflicts. For example, device 1 to port 443 (UDP) and device 2 to port 80 (UDP). Kind regards
  25. Hello @JWW, Eddie's "Network Lock" works on every browser and every program because it solves the Windows problem at its roots. What you cite is a Chrome extension, unrelated to VPN or other services. It can't prevent WebRTC leaks from other than Chrome programs. Currently we do not have developers for browsers extensions, but who knows, it could be an idea. Anyway, good to know that such an extension now exists. Previously available extension did not work properly. Kind regards
×
×
  • Create New...