Staff

Hello! We're very glad to inform you that a new 100 Mbit/s server located in Ukraine is available: Theemim. 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, Theemim 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

Hello! We're very glad to inform you that a new 1 Gbit/s server located in the USA is available: Etamin. 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, Etamin 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

Hello! We're very glad to inform you that two new 1 Gbit/s server located in Canada are available: Alhena and Tegmen. The AirVPN client will show automatically the new servers, 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 servers accept connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Alhena and Tegmen support 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

Hello! From the limited number of lines reported on the screenshot it seems there are routing table problems in your system. Please post complete logs in text format ("Logs" -> "Copy to clipboard" then paste here), maybe some additional clue will be visible. Please never post logs through a screenshot unless absolutely unavoidable. Kind regards

Hello! Network Lock is an Eddie plugin. For Windows, currently the only available plugin is for Windows Firewall. You will need to disable Norton Firewall completely if you wish to use Network Lock, because two competing firewalls can cause unpredictable behavior. Otherwise, you will need to set specific rules for your firewall, taking as an example the guide for Windows Firewall or Comodo Firewall in our "How-To" forum: https://airvpn.org/forum/15-how-to Kind regards EDIT Oct 2016: starting from Eddie 2.11, Network Lock uses Windows Filtering Platform (switching to Windows Firewall is optional anyway).

You won't believe it but IT FINALLY WORKED :-D I just tried with "mssfix 1400" and it worked! I also tried anothother values (1500, 1450, etc.) but it works only with 1400. I'm so happy now! Finally I also compared the connection via SSL and there seem not to be any performance hit at all, neither over SSL nor Automatic mode. I run some speed test here and on speedtest.net, pingtest.net. So, if there is no noticable performance hit between UDP and SSL, is it better then to go with SSL connection? I've read this is something like an additional security layer, right? But anyway THANK YOU GUYS!!! :-) Hello! Very well! About OpenVPN over SSL, use it only if you wish (or need) to hide to your ISP the OpenVPN fingerprint, for example when detection of OpenVPN causes traffic shaping. Otherwise you don't need it, because it hits performance and does not add a significant security layer. If you need to strengthen effectively the anonymity layer for specific purposes, you should evaluate to use Tor after you have connected to the VPN (Tor over OpenVPN). Kind regards

Hello! No, in that case you don't need it and you must not use it. Kind regards

Hello! Problem fixed, please try again at your convenience. Kind regards

Hello, since we're not familiar with Microtik you could find yourself without our support in case of necessity, anyway you can get community support of course (which is often excellent); therefore do not hesitate to ask for a free trial coupon which will let you have a free three days subscription, probably the best way to determine whether the service meets your requirements and expectations without spending money. Make sure to file a request to "Trial request" dep. from your registered account. Kind regards

Hello! Nice idea; it has just been implemented. Kind regards

Thank you! We're going to check soon. Kind regards

Hello, about OpenVPN over SSH on stock, non-rooted Android devices, Sheivoko wrote this guide some months ago: https://airvpn.org/topic/13486-ssh-tunneled-vpn-on-stock-android Kind regards

Hello, sorry for the mistake, "fragment" needs to be implemented on server side too, therefore it is not a viable option. Operate only with mssfix (start for example with "mssfix 1400" then lower the value progressively at steps of 50 if necessary). Kind regards

Hello, try to test again with routes check disabled: untick "Check if the tunnel effectively works" in client menu "AirVPN" -> "Preferences" -> "Advanced" and click "Save". Try a new connection and if it is established browse to airvpn.org. Verify whether the central bottom box is green or red. Do the above both with no custom directives and with the following directives: fragment 1400 mssfix to see whether there's any difference. Kind regards

Hello, please see if this helps and please continue there: https://airvpn.org/topic/14141-ubuntu-1504-potential-issue/ Locked. Kind regards

