Search the Community

Hello, direct OpenVPN connections are disrupted in most China lines since years ago, you were lucky that yours was not. OpenVPN over SSL will solve the problem just like over SSH, but probably with higher performance (apparently, SSH is allowed on every line but it is shaped more than SSL/TLS to port 443). Please select "SSL Tunnel - Port 443" in client menu "AirVPN" -> "Preferences" -> "Protocols". Kind regards

Suddenly, last week here in Shanghai, I could not connect to ANY server with Automatic protocols selected. I could only get a connection using an SSH tunnel. This option seems to also be slow. Chinese TV sucks and I want to download via torrent my shows...Torrents also generally make the connection crash in several ways (my wifi, the hotels AP, time outs...)

http://www.reuters.com/article/2015/06/14/us-britain-security-idUSKBN0OT0XF20150614 What do you guys think. Is it possible that they cracked it or have they got the information from Snowden?

Hello! In China, please try OpenVPN over SSL (it's called "SSL Tunnel - Port 443" in our client Eddie). Upgrade to Eddie version 2.8.8 or 2.9.2 is recommended. Feel free to keep us posted. Kind regards

What if users are in China and not connected to the vpn? I think this is still valuabled for the same reason as the website providing ip addresses in the config section.

I appreciate your logic. I am a number cruncher but sometimes I go with the 'eye' (or 'nose') test; even if the numbers add up. It does not smell right. That is just for me. I am not suggesting anyone use or not use their services. I find it sad that they need to specifically say people in Iran, China, etc cannot use their software. Or if I were to travel to those countries, it is illegal for me to use it, not to mention have it installed on my device. I do not trust the lawmakers who represent those communities. I do not trust the companies who (are bound by and) will overwhelm me with their laws. I'll defer to you on comparing that other provider. It sounds like you have thoroughly researched them.

hi, How's that server from China? What speeds did you get?

One user descriped a way how to bypass the great firewall in china: https://airvpn.org/topic/11134-ssh-or-ssl-tunnel-on-android/?p=21319 Why isn't android supported officially? If the devs decide to support this I will make an video which would explain this feature and how to install it.

Hi on my rhel 6.6 system I can't install mono for corporate compliance. I have installed openvpn and was trying to use it from the console or via NetworkManager. at the moment, I am connected from China via the corporate VPN but was looking at some independent solution. when I disconnect the corporate VPN, and triy to connect using openvpn udp 443 fails to connect (timeout) ssh tunnel port 22 and ssl tunnel on 443 both connect I get a tun0 device with a 10.... IP. note that I had the openvpn config files imported in NetworkManager else resolv.conf did not get updated. however if I try to ping the 10.* dns server that appears in resolv.conf I never get a reply. I can't even ping google's own DNS servers so after I connect via openvpn I am effectively isolated although with a 10.* IP address. I even tried flushing my iptables but no change (and anyway the tun0 device created by my corporate VPN dialler works fine) suggestions welcome

I've personally had success with "AirVPN over SSH" (though I just signed up a few hours ago so I have it as an alternative to another VPN provider). Strangely no success with AirVPN over SSL, though my understanding is that China is starting to get wise to SSTP type traffic. That said, my personal experience in China is that the great firewall differentiates between cellular access and land lines. I have used roughly 6 VPNs in my time in China and all of them have had very few issues on my cell phone and all of them were completely screwed when I used them in the office or at home.

I know that it is easy to use airvpn from china with an ssl tunnel works fine with Eddie. But there is still one problem: Lets say you are in wuhan, the next available server is Hongkong. The distance is very far, wouldn't it be possible to get nearer server locations in this reigion (japan / south korea / taiwan)?

I notice there is already another topic for this but I want one to be dedicated to a tutorial for SSH and SSL on the android. If someone could post the instructions for them it would be much appreciated to me and many others (especially China citizens). Thank you.

oh, since you have an asus ac68 you need to also use the forums at http://forums.smallnetbuilder.com/forumdisplay.php?f=42 to get information. And look through merlin's wiki to learn how to install optware https://github.com/RMerl/asuswrt-merlin/wiki once optware is installed you should be able to install stunnel with 'ipkg install stunnel' unless you're in a place that requires an SSL tunnel to masq openvpn (China) or your ISP throttles openvpn you'll probably only see a decrease in performance.

Feedback from my side, Only L2TP/PPTP connections, and some OpenVPN connections on port 1194 are blocked. No issues at all with UDP/TCP port 443. Both China Telecom and China Unicom. Sorry I don't have access to other ISPs at this point, but those ones are 70% of China. Even without SSL/SSH tunnels. I don't want to go into assumptions here, but it seems to me this was a PR move, from some VPN providers that use default settings, just to bring some "new" features that we already have with Air, if you can call a non-standard port a feature. Anyway with the ability Air provides all of the users, without special "Premium" plans or other BS, the connections via SSL/SSH are simply cannot be blocked. Not in the near few years at least, unless they do some quantum computing calculation on each outgoing connection to determine the real protocol.

I am just curious if this has become problematic for our Air members in China? I will link the article below. Since the forum is not "lit up" I am sort of thinking Air is still OK in China. Feedback from users?? http://www.theregister.co.uk/2015/01/24/china_beefs_up_great_firewall_snips_off_vpn_access

This topic has been discussed in a lot of places (including: here, Tor Stack Exchange, Wilders Security, ...) so I'll keep it relatively short: "VPN over Tor" (== you >>> Tor >>> VPN >>> destination) Pro: VPN provider doesn't know who/where you are (if you paid anonymously)Pro: Less obstacles while surfing the web (fewer captchas and/or blocks)Pro: Tor offers more creative anti-firewall measures (private Tor bridges and Pluggable Transport protocols) - although SSL/SSH-tunneled VPN usually works well too (even in places like China) Con: VPN provider is able to snoop on your trafficCon: It's easier for sites to track you (one VPN provider cannot provide the same anonymity pool as the bigger Tor network)Con: Less flexible in most cases (pumping all your traffic through Tor first will add a bottleneck) "Tor over VPN" (== you >>> VPN >>> Tor >>> destination) Pro: VPN provider is unable to snoop on your (Tor) trafficPro: Your ISP / local admin / local network cannot see that you're using Tor (although this can also be achieved by using private Tor bridges and/or Pluggable Transports)Pro: Harder for sites to track you (better anonymity pool)Pro: More flexible in most cases (use Tor Browser for the web, use VPN-only for P2P, software updates, ...) Con: More obstacles while surfing the sub (captchas; sites blocking Tor) About P2P: 1. Please don't use Tor at all as P2P traffic generates high numbers of connections and large amounts of traffic; this unfairly strains the Tor network (and, in certain edge cases, might even defeat your anonymity). Read: https://www.torproject.org/docs/faq#FileSharing https://blog.torproject.org/blog/bittorrent-over-tor-isnt-good-idea 2. That means it would be best for you to go for "Tor over VPN", meaning that you do your browsing via Tor but let your P2P applications exit directly through the VPN. This also allows you to set up VPN port forwarding for these applications. 3. If you're looking for anonymous P2P, take a look at the i2p network which is designed with P2P in mind. It's not as popular as Tor though, meaning fewer users, more bugs and - I would imagine - (I haven't tried it yet) slow speeds and small number of available files.

