Search the Community

Since it is not very easy to use a VPN from countries like Iran a recorded a tutorial on how to use airvpn from these countries: https://usefulvid.com/bypass-the-persian-and-chinese-firewall-by-using-airvpn-with-ssl/ The videos are hosted on my website and on youtube. The reason is that it is not possible to access youtube from Iran. https://youtu.be/jl8I2-GQF94 It would be nice if you could share this with your friends in Iran, China, Turkey, Russia, UAE, Saudi Arabia and provide feedback if this method works. You can also download this video from my website to make it easier to share and spread the word. A video on how to use stunnel on android will follow and also published on this site. Update on 6.1.2018: The Video for Android is finally published: https://www.youtube.com/watch?v=zwf5JI6t0TI For all who suffer from youtube censorship this is the link for you: https://usefulvid.com/bypass-the-persian-and-chinese-firewall-by-using-airvpn-with-ssl/ Second Video on the page

Greetings all, it's been noted in recent months that using Air VPN in the UAE has become more difficult. Currently only encapsulated sessions using SSL or SSH work, although there seems to be some DPI taking place that is allowing the ISPs to throttle traffic. Has anyone else had this issue and addressed it?

I am currently in China and like to share my experience with airvpn. Findings Every Hotel Wifi blocks VPN differently Tor (orbot) always works fine Airvpn is a pain on Android stunnel is complicated to install the own android app does not come with predefined profiles the config generator is not mobile friendly I tried to use stunnel on Windows -> eddie has a problem with usernames with a vowel mutation and fails to establish a connection Protocols and IPs Some IPs from AirVPN Servers seem to be completely blocked. E.g. Zuben: IP1 fails completly (tested on UDP 443 / SSH 22) IP2 on UDP 443 works fine IP2 on UDP 1194 works fine Ping to Zuben IP1 fails Ping to IP2 works fine The weired thing is that I am running 2 VPN servers in my home network. In the actual hotel both are blocked entirely. What I do not get is why zuben on 1194 works but my VPN in the home network (on 1194 and also on 1195) fails. I can't even ping my IP (dyndns). The DNS resolution works fine but no connection is possible. It can only be explained if all private network IPs are blocked. I tried a second private IP to connect to and this also failed. For the second ip a ping was possible but VPN on tcp/443 failed. There is no real consistent image I get.... The second IP was never used in china before. Some thoughts about Eddie A feature which detects blocked servers (by a ping test?) would be great. Eddie should be capable of choosing the best IP and protocol by itself. The chinese Firewall is able to detect openVPN connections it would be a could idea to reserve one IP (nr. 4?) only for stunnel and ssh connections. In the actual situation I am able to connect via 1194/udp to IP4. If the chinese firewall can detect a VPN it will block the whole IP4 and also stunnel and ssh is not possible any more. It is a very good idea to develop eddie for android. it should be able to use ssl/ssh connections and all possible IPs and protocols should be available without manual download

Hello, I currently was at a hotspot in a business. I tried to connect to AirVPN directly*, and wasn't able to. A competitor to AirVPN was able to. If I'm on an hotspot behind Microsoft Forefront (not sure I got the name right), how can I connect directly to AirVPN? Somewhat related, does AirVPN provide servers with connectivity on port 1194? (*) using stunnel as a middleman worked.

The isp here is killing my airvpn vpn connections right now. I want to know how to avoid this. The alternatives you have to use a ssl tunnel are not working and have never worked for me. Can you help because your service is not working for me, not your fault but their routers are confgured to detect the encryption of open vpn.

