-
Content Count
11388 -
Joined
... -
Last visited
... -
Days Won
1978
Everything posted by Staff
-
Hello, it looks correct, that service allows access only to UK IP addresses. Kind regards
-
EDIT: SERVER WITHDRAWN ON 16-JUN-2016. Reason: major hardware failure. Hello! We're very glad to inform you that six, new 1 Gbit/s servers located in Sweden are available: Acubens, Beid, Cumeisa, Nodus, Pherkad and Rastaban. 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, Acubens, Beid, Cumeisa, Nodus, Pherkad and Rastaban 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
-
ANSWERED AirVPN Config Not Connecting
Staff replied to acid192's topic in Troubleshooting and Problems
Hello, good that the main problem is solved. Probably OpenVPN logs can explain what goes wrong when trying to execute update-resolv-conf script. Kind regards -
ANSWERED AirVPN Config Not Connecting
Staff replied to acid192's topic in Troubleshooting and Problems
Hello! It could be a DNS problem. Maybe the nameservers you have in /etc/resolv.conf can't be accessed through the VPN servers. If so, this is a very minor problem: your traffic is tunneled but your system can't resolve names. Check for names resolution and connectivity to discern the case, for example (from a command line interface): ping -c 4 8.8.8.8 ping -c 4 10.4.0.1 ping -c 4 google.com (if in doubt copy and paste the output of those commands). resolvconf is available for Arch Linux, right? If so, please see here: https://airvpn.org/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf For a quick test, please edit (as root) the /etc/resolv.conf file while the system is connected to a VPN server, and add the following line: nameserver 10.4.0.1 then check whether names are resolved. Kind regards -
Hello! As you may have been noticed, Zaurak is down and has been down since 9 days ago. Zaurak is not reachable in any way. All of our contact attempts with the datacenter support staff have failed so far. We receive automated replies as a receipt confirmation of our tickets, then nothing. The official web site of the housing company is reachable as usual, as well as the customers administrative panel. Unfortunately, although we understand that situation in Kiev might pose problems to business and connectivity, we repute that it would have been reasonable to expect at least some feedback after nine days. We will keep you informed. We are also planning to find an alternative Ukraine datacenter to replace the current one, in an attempt to remain with at least a server in Ukraine. We apologize for the inconvenience and we are confident that you understand that we have no control on this incident. Kind regards AirVPN Staff
-
Hello! 1) Packets injection by ISPs normally have the only purpose to force advertisements to you. More sinister purposes could be sought by different entities. https://en.wikipedia.org/wiki/Packet_injection 2) Unfortunately not. It is not trivial to prove packet injection. 3) We leave answers to this questions to software developers. 4) OpenVPN is extremely resistant to replay attacks and it can be used whenever end-to-end validation and encryption is not available. Otherwise, end-to-end encryption and validation normally makes replay attacks impossible to succeed. With OpenVPN, you can add (as already written both by you and us) an additional security layer, i.e. using OpenVPN with TCP as transport layer (see also the manual piece quoted here: https://airvpn.org/topic/3773-pls-help-strange-logs/?do=findComment&comment=3784 ). Kind regards
-
Hello! A replay attack can come from someone inside the ISP network, not necessarily by the ISP personnel or network configuration. There's nothing to laugh about, if they do it again tell them that even giant ISPs like Comcast inject packets for marketing purposes or any other reason: https://www.techdirt.com/articles/20140908/07191228453/comcast-using-packet-injection-to-push-its-own-ads-via-wifi-apparently-oblivious-to-security-concerns.shtml The problem with many ISPs attacking their own customers with packet injection began at least EIGHT years ago: https://www.eff.org/wp/detecting-packet-injection so the person who laughed when you reported your case has provided a strong proof of his/her utter incompetence. Description you provide in point 1 is interesting. If it was packet injection attempt you would exactly experience that. What is your ISP (don't tell if you don't wish so)? Kind regards
-
Slow download speed - Heze/Persei Fremont/CA Servers
Staff replied to ddrnewb's topic in Troubleshooting and Problems
I don't blame anyone here because a vast amount of users are more than satisfied with their speed (hrrhrr, including me ), and some of them subscribed to 100 Mbit plans (unfortunately, not including me ). I was pointing at those who fail to reach these speeds. One particular case highly interests me because that person downloaded with full speed on Linux and failed to do so on Windows. So I assume reasoned this shaping thing has something to do with Windows, it's (TCP/IP stack) (default) configuration, the hardware drivers and/or the driver's configuration. Going to drill down on that... Hello! Have you seen this: https://airvpn.org/topic/13652-eddie-udp-443-on-windows-vs-linux/?do=findComment&comment=27068 ? Kind regards -
Hello! Problem solved, can you try again? Kind regards
-
Hello! Problem is under investigation by the competent person. CoinBase warned about a "wrong payment" (the paid BTC amount does not match the required amount) but let us check about this claim. Kind regards
-
Hello @ghostp ! 1) The Automatic mode in Eddie at the moment always picks protocol UDP, port 443 2) You can't get the mentioned logs entries when OpenVPN works in TCP because a first error correction is performed at TCP transport layer. See the already linked messages for more insights about that. Note that when over SSL or SSH, OpenVPN must work in TCP (stunnel and ssh do not and can not support UDP) 3) The fact that you don't experience packet loss without VPN is interesting. Two possible explanations: either you are not detecting correctly packet loss (how did you verify that?) or you are really subjected to replay attacks - in which case OpenVPN is doing its job correctly, in UDP. In the latter case, the fact that you get packet authentication failures with every and each VPN server in several different datacenters would seem to imply that the replay attack is performed in some point inside your ISP network (it's possible: injecting forged packets is not rocket science once someone is in your same network). It would be an attack specifically aimed against you. In this case, when you don't use VPN and you don't use end-to-end encryption and authentication, the attack would succeed, but it could be hard (if not impossible) for you to recognize forged injected packets. Kind regards
-
Request for implementing DANE on AirVPN website
Staff replied to OpenSourcerer's topic in General & Suggestions
Hello, changing NS implies to become authoritative, requires stable DNS with fail-over and load-balancing, manual reconfiguration of all the domain stuff (like DNSSEC) etc. It may be done in the future, but currently DANE is unsupported by major browsers on client-side and unused by an overwhelming majority of persons even when some add-on for their browser is available. Interesting stuff, but it does not justify the work of changing NS records at the moment, we're sorry. Kind regards -
Request for implementing DANE on AirVPN website
Staff replied to OpenSourcerer's topic in General & Suggestions
Hello! We enabled IPv6 on airvpn.org . We enabled DNSSEC on airvpn.org. Now https://en.internet.nl/domain/airvpn.org/results returns a 100% score. Unfortunately, our registrar GoDaddy does not support TLSA record required by DANE protocol. http://comments.gmane.org/gmane.ietf.dane/907 At the moment, we can't do anything, neither change GoDaddy. We will try to request this feature to GoDaddy. In the future, we will study about the option to add DNSSEC on airdns.org (DDNS domain linked to port-forwarding etc. which is on our authoritative DNS), but it seems a bit complex. TLSA will be added for sure when GoDaddy supports it. Please, push freely. We always read all the topics/posts, but we might forget something if we have other priorities. Pushing doesn't cost nothing. Kind regards -
Hello! Apparently you have performed all the necessary steps. On the router, if you're forwarding with iptables you can compare with this guide (for Tomato and DD-WRT, maybe you can find it useful for your router too): https://airvpn.org/topic/9270-how-to-forward-ports-in-dd-wrt-tomato-with-iptables Maybe not related but you never know: you must access Plex from a different machine, not from the very same machine that's running it and that's connected to the VPN. Make sure that you access it on the VPN server exit-IP address, correct port (the port you have remotely forwarded in your port panel in our web site). Kind regards
-
easiest way to keep LAN traffic while on network lock
Staff replied to kongolav's topic in Troubleshooting and Problems
Hello! Try with Eddie 2.9.2 Experimental for OS X Mavericks/Yosemite. In the usual OS X download page https://airvpn.org/macosx click "Other versions" then select "Experimental". In "AirVPN" -> "Preferences" -> "Network Lock" tick "Allow lan/private", click "Save" and test. According to our tests on Yosemite systems everything works fine, feel free to let us have your feedback. Kind regards -
Hello! PiWick fully respects users' privacy (and our privacy as well!) and is open source. It is fully compliant to any EU directive on privacy and data protection and it goes even further. About performance, of course you can't normally expect more than what you already get without VPN. Feel free to open a ticket to try to improve performance. Kind regards
-
Nope, I did not change anything, even my modem/router is the same. What do you think, might it be something I should concern about? @ghostp Hello, at the moment it's difficult to say something. It could be just a momentary line problem, go on checking in the next hours or even days. As a generic suggestion, if your system is connected via WiFi, try to get the strongest signal. If it is connected via Ethernet, try to replace the cable. The following post talks about the log lines you get and replay attacks: https://airvpn.org/topic/3773-pls-help-strange-logs/?do=findComment&comment=3784 Kind regards
-
This client is obsolete and no more supported
Staff replied to libai's topic in General & Suggestions
Hello, you're still running the old version, please make sure you launch the new one. Kind regards -
Slow download speed - Heze/Persei Fremont/CA Servers
Staff replied to ddrnewb's topic in Troubleshooting and Problems
Hello! If you connect via UDP 443 with other providers with the very same cipher (please check both of these) and you get higher performance then we have no rational explanation, we're sorry. Maybe it's a peering problem, try also other servers in different datacenters, because Heze and Persei are in the same datacenter with the same provider. Kind regards -
Slow download speed - Heze/Persei Fremont/CA Servers
Staff replied to ddrnewb's topic in Troubleshooting and Problems
Hello! We confirm all that written before. You have obtained triple throughput with OpenVPN over SSL than with direct UDP, instead of lower. Your calculations are wrong (because they do not take into account how a VPN works), but that's not important at all: even when the throughput is the same, this is a "smoking gun": traffic shaping. The point is that you got at least once higher throughput with OpenVPN over SSL than with direct UDP connection, and in all other cases approximately the very same throughput. If there was no traffic shaping (of course assuming that every other condition you reported stands), you would have always got a significantly lower throughput with OpenVPN over SSL. Tests to Persei are fine at the moment. Sometimes you can even see some user in the Top 10 Speed table (in the "Status" page) connected to Persei. Now, let's move on to find something more useful for you, we repeat: it would be relevant to compare the ports you connect to the VPN servers with PIA and with Air. The option that it is port shaping deserves to be verified. Also, what is your CPU and which cipher do you select when connected to PIA? Kind regards -
@karn Of course, you can pick a specific server, or a country, or a specific set of servers... please read the instructions for Android: https://airvpn.org/android Kind regards AirVPN Support Team
-
Slow download speed - Heze/Persei Fremont/CA Servers
Staff replied to ddrnewb's topic in Troubleshooting and Problems
Not true. Did you not see the 3rd speed test I posted? It was done using SSL 443. We also saw this: https://airvpn.org/topic/14078-slow-download-speed-hezepersei-fremontca-servers/?p=26937&do=findComment&comment=26937 where it is reported a performance that's almost triple than that you recorded with direct UDP connections. At the same time you are absolutely sure that there is no congestion in your ISP network, so we have momentarily ruled out this option. That's why we think it's traffic shaping, but of course it could be also bad peering. Let's try to verify the first option first. That fact is meaningless in many cases, for example if it is port shaping. It would be relevant now to compare the ports you connect to the VPN servers with PIA and with Air. The option that it is a port shaping deserves to be verified. Also, what is your CPU, and which cipher do you use with PIA? Kind regards -
Slow download speed - Heze/Persei Fremont/CA Servers
Staff replied to ddrnewb's topic in Troubleshooting and Problems
@ddrnewb As you can see either your ISP or your system perform extreme traffic shaping because with OpenVPN over SSL, instead of getting lower performance, you get almost the triple throughput. This means that the remarkable overhead introduced by double tunneling added to the extremely significant loss of performance when OpenVPN is forced to work in TCP (because stunnel can't support UDP) added to all the problems related to TCP/UDP (your applications protocol) over TCP over TCP, are LESS than the traffic shaping against pure UDP and/or OpenVPN by your ISP or by your system. If you don't have anything in your system that slows down UDP and/or direct OpenVPN (we have seen cases of customers throttling their own systems without even being aware of that...) your ISP is the culprit. Another clue that points to your ISP and not to your system is that in different hours you have got significantly different performance. Even if we assume that it was the Persei datacenter congested (which should not be the case because we are careful about infrastructure of our ISPs), then you should have recorded higher performance on some other location. Kind regards -
Slow download speed - Heze/Persei Fremont/CA Servers
Staff replied to ddrnewb's topic in Troubleshooting and Problems
Hello, how can you know whether the other provider provides connections to the same ports with the same ciphers and same protocol tried on our servers by ddrnewb or not? And even if it did, you can't assume that ddrnewb tested exactly under the same conditions both services. Actually ddrnewb did not specify anything about that, so it's not correct to make such an assumption. And as you can see from the results he/she posted, we were right, either his/her ISP is performing traffic shaping or it's his/her system to do that. Kind regards -
@CriticalRabbit Hello, according to your description no leak was possible. Network Lock in Linux operates with iptables which is a frontend to modify kernel tables. When the VM crashed, either the kernel of the guest OS did not work anymore, so the whole machine was dead even at the most basic level - a TCP/IP stack did not even exist anymore probably - or it did still work, in which case outgoing packets outside the tunnel would have been dropped. Kind regards