Any provider that does this is pure garbage and should open up an office in China. Would fit in perfectly over there.

Dear AirVPN team, Thank you for your product, it proved quite helpful while in Shanghai, China last week. My challenge/problem was breaking through the Great Firewall of China. I was having sporadic connectivity problems with my own personal OpenVPN. I managed to find and download your tool during a moment when I was "unblocked" and had connectivity. My suggestion is this: Bundle in some tutorials, guides, etc... with the application itself. Everything link in the app to help we connect opened a my browser which could not open the intended web page. Your content was blocked by the Great Firewall of China. So while having connectivity problems I could not get to the very information intended to help we figure out how to fix my connectivity problems. I am not a networking guru, but I do know a few things. When I was over there, sometimes your tool could not connect and I was essentially trying "random things" in the preferences settings. If I had a little bit of help or guidance with me on my computer, I think that would have been a big plus. Thanks! P.S. Really glad I found your tool because it helped me a lot while over there! Big fan.

I am not sure how making an "undetectable" connection is better than making an SSL one. The most "scary" traffic for Internet Censorship adversaries, is the traffic they cannot correlate to a known protocol, not an "unusual" behavior like keeping a very long HTTPS connection. You can keep any HTTPS enabled site open in the background browser tab, and the exact "footprint" will be seen on DPI systems as just an SSL connection to an OpenVPN service. I can send you screenshots from both BlueCoat or Allot DPI systems, although in China they are using in-house solution made by CERNET. The issue I see with standard obfsproxy3/4 bridges, is that some poor maintained blacklist systems can add them to the list of public Tor nodes, and then we will all suffer from what is described in this topic: https://airvpn.org/topic/12340-stop-running-tor-servers-behind-airvpn Generally, since China is a very big country with many internet users, once regular SSL connections will start being blocked, the "internet" will know about really quick. It will be in major technology news the same day. I'm totally with you about the fact that maybe more obfuscation methods could be added, after all there is never "enough" to satisfy geeks like us. But every option should be considered 100 times before, in order to see all the possible implications. Some providers offer tunneling via ICMP and DNS protocols as well, that can also work in highly restricted networks in many cases. Regards

Hi! Since sometimes I faced the same problem, the best solution for me was Tor > AirVPN. The recent changes in the Tor bridges infrastructure in 2014 made a clear improvement over existing OpenVPN patches, such as the Xor patch https://github.com/clayface/openvpn_xorpatch and OpenVPN obfuscation patch https://github.com/siren1117/openvpn-obfuscation-release I can confirm (from internal tests that I conducted) that the Meek pluggable transport was working much better for me, than any other custom patches, that had to be supported by VPN provider as well. https://www.torproject.org/docs/pluggable-transports https://github.com/arlolra/meek Meek (Google/Amazon/Azure SNI obfuscation) performed far better than those obsolete obfs3 patches, and considering the fact that your ISP sees those main companies in the SSL handshake, can even make your QoS score higher, in case your ISP uses DPI in order to shape traffic, such as most cases outside US/EU. You will have an extra anonymity layer, as well as -immediate- availability, since it's only up to you to create such bridge. P.S. If you are connecting from Mainland China, the overhead of the Tor network will be almost not noticable, since the home ISP connections are capped at 5Mbit/sec max anyway. You might get an extra 200msec latency, though. Also, both SSL Tunnel and SSH Tunnel to AIrVPN servers work from China without DPI triggers, at the moment. I know that it seems logical that "unusual long singular HTTPS Session showing up" looks obvious if you do manual traffic analysis, but again, at least now there are no DPI devices that we are aware of, that keep such extra metadata states, like the duration of an HTTPS connection. It is a little hard to implement, since then every connection would have to be logged for it's entire time, and not only during its initial establishment. I doubt we will see that soon, on such massive deployment like a whole continent. Regards