I'm with Virgin Media in the UK, on 160/12 cable. Last year I had a spate of low speed (3MB/sec hard cap) which I initially blamed on throttling of OpenVPN as I could hit full speed on my naked ISP connection. After some investigation I found it was actually a bug in the ISP supplied router, so I switched to my own and the problem went away. Lately however, I'm having a hard speed cap problem and it really looks like issues caused by either VM's use of DPI and/or OpenVPN throttling/shaping at ISP level. VM operate a whitelist for shaping, so unless the protocol is whitelisted it's shaped by default. VM categorically and publicly deny any form of throttling, shaping or interference with OpenVPN connections. I've been using an Ubuntu torrent as a speed benchmark as it's multi-threaded, consistently very fast, and can be used off-VPN without fear of legal issues. I have tested every port and protocol in Eddie, as well as via Viscosity (to rule out Eddie issues). I also tried the same tests with several other well respected VPN providers with good networks and the results were consistent across them all, Air included. Note that I am using MB/sec in its proper format, meaning megabytes per second. 1MB/sec = 8Mbps. All results are for the same Ubuntu 15.04 x64 torrent downloaded in the latest qBittorrent v3.2.3 on Mac OS X (also verified on Linux, PCBSD and Windows 8.1 Pro). As well as checking against multiple VPN companies, multiple OpenVPN software and multiple operating systems, I also reproduced the results on multiple machines (mid 2012 MacBook Pro and my FX8350 / 16GB DDR3 / Samsung Evo 850 sad / Radeon R9 380 gfx desktop). I repeated the tests with several ethernet cables (to rule out cable issues), as well as with *machine* > router > modem and *machine* > modem (to rule out firmware or routing issues). Every time, regardless of the variable, the results below were consistent. ISP : 19MB/sec OpenVPN 53 UDP : 2MB/sec OpenVPN (all other ports in turn) UDP : 5MB/sec OpenVPN (all ports) TCP : 4 - 5 MB/sec OpenVPN + SSH 22 : 2MB/sec OpenVPN + SSH 80 (or 53) : 13 - 18 MB/sec (lower in peak times, high off-peak) OpenVPN + SSL 443 : 13 - 18 MB/sec (lower in peak times, high off-peak) As we can see, generally SSL and SSH masking the OpenVPN connection allows almost full line speed (minus the encryption overheads). That's great. As soon as it's a bare OpenVPN connection the speeds cap out at around 33% of what they should be. Bare OpenVPN TCP is a little slower than UDP (as you'd expect) but otherwise in accordance with the general 5MB/sec cap experienced on UDP. The only exceptions are UDP:53 and SSH:22 which are both heavily restricted to around 2MB/sec. Now to my mind, knowing what I do of VM's shaping and DPI systems, this would only make sense if they were interfering with OpenVPN either by purposefully throttling it, or else their DPI system is messing up the connection. They further seem to restrict SSH:22 and UDP:53 by protocol but not by port. This actually makes sense, as all other Eddie combinations are quite random whereas SSH:22 (SSH) and UDP:53 (DNS) are established network traffic protocols and thus could be singled out for listing in the shaping systems. If we reverse the protocol/port (to give SSH 53 and UDP 22) we once again obfuscate the tunnel and go back to full speeds! I also get a lot of decrypt/replay errors in the logs on every single port for 'normal' OpenVPN. As soon as I hide the OpenVPN in either SSL or SSH the errors simply don't occur. Ever. This suggests that the extra tunnel is hiding the OpenVPN tunnel from being shaped, or else the DPI process in and of itself is breaking OpenVPN and causing the packets to arrive out of order. Maybe that in and of itself can hurt speed? So there you go. Sorry for the long post but it's an interesting (if thoroughly frustrating and annoying) issue. What do you gurus think? Given I have worked to change the variables one at a time to rule out issues with AirVPN (different providers), the router and/or its firmware (direct connection to modem, bypassing router), wireless issues (used ethernet directly) and OS limits or bugs (used multiple OSs) I can't see anything is left... except issues with the ISP shaping/throttling or else their DPI breaking things. I posted a thread very similar to this in VM's support forums, but for a whole week it has gone unanswered by any staff. Interestingly it is the only thread on the forum to have been ignored. Make of that what you wish. I await your replies with interest. Thanks in advance for reading.

Hi, Is there any development going on to enable SSH or SSL tunnels on Android to avoid DPI in China? Some other providers already have this service on Android. Thanks,