I have an update in this case. I've confronted my ISP with this problem and had a chat with a high positioned technican. He immediately knew what I was talking about and he assured that my ISP does not do things like that. He also assured that the don't block any ports, services ect. But he said I could try to "Increase the MTU to 1.000 in openvpn". The hell I don't know what he was talking about! Anyway I wanted to share it with you air-team and wanted to know what are you thinking about it? At least if you also think it is a good idea to increase the MTU, how can I do it???? Hello! MTU: https://en.wikipedia.org/wiki/Maximum_transmission_unit Our OpenVPN servers have a default setting of 1500 so the technician meant to decrease it, not increase it. You can't change MTU size on the client size only (this size must match on both parties), so that's not an option. You can however operate with "mssfix" (for TCP wrapped in the tunnel) and/or "fragment" (for UDP) directives to handle MTU size problems. You can add custom directives in "AirVPN" -> "Preferences" -> "Advanced" -> "OVPN directives". For example: fragment 1400 Then click "Save" and restart a VPN connection. See below an extract from the OpenVPN manual. This thread can help: https://airvpn.org/topic/9773-receiving-packets-larger-than-1500-bytes/?do=findComment&comment=11446 Kind regards From OpenVPN manual: --fragment max Enable internal datagram fragmentation so that no UDP datagrams are sent which are larger than max bytes. The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself. The --fragment option only makes sense when you are using the UDP protocol ( --proto udp ). --fragment adds 4 bytes of overhead per datagram. See the --mssfix option below for an important related option to --fragment. It should also be noted that this option is not meant to replace UDP fragmentation at the IP stack level. It is only meant as a last resort when path MTU discovery is broken. Using this option is less efficient than fixing path MTU discovery for your IP link and using native IP fragmentation instead. Having said that, there are circumstances where using OpenVPN's internal fragmentation capability may be your only option, such as tunneling a UDP multicast stream which requires fragmentation. --mssfix max Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes. The default value is 1450. The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself. The --mssfix option only makes sense when you are using the UDP protocol for OpenVPN peer-to-peer communication, i.e. --proto udp. --mssfix and --fragment can be ideally used together, where --mssfix will try to keep TCP from needing packet fragmentation in the first place, and if big packets come through anyhow (from protocols other than TCP), --fragment will internally fragment them. Both --fragment and --mssfix are designed to work around cases where Path MTU discovery is broken on the network path between OpenVPN peers. The usual symptom of such a breakdown is an OpenVPN connection which successfully starts, but then stalls during active usage. If --fragment and --mssfix are used together, --mssfix will take its default max parameter from the --fragment max option. Therefore, one could lower the maximum UDP packet size to 1300 (a good first try for solving MTU-related connection problems) with the following options: --tun-mtu 1500 --fragment 1300 --mssfix

Hello! So it was never a DNS leak. Linux just sent DNS queries to the specified nameservers and it tunneled them. A DNS leak is when a DNS query is sent in clear text, outside the tunnel. Generally even with disrespect to your configuration. Unless you tweak Linux in a way to have specific nameservers for each interface and you define multiple routing tables, it is impossible to cause "DNS leaks", simply because there are global nameservers. Kind regards

Hello! There's no need to open a Coinbase account to pay to us via Coinbase and actually we see no compelling reason for a customer to keep an account or a wallet in their systems. Additionally you can add a strong anonymity layer to your Bitcoin client by running it behind Tor. The alleged problems that have been reported in the linked Reddit page pertain to those who keep accounts and even wallets on external systems. This does not appear to be a good way to use Bitcoin in absolute terms, not only with Coinbase. Kind regards

Hello! Just to understand whether the problem is related or not to UDP in your system and/or in your ISP settings, do you see any difference in performance if you establish a VPN connection in TCP (we're assuming that your current connection is on UDP)? Kind regards

Hello! As you can see incoming and outgoing IPv6 packets to/from any interface except lo are dropped. What IPv6 address is detected via ipleak torrent check? Kind regards

Hello, can you explain what you mean with DNS leaks? We ask because there can't be any DNS leak on Linux by definition. What Eddie version are you running? Kind regards

Thank you. When the client is running and Network Lock is enabled, can you please send us the output of the command: ip6tables -L --verboseissued from a root terminal? Kind regards

Hello, which Eddie version are you running? Kind regards

Hello! There is no problem: have you read the thread? Kind regards

Hello! Can you please try again and report back at your convenience? Kind regards