dear Airvpn Team id like to let you know about obfsproxy vs ssl , you should switch to obfsproxy with obfs3 support , this is a much better way to obfuscate the openvpn connection from DPI, so your ISP cant notice the difference between your regular net activity and usage of a VPN, since SSL aka Stunnel has the issue of being noticeable due to it being a HTTPS session but it would flag up per DPI due to an unusual long singular HTTPS Session showing up , you see so its far from perfect , mind you China is working on improving the DPI sides of things since they hate people using VPNs but theyre not the only ones and we should be prepared , as so it can only be a positive thing to do not to mention with all the future proofing and so on seeing as Team Tor is constantly developing new plugins for obfsproxy such as the much anticipated Scramblesuit plugin that should take care of DPI for good , but that one is currently in testing phase , so let me know what you guys think i think this is the way to go forward from here on out as should any trustworthy VPN provider that has its users privacy and security in mind, thank you

Log files below. I'm using VPN through SSH as I'm based in China. 2014.12.06 21:27:19 - AirVPN client version: 2.7, System: OSX, Architecture: x64 . 2014.12.06 21:27:19 - Reading options from /Users/XXXXX/.airvpn/AirVPN.xml. 2014.12.06 21:27:19 - Data Path: /Users/XXXXX/.airvpn. 2014.12.06 21:27:19 - App Path: /Applications/AirVPN.app/Contents/MacOS. 2014.12.06 21:27:19 - Executable Path: /Applications/AirVPN.app/Contents/MacOS/AirVPN. 2014.12.06 21:27:19 - Command line arguments:. 2014.12.06 21:27:20 - Updating systems & servers data .... 2014.12.06 21:27:20 - Operating System: Unix 14.0.0.0 - Darwin XXXXXs-MacBook-Pro.local 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64I 2014.12.06 21:27:20 - OpenVPN Driver - ExpectedI 2014.12.06 21:27:20 - OpenVPN - Version: OpenVPN 2.3.4 (/Applications/AirVPN.app/Contents/MacOS/openvpn)I 2014.12.06 21:27:20 - SSH - Version: OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011 (/usr/bin/ssh)I 2014.12.06 21:27:20 - SSL - Version: stunnel 5.06 (/Applications/AirVPN.app/Contents/MacOS/stunnel)I 2014.12.06 21:27:20 - IPV6: AvailableW 2014.12.06 21:27:20 - Recovery. Unexpected crash?I 2014.12.06 21:27:20 - DNS of a network adapter restored to original settings (Bluetooth DUN)I 2014.12.06 21:27:20 - DNS of a network adapter restored to original settings (Wi-Fi)I 2014.12.06 21:27:20 - DNS of a network adapter restored to original settings (Thunderbolt Bridge)I 2014.12.06 21:27:20 - Session starting.! 2014.12.06 21:27:20 - Checking environment! 2014.12.06 21:27:20 - Retrieving manifest. 2014.12.06 21:27:30 - Updating systems & servers data ..., 1° try failed (The request timed out). 2014.12.06 21:27:34 - Systems & servers data update completed! 2014.12.06 21:27:34 - Checking authorization .... 2014.12.06 21:27:44 - Checking authorization ..., 1° try failed (The request timed out)! 2014.12.06 21:27:46 - Connecting to Pavonis (United States, Chicago, Illinois). 2014.12.06 21:27:46 - SSH > OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011. 2014.12.06 21:27:46 - SSH > debug1: Reading configuration data /etc/ssh_config. 2014.12.06 21:27:46 - SSH > debug1: /etc/ssh_config line 20: Applying options for *. 2014.12.06 21:27:46 - SSH > debug1: Connecting to 149.255.33.156 [149.255.33.156] port 22.. 2014.12.06 21:27:47 - SSH > debug1: Connection established.. 2014.12.06 21:27:47 - SSH > debug1: permanently_set_uid: 501/20. 2014.12.06 21:27:47 - SSH > debug1: identity file /Users/XXXXX/.airvpn/1c85d7141445efef107ef41549857f055f92ff9bb0644cfbd07ad4647fc24679.tmp.key type -1. 2014.12.06 21:27:47 - SSH > debug1: identity file /Users/XXXXX/.airvpn/1c85d7141445efef107ef41549857f055f92ff9bb0644cfbd07ad4647fc24679.tmp.key-cert type -1. 2014.12.06 21:27:47 - SSH > debug1: Enabling compatibility mode for protocol 2.0. 2014.12.06 21:27:47 - SSH > debug1: Local version string SSH-2.0-OpenSSH_6.2. 2014.12.06 21:27:48 - SSH > debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4+deb7u2. 2014.12.06 21:27:48 - SSH > debug1: match: OpenSSH_6.0p1 Debian-4+deb7u2 pat OpenSSH*. 2014.12.06 21:27:48 - SSH > debug1: SSH2_MSG_KEXINIT sent. 2014.12.06 21:27:49 - SSH > debug1: SSH2_MSG_KEXINIT received. 2014.12.06 21:27:49 - SSH > debug1: kex: server->client aes128-ctr hmac-md5 none. 2014.12.06 21:27:49 - SSH > debug1: kex: client->server aes128-ctr hmac-md5 none. 2014.12.06 21:27:49 - SSH > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent. 2014.12.06 21:27:49 - SSH > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP. 2014.12.06 21:27:51 - SSH > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent. 2014.12.06 21:27:51 - SSH > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY. 2014.12.06 21:27:52 - SSH > debug1: Server host key: RSA 86:7d:6a:e1:3c:9e:ff:78:0a:1d:0d:01:9b:13:df:55. 2014.12.06 21:27:52 - SSH > Warning: Permanently added '149.255.33.156' (RSA) to the list of known hosts.. 2014.12.06 21:27:52 - SSH > debug1: ssh_rsa_verify: signature correct. 2014.12.06 21:27:52 - SSH > debug1: SSH2_MSG_NEWKEYS sent. 2014.12.06 21:27:52 - SSH > debug1: expecting SSH2_MSG_NEWKEYS. 2014.12.06 21:27:52 - SSH > debug1: SSH2_MSG_NEWKEYS received. 2014.12.06 21:27:52 - SSH > debug1: Roaming not allowed by server. 2014.12.06 21:27:52 - SSH > debug1: SSH2_MSG_SERVICE_REQUEST sent. 2014.12.06 21:27:55 - SSH > debug1: SSH2_MSG_SERVICE_ACCEPT received. 2014.12.06 21:27:57 - SSH > debug1: Authentications that can continue: publickey,password. 2014.12.06 21:27:57 - SSH > debug1: Next authentication method: publickey. 2014.12.06 21:27:57 - SSH > debug1: Trying private key: /Users/XXXXX/.airvpn/1c85d7141445efef107ef41549857f055f92ff9bb0644cfbd07ad4647fc24679.tmp.key. 2014.12.06 21:27:57 - SSH > debug1: read PEM private key done: type RSA. 2014.12.06 21:27:58 - SSH > debug1: Authentication succeeded (publickey).. 2014.12.06 21:27:58 - SSH > Authenticated to 149.255.33.156 ([149.255.33.156]:22).. 2014.12.06 21:27:58 - SSH > debug1: Local connections to LOCALHOST:61650 forwarded to remote address 127.0.0.1:2018! 2014.12.06 21:27:58 - Disconnecting. 2014.12.06 21:27:58 - OpenVPN > OpenVPN 2.3.4 x86_64-apple-darwin13.4.0 [sSL (OpenSSL)] [LZO] [MH] [iPv6] built on Oct 18 2014. 2014.12.06 21:27:58 - SSH > debug1: Local forwarding listening on ::1 port 61650.. 2014.12.06 21:27:58 - OpenVPN > library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.05. 2014.12.06 21:27:58 - SSH > debug1: channel 0: new [port listener]. 2014.12.06 21:27:58 - Auto retry with another port.. 2014.12.06 21:27:59 - SSH > debug1: Local forwarding listening on 127.0.0.1 port 61650.. 2014.12.06 21:27:59 - OpenVPN > MANAGEMENT: Socket bind failed on local address [AF_INET]127.0.0.1:3103: Address already in use. 2014.12.06 21:27:59 - Connection terminated.. 2014.12.06 21:27:59 - SSH > debug1: channel 1: new [port listener]. 2014.12.06 21:27:59 - OpenVPN > Exiting due to fatal error. 2014.12.06 21:27:59 - SSH > debug1: Requesting no-more-sessions@openssh.com. 2014.12.06 21:27:59 - SSH > debug1: Entering interactive session.! 2014.12.06 21:28:02 - Waiting for latency tests (59 to go)! 2014.12.06 21:28:03 - Waiting for latency tests (58 to go)! 2014.12.06 21:28:04 - Waiting for latency tests (57 to go)! 2014.12.06 21:28:04 - Waiting for latency tests (56 to go)! 2014.12.06 21:28:05 - Waiting for latency tests (55 to go)! 2014.12.06 21:28:05 - Waiting for latency tests (53 to go)! 2014.12.06 21:28:06 - Waiting for latency tests (51 to go)! 2014.12.06 21:28:06 - Waiting for latency tests (49 to go)! 2014.12.06 21:28:07 - Waiting for latency tests (46 to go)! 2014.12.06 21:28:07 - Waiting for latency tests (43 to go)! 2014.12.06 21:28:08 - Waiting for latency tests (40 to go)! 2014.12.06 21:28:08 - Waiting for latency tests (36 to go)! 2014.12.06 21:28:09 - Waiting for latency tests (32 to go)! 2014.12.06 21:28:09 - Waiting for latency tests (28 to go)! 2014.12.06 21:28:10 - Waiting for latency tests (23 to go)! 2014.12.06 21:28:11 - Waiting for latency tests (18 to go)! 2014.12.06 21:28:11 - Waiting for latency tests (15 to go)! 2014.12.06 21:28:11 - Waiting for latency tests (12 to go)! 2014.12.06 21:28:12 - Waiting for latency tests (7 to go)! 2014.12.06 21:28:12 - Checking authorization .... 2014.12.06 21:28:22 - Checking authorization ..., 1° try failed (The request timed out)! 2014.12.06 21:28:24 - Connecting to Pavonis (United States, Chicago, Illinois). 2014.12.06 21:28:25 - SSH > OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011. 2014.12.06 21:28:25 - SSH > debug1: Reading configuration data /etc/ssh_config. 2014.12.06 21:28:25 - SSH > debug1: /etc/ssh_config line 20: Applying options for *. 2014.12.06 21:28:25 - SSH > debug1: Connecting to 149.255.33.156 [149.255.33.156] port 22.. 2014.12.06 21:28:25 - SSH > debug1: Connection established.. 2014.12.06 21:28:25 - SSH > debug1: permanently_set_uid: 501/20. 2014.12.06 21:28:26 - SSH > debug1: identity file /Users/XXXXX/.airvpn/1e97e853a1473d38d65f1ac6ca33e33175f0ef8e4507885928fcde98b8c3a336.tmp.key type -1. 2014.12.06 21:28:26 - SSH > debug1: identity file /Users/XXXXX/.airvpn/1e97e853a1473d38d65f1ac6ca33e33175f0ef8e4507885928fcde98b8c3a336.tmp.key-cert type -1. 2014.12.06 21:28:26 - SSH > debug1: Enabling compatibility mode for protocol 2.0. 2014.12.06 21:28:26 - SSH > debug1: Local version string SSH-2.0-OpenSSH_6.2. 2014.12.06 21:28:26 - SSH > debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4+deb7u2. 2014.12.06 21:28:26 - SSH > debug1: match: OpenSSH_6.0p1 Debian-4+deb7u2 pat OpenSSH*. 2014.12.06 21:28:27 - SSH > debug1: SSH2_MSG_KEXINIT sent. 2014.12.06 21:28:27 - SSH > debug1: SSH2_MSG_KEXINIT received. 2014.12.06 21:28:27 - SSH > debug1: kex: server->client aes128-ctr hmac-md5 none. 2014.12.06 21:28:28 - SSH > debug1: kex: client->server aes128-ctr hmac-md5 none. 2014.12.06 21:28:28 - SSH > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent. 2014.12.06 21:28:28 - SSH > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP. 2014.12.06 21:28:29 - SSH > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent. 2014.12.06 21:28:29 - SSH > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY. 2014.12.06 21:28:30 - SSH > debug1: Server host key: RSA 86:7d:6a:e1:3c:9e:ff:78:0a:1d:0d:01:9b:13:df:55. 2014.12.06 21:28:30 - SSH > Warning: Permanently added '149.255.33.156' (RSA) to the list of known hosts.. 2014.12.06 21:28:30 - SSH > debug1: ssh_rsa_verify: signature correct. 2014.12.06 21:28:30 - SSH > debug1: SSH2_MSG_NEWKEYS sent. 2014.12.06 21:28:30 - SSH > debug1: expecting SSH2_MSG_NEWKEYS. 2014.12.06 21:28:30 - SSH > debug1: SSH2_MSG_NEWKEYS received. 2014.12.06 21:28:30 - SSH > debug1: Roaming not allowed by server. 2014.12.06 21:28:30 - SSH > debug1: SSH2_MSG_SERVICE_REQUEST sent. 2014.12.06 21:28:32 - SSH > debug1: SSH2_MSG_SERVICE_ACCEPT received. 2014.12.06 21:28:33 - SSH > debug1: Authentications that can continue: publickey,password. 2014.12.06 21:28:33 - SSH > debug1: Next authentication method: publickey. 2014.12.06 21:28:33 - SSH > debug1: Trying private key: /Users/XXXXX/.airvpn/1e97e853a1473d38d65f1ac6ca33e33175f0ef8e4507885928fcde98b8c3a336.tmp.key. 2014.12.06 21:28:34 - SSH > debug1: read PEM private key done: type RSA. 2014.12.06 21:28:34 - SSH > debug1: Authentication succeeded (publickey).. 2014.12.06 21:28:34 - SSH > Authenticated to 149.255.33.156 ([149.255.33.156]:22).. 2014.12.06 21:28:35 - OpenVPN > OpenVPN 2.3.4 x86_64-apple-darwin13.4.0 [sSL (OpenSSL)] [LZO] [MH] [iPv6] built on Oct 18 2014. 2014.12.06 21:28:35 - SSH > debug1: Local connections to LOCALHOST:45934 forwarded to remote address 127.0.0.1:2018. 2014.12.06 21:28:35 - OpenVPN > library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.05. 2014.12.06 21:28:35 - SSH > debug1: Local forwarding listening on ::1 port 45934.. 2014.12.06 21:28:35 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3104. 2014.12.06 21:28:35 - SSH > debug1: channel 0: new [port listener]. 2014.12.06 21:28:35 - OpenVPN > Control Channel Authentication: tls-auth using INLINE static key file. 2014.12.06 21:28:35 - SSH > debug1: Local forwarding listening on 127.0.0.1 port 45934.. 2014.12.06 21:28:35 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication. 2014.12.06 21:28:35 - SSH > debug1: channel 1: new [port listener]. 2014.12.06 21:28:35 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication. 2014.12.06 21:28:35 - SSH > debug1: Requesting no-more-sessions@openssh.com. 2014.12.06 21:28:35 - OpenVPN > Socket Buffers: R=[131072->65536] S=[131072->65536]. 2014.12.06 21:28:35 - SSH > debug1: Entering interactive session.. 2014.12.06 21:28:35 - OpenVPN > Attempting to establish TCP connection with [AF_INET]127.0.0.1:45934 [nonblock]. 2014.12.06 21:28:35 - SSH > debug1: Connection to port 45934 forwarding to 127.0.0.1 port 2018 requested.. 2014.12.06 21:28:35 - SSH > debug1: channel 2: new [direct-tcpip]. 2014.12.06 21:28:35 - SSH > debug1: Remote: Pty allocation disabled.. 2014.12.06 21:28:35 - SSH > debug1: Remote: X11 forwarding disabled.. 2014.12.06 21:28:36 - OpenVPN > TCP connection established with [AF_INET]127.0.0.1:45934. 2014.12.06 21:28:36 - SSH > debug1: Remote: Forced command.. 2014.12.06 21:28:36 - OpenVPN > TCPv4_CLIENT link local: [undef]. 2014.12.06 21:28:36 - OpenVPN > TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:45934. 2014.12.06 21:28:38 - OpenVPN > TLS: Initial packet from [AF_INET]127.0.0.1:45934, sid=d9028d03 91da3f4a. 2014.12.06 21:28:59 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org. 2014.12.06 21:28:59 - OpenVPN > Validating certificate key usage. 2014.12.06 21:28:59 - OpenVPN > ++ Certificate has key usage 00a0, expects 00a0. 2014.12.06 21:28:59 - OpenVPN > VERIFY KU OK. 2014.12.06 21:28:59 - OpenVPN > Validating certificate extended key usage. 2014.12.06 21:28:59 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication. 2014.12.06 21:28:59 - OpenVPN > VERIFY EKU OK. 2014.12.06 21:28:59 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org. 2014.12.06 21:29:22 - OpenVPN > Connection reset, restarting [0]. 2014.12.06 21:29:22 - OpenVPN > SIGUSR1[soft,connection-reset] received, process restarting! 2014.12.06 21:29:22 - Disconnecting. 2014.12.06 21:29:22 - OpenVPN > Restart pause, 5 second(s). 2014.12.06 21:29:23 - Connection terminated.! 2014.12.06 21:29:26 - Checking authorization .... 2014.12.06 21:29:36 - Checking authorization ..., 1° try failed (The request timed out)! 2014.12.06 21:29:39 - Connecting to Pavonis (United States, Chicago, Illinois). 2014.12.06 21:29:39 - SSH > OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011. 2014.12.06 21:29:39 - SSH > debug1: Reading configuration data /etc/ssh_config. 2014.12.06 21:29:39 - SSH > debug1: /etc/ssh_config line 20: Applying options for *. 2014.12.06 21:29:39 - SSH > debug1: Connecting to 149.255.33.156 [149.255.33.156] port 22.. 2014.12.06 21:29:40 - SSH > debug1: Connection established.. 2014.12.06 21:29:40 - SSH > debug1: permanently_set_uid: 501/20. 2014.12.06 21:29:40 - SSH > debug1: identity file /Users/XXXXX/.airvpn/28ba73950155f600af8ea87ce9db7686474c1e32a213e42c858200ff65aba095.tmp.key type -1. 2014.12.06 21:29:40 - SSH > debug1: identity file /Users/XXXXX/.airvpn/28ba73950155f600af8ea87ce9db7686474c1e32a213e42c858200ff65aba095.tmp.key-cert type -1. 2014.12.06 21:29:40 - SSH > debug1: Enabling compatibility mode for protocol 2.0. 2014.12.06 21:29:40 - SSH > debug1: Local version string SSH-2.0-OpenSSH_6.2. 2014.12.06 21:29:41 - SSH > debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4+deb7u2. 2014.12.06 21:29:41 - SSH > debug1: match: OpenSSH_6.0p1 Debian-4+deb7u2 pat OpenSSH*. 2014.12.06 21:29:41 - SSH > debug1: SSH2_MSG_KEXINIT sent. 2014.12.06 21:29:43 - SSH > debug1: SSH2_MSG_KEXINIT received. 2014.12.06 21:29:43 - SSH > debug1: kex: server->client aes128-ctr hmac-md5 none. 2014.12.06 21:29:43 - SSH > debug1: kex: client->server aes128-ctr hmac-md5 none. 2014.12.06 21:29:43 - SSH > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent. 2014.12.06 21:29:43 - SSH > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP. 2014.12.06 21:29:45 - SSH > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent. 2014.12.06 21:29:45 - SSH > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY. 2014.12.06 21:29:46 - SSH > debug1: Server host key: RSA 86:7d:6a:e1:3c:9e:ff:78:0a:1d:0d:01:9b:13:df:55. 2014.12.06 21:29:46 - SSH > Warning: Permanently added '149.255.33.156' (RSA) to the list of known hosts.. 2014.12.06 21:29:47 - SSH > debug1: ssh_rsa_verify: signature correct. 2014.12.06 21:29:47 - SSH > debug1: SSH2_MSG_NEWKEYS sent. 2014.12.06 21:29:47 - SSH > debug1: expecting SSH2_MSG_NEWKEYS. 2014.12.06 21:29:47 - SSH > debug1: SSH2_MSG_NEWKEYS received. 2014.12.06 21:29:47 - SSH > debug1: Roaming not allowed by server. 2014.12.06 21:29:47 - SSH > debug1: SSH2_MSG_SERVICE_REQUEST sent. 2014.12.06 21:29:48 - SSH > debug1: SSH2_MSG_SERVICE_ACCEPT received. 2014.12.06 21:29:50 - SSH > debug1: Authentications that can continue: publickey,password. 2014.12.06 21:29:50 - SSH > debug1: Next authentication method: publickey. 2014.12.06 21:29:50 - SSH > debug1: Trying private key: /Users/XXXXX/.airvpn/28ba73950155f600af8ea87ce9db7686474c1e32a213e42c858200ff65aba095.tmp.key. 2014.12.06 21:29:50 - SSH > debug1: read PEM private key done: type RSA. 2014.12.06 21:29:51 - SSH > debug1: Authentication succeeded (publickey).. 2014.12.06 21:29:51 - SSH > Authenticated to 149.255.33.156 ([149.255.33.156]:22).. 2014.12.06 21:29:51 - OpenVPN > OpenVPN 2.3.4 x86_64-apple-darwin13.4.0 [sSL (OpenSSL)] [LZO] [MH] [iPv6] built on Oct 18 2014. 2014.12.06 21:29:51 - SSH > debug1: Local connections to LOCALHOST:34597 forwarded to remote address 127.0.0.1:2018. 2014.12.06 21:29:51 - OpenVPN > library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.05. 2014.12.06 21:29:51 - SSH > debug1: Local forwarding listening on ::1 port 34597.. 2014.12.06 21:29:51 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3104. 2014.12.06 21:29:51 - SSH > debug1: channel 0: new [port listener]. 2014.12.06 21:29:51 - OpenVPN > Control Channel Authentication: tls-auth using INLINE static key file. 2014.12.06 21:29:51 - SSH > debug1: Local forwarding listening on 127.0.0.1 port 34597.. 2014.12.06 21:29:51 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication. 2014.12.06 21:29:51 - SSH > debug1: channel 1: new [port listener]. 2014.12.06 21:29:51 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication. 2014.12.06 21:29:51 - SSH > debug1: Requesting no-more-sessions@openssh.com. 2014.12.06 21:29:51 - OpenVPN > Socket Buffers: R=[131072->65536] S=[131072->65536]. 2014.12.06 21:29:51 - SSH > debug1: Entering interactive session.. 2014.12.06 21:29:51 - OpenVPN > Attempting to establish TCP connection with [AF_INET]127.0.0.1:34597 [nonblock]. 2014.12.06 21:29:51 - SSH > debug1: Connection to port 34597 forwarding to 127.0.0.1 port 2018 requested.. 2014.12.06 21:29:51 - SSH > debug1: channel 2: new [direct-tcpip]. 2014.12.06 21:29:51 - SSH > debug1: Remote: Pty allocation disabled.. 2014.12.06 21:29:51 - SSH > debug1: Remote: X11 forwarding disabled.. 2014.12.06 21:29:51 - SSH > debug1: Remote: Forced command.. 2014.12.06 21:29:52 - OpenVPN > TCP connection established with [AF_INET]127.0.0.1:34597. 2014.12.06 21:29:52 - OpenVPN > TCPv4_CLIENT link local: [undef]. 2014.12.06 21:29:52 - OpenVPN > TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:34597. 2014.12.06 21:29:54 - OpenVPN > TLS: Initial packet from [AF_INET]127.0.0.1:34597, sid=37aa5366 a42c5fb9. 2014.12.06 21:30:04 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org. 2014.12.06 21:30:04 - OpenVPN > Validating certificate key usage. 2014.12.06 21:30:04 - OpenVPN > ++ Certificate has key usage 00a0, expects 00a0. 2014.12.06 21:30:04 - OpenVPN > VERIFY KU OK. 2014.12.06 21:30:04 - OpenVPN > Validating certificate extended key usage. 2014.12.06 21:30:04 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication. 2014.12.06 21:30:04 - OpenVPN > VERIFY EKU OK. 2014.12.06 21:30:04 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org. 2014.12.06 21:30:22 - OpenVPN > Connection reset, restarting [0]. 2014.12.06 21:30:22 - OpenVPN > SIGUSR1[soft,connection-reset] received, process restarting. 2014.12.06 21:30:22 - OpenVPN > Restart pause, 5 second(s)! 2014.12.06 21:30:22 - Disconnecting. 2014.12.06 21:30:22 - Connection terminated.! 2014.12.06 21:30:25 - Checking authorization .... 2014.12.06 21:30:36 - Checking authorization ..., 1° try failed (The request timed out)! 2014.12.06 21:30:38 - Connecting to Pavonis (United States, Chicago, Illinois). 2014.12.06 21:30:38 - SSH > OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011. 2014.12.06 21:30:38 - SSH > debug1: Reading configuration data /etc/ssh_config. 2014.12.06 21:30:38 - SSH > debug1: /etc/ssh_config line 20: Applying options for *. 2014.12.06 21:30:38 - SSH > debug1: Connecting to 149.255.33.156 [149.255.33.156] port 22.. 2014.12.06 21:30:40 - SSH > debug1: Connection established.. 2014.12.06 21:30:40 - SSH > debug1: permanently_set_uid: 501/20. 2014.12.06 21:30:40 - SSH > debug1: identity file /Users/XXXXX/.airvpn/2ac1038dff731d0e4cb4e307a9681c2afe41c31882878b4ecc9d39c1ff2883a6.tmp.key type -1. 2014.12.06 21:30:40 - SSH > debug1: identity file /Users/XXXXX/.airvpn/2ac1038dff731d0e4cb4e307a9681c2afe41c31882878b4ecc9d39c1ff2883a6.tmp.key-cert type -1. 2014.12.06 21:30:40 - SSH > debug1: Enabling compatibility mode for protocol 2.0. 2014.12.06 21:30:40 - SSH > debug1: Local version string SSH-2.0-OpenSSH_6.2. 2014.12.06 21:30:41 - SSH > debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4+deb7u2. 2014.12.06 21:30:41 - SSH > debug1: match: OpenSSH_6.0p1 Debian-4+deb7u2 pat OpenSSH*. 2014.12.06 21:30:41 - SSH > debug1: SSH2_MSG_KEXINIT sent. 2014.12.06 21:30:42 - SSH > debug1: SSH2_MSG_KEXINIT received. 2014.12.06 21:30:42 - SSH > debug1: kex: server->client aes128-ctr hmac-md5 none. 2014.12.06 21:30:42 - SSH > debug1: kex: client->server aes128-ctr hmac-md5 none. 2014.12.06 21:30:42 - SSH > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent. 2014.12.06 21:30:42 - SSH > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP. 2014.12.06 21:30:44 - SSH > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent. 2014.12.06 21:30:44 - SSH > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

