Staff

@zhang888 Hi, ipleak.net queries the updated MaxMind database in real time. Some results are cached but we refresh the cache often, and when necessary. MaxMind is still wrong at the moment of this writing with some IP addresses such as 213.152.162.104 Kind regards

Hello, thank you for your subscription. You are a premium member since a lot of weeks ago, is this a new problem which arose very recently? From the logs it seems that you have severe line problems. As a first check, if the system is connected via WiFi, try to get a stronger signal. If it's connected via cable, test a new cable. Do you have the option to test a different router on the same network with the same system, and test a different system on the same network (with the same router and a different router)? Kind regards

Hello, please see https://airvpn.org/topic/9162-what-is-the-difference-between-tcp-and-udp-ports-which-port-should-i-choose Kind regards

Hello, please publish OpenVPN logs, we wish to verify OpenVPN buffers size first of all, Kind regards

Hello, the cited feature has never been implemented in AirVPN forum and of course it will never be implemented. As far as we can see, questionable data mining is not implemented in plug-ins for the Invision version running in our servers. We will never allow TapaTalk to send out our database e-mail addresses entries. While TapaTalk accesses the database (to allow users' log in our web site from TapaTalk) no transmission of such data to remote TapaTalk servers is allowed. There's no code on the TapaTalk we run that can do it. We can say this for sure because we analyze the source code of several applications in our servers, including the TapaTalk plug-in. The questionable data mining code is implemented in the latest version of Invision TapaTalk plugin, not yet running on our server. Our developers will purge this code before applying the plugin, if it will ever be deployed. We disagree that we infringe their license if we do not allow collection of e-mail addresses: we consider any contractual agreement infringing the EU legal framework on data protection and privacy as invalid (as well as any other contractual agreement causing infringements of the law), and we consider e-mail addresses as data covered by the scope of the relevant Directives on privacy and data protection. Since we are based in Italy and the forum servers are physically based inside the EU, there's no doubt that the applicable law on the matter is EU law, not USA law. According to the contract, if a clause is invalid due to the law, all other non-illegal clauses remain into effect. Kind regards AirVPN Staff

Hello, it makes no difference. Your rules as well as zhang888 rules look fine and everything should be working: the router will forward everything for both services. In case you need further discernment, configure the services to listen to two different ports and configure your Air ports panel and your router iptables accordingly. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in Phoenix, AZ (USA) is available: Peacock. 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, Peacock 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! The problem has been solved. You can now access and watch BBC programs and iPlayer from any Air VPN server, enjoy! Kind regards

Hello! Issue with BBC has been fixed. You can now access all BBC programs / iPlayer from Hong Kong and Singapore servers. Kind regards

Hello, so the problem is with UDP. If it's caused by your ISP nothing can be done, but if it's your router you can solve it. Check for any packet filtering / inspection tool, such as Quality of Service etc., that might de-prioritize or even block UDP. When you're connected over UDP and you start a remarkable traffic volume exchange, such tools might even think that you're under an UDP flood attack, because all the traffic is over UDP. As a consequence they will drop legitimate UDP packets, causing soon a VPN disconnection. Kind regards

Hello, thank you very much, a preliminary analysis confirms your report. An investigation on the issue has been scheduled. Kind regards

What about developing app for mobile devices with such feature? I'm more interested in this issue now. Without field testing on real laptops with listening all network traffic it's useless to discuss Eddie reliability in open wi-fi anyway. Hello, see here: https://airvpn.org/topic/14231-ipv6-leakage-and-dns-hijacking/?do=findComment&comment=27633 It's the first scientific paper which focuses on some specific attacks, particularly possible in open WiFi (AirVPN has been tested as well) which our service is now immune to (the paper is outdated) but it's interesting anyway. About the other theorized attacks in this thread, in our previous messages we wrote why they can't (should not) work. We'll be waiting for additional attacks the community can devise, they can be invaluable source of data to improve Eddie. Kind regards

Hello! To succeed with that reverse engineering, the attacker must have something more. Note from the source code how Eddie communicates to retrieve manifest - or try snooping http traffic from/to Eddie: you should find immediately the missing element which makes this attack impossible as long as the attacker can't break in the backend servers (which are unknown even to Eddie). See also https://airvpn.org/topic/11545-airvpn-client-eddie-beta-testing-phase/?do=findComment&comment=17709 Kind regards

Hello! Understood. Some additional info: the attacker should make many more servers unavailable, not only the auth server. Additionally, Eddie will connect happily (provided that it connected at least once in the past and that the user did not erase the data files) even if the attacker finds and blocks to the client all the possible auth servers. Eddie will use the latest available information to find VPN servers. Once it connects to a VPN server, it tries to update all the data from inside the VPN. Kind regards

Hi, but in this case (we write especially for the casual reader, since this is obvious to you) Network Lock remains active. Even if the attacker manages an exploit to make Mono, .NET or the client "crash", the firewall rules stand. Eddie relies on a different software (pf, iptables or Windows Firewall) for Network Lock, and that's important. Kind regards

@angruvidal Hello, do you connect OpenVPN in UDP, while without VPN most of your traffic is over TCP? If so, is the problem resolved if you connect OpenVPN in TCP? Kind regards

Hello! Network Lock is not available for Windows XP. The fact that the option is showed is a bug, fixed in the latest Eddie release for Win XP. Kind regards

Website: http://www.tf1.fr Official site of French television channels (TF1, TMC, NT1, HD1) Status: OK Native: FR servers. Routing: All other servers.

Website: http://www.france.tv Official site of French public television channels (France2, France 3, France 4 , France 5, France ô) Status: OK Native: FR servers. Routing: All other servers.

Hello, https://airvpn.org/topic/14309-looking-up-server-ips-show-them-in-different-country/?do=findComment&comment=28052 Kind regards

Thank you lsat. Kind regards

Hello! . 2015.06.15 20:17:21 - OpenVPN > Socket Buffers: R=[131072->65536] S=[131072->524288] While the OpenVPN send buffer is appropriate for your line (even too big), the receive buffer could be too small for a 100 Mbit/s line, try to force it to 131072 bytes (currently OpenVPN shrinks it to 65536 bytes, we see from the logs). In Eddie 2.10.1 Experimental you can set buffers size in "AirVPN" -> "Preferences" -> "Advanced" -> "General", and anyway Eddie 2.10.1 sets them to 131072 bytes by default. In Eddie versions older than 2.10.1 you can set buffers size with the OpenVPN directives "sndbuf" and "rcvbuf". In your case: rcvbuf 131072 Put the above line in the "Custom" field that you can see in "AirVPN" -> "Preferences" -> "Advanced" -> "OVPN Directives". On Comcast traffic shaping can be intermittent (it is applied at their discretion even according to customer behavior, see https://airvpn.org/topic/14078-slow-download-speed-hezepersei-fremontca-servers/page-2?do=findComment&comment=27026 ), so your protocol choice could be correct, but you can also test UDP, it's worth a try. Kind regards

Hello! In "AirVPN" -> "Preferences" -> "Advanced" -> "Network Lock" set the combo box "Mode:" to "None". In this way you will completely disable Network Lock, and you will prevent permanently Eddie to modify firewall rules. Anyway, even if you use Network Lock, if you shut down Eddie properly it will restore previous firewall rules diligently. It's only when you kill Eddie without grace that it can't restore rules. Kind regards

Hello! Please see https://airvpn.org/topic/14309-looking-up-server-ips-show-them-in-different-country/?do=findComment&comment=28052 Kind regards

Hello! You're totally free to query any DNS server you wish in our service. Usage of our VPN DNS, although recommended, is not mandatory. About the problem you cite, maybe it is not related to nameservers. It might be a Google IP address geo-location error. Browse to No Country Redirect page, which Google offers even for these cases. https://www.google.com/ncr Kind regards