Hi, I'd like to offer some suggestions for improvement of the client (Eddie). Although the product works, there are a few niggling issues I have seen many times over that have caused me to use a third party client over Eddie. So you know where I am coming from, I am currently travelling the world and using AirVPN exclusively as my VPN provider mainly to protect myself from the many unknown networks I have been connecting to over the last 7 months. I use the service on my ipad, mac osx (10.10), and android phone (side note, please increase the number of connections you are allowed simultaneously!). I have been using Eddie over many different network environments, slow, fast, intermittent, lots of packet loss etc, on many different settings, SSL tunnel while in China, UDP , TCP on differing ports. As I say, here are a few suggestions that I think you should incorporate into the client. As a side effect of these problems I no longer use it as my main client, opting only to use it for its ease of tunnelling capabilities. - Limit or have the option to stop authentication attempts: When on a shoddy network (which is quite frequent for me), this greatly increases the time it takes to actually get a connection. Not great when you just want to quickly check emails... This check does not exist when using a third party client such as TunnelBlick. - Provide an option to use resolved server names: Give advanced users the option to download/update a list of server IPs to use instead of resolving server names. This helps with some restrictive networks (captive portals where DNS is allowed, make a great UDP 53 tunnel ) - Allow users to update the list of servers when they require: This stops the server list from being corrupted and also allows finer grain control - Be a little clearer as to the algo for choosing a server when 'connect to recommended server' is selected: I cannot work out what the reasoning is for choice of servers. Is it based around latency? If so, tests may be made against ALL servers before a connection can be made, so doesn't this make connection to the service EVEN slower? Happy to be shot down for any of the above suggestions or to provide better examples where required Cheers!

Hi everyone A friend of mine that is also a AirVPN user and in China at the moment cannot connect. There are two problems: - He cannot select SSL Tunnel in the Protocols (is deactivated, grey) --> he uses ssh port 80 at the moment - When he tries to connect to a server, he get the error "OpenVPN not found" He's on OS X Yosemite and uses the latest Eddie version. This is his log: thx for your help.

Hello, You can use the SSH Tunnel application (links below) with OpenVPN. This will defeat the Great Firewall as well as China Unicom's total ban on OpenVPN. You do not need to be rooted either. From the config generator on your Android device, click Mac OS X as your operating system, then choose your regions/servers, and finally choose the profiles for SSH. Import the OpenVPN file into OpenVPN for Android. Then, copy the values from the xx.sh config to the SSH Tunnel application. If anyone wants a full guide, please post the request on this form as well as if you will be using it day to day. This is complex so many of you may not know which values correspond to which entry's in the SSH Tunnel app. Note: You may need the beta version depending on your Android phone. The file browser sometimes does not work. The beta version if only available from Google Code however. Also, try using a bunch of different ports as well. Some people suggest that China Mobile blocked port 22 for everything, but any other port works fine. Port 22 should work on China Unicom, however. If it stops working one day, just change the port to 53 or 80. Hope this helps! startssl2 Play Store: https://play.google.com/store/apps/details?id=org.sshtunnel&hl=en https://code.google.com/p/sshtunnel/downloads/list