Staff

Works on testmachine (Win7 x64) without problems. I think the exit confirmation is a good thing and should be enabled by default.
Advanced users could turn it of if they feel like it. Its a good feature for beginner users...

I have been using Eddie 2.2-2.4 on Windows 7 x64. I have always ensured that those three settings have the values you have described. I have never had any issues on Windows.
 
I have been using the Mac versions since it was released. With same setting's values set as mentioned. I have had a mixed experience on OSX 10.9.something. The client connects successfully when the app is first started. But if for some reason the connection is lost, it gets stuck in the connect-disconnect-reconnect loop. Doesn't always happen. Quitting the app, ensuring the Wifi DNS is not set to AirVPN DNS and starting app seems to resolve it.
 
Regarding the Exit Confirmation - Huge NO. On my Windows machine I hibernate it a lot. If AirVPN is running when the machine is put into hibernation, on resuming the Servers tab gets badly glitched. Its constantly keeps refreshing itself making it impossible to select a server. Point being I quite the app a lot. Also if I forget to quit app and I try to shutdown/restart the machine, it simply WONT proceed further till I cancel the shutdown, answer yes and try again. Very frustrating.
 
I prefer the confirmation prompt to NOT be enabled by default. If as a user I need something like this, I would ask in the forums and get redirected to the appropriate settings tab.

It is working here on Windows 8 x64.

OK I got it!
I forgot to disconnect, Eddie still running when I was shutting down.
Eddie force all your Network Interfaces to use DNS-Server xyz. When you disconnect, Eddie restore the DNS-Server to the default one. Of course it dosen't do it when you (or your OS) kill the process (e.g. Shut down).
Is it possible to tell the OS to quit an application and not to kill it?

Hello!
 
We need to understand if some advanced feature of AirVPN client can be activated by default for all users without causing issues.
We ask those who want to collaborate to do a little test:

In Menu -> Preferences -> Advanced -> General please enable
"Checking if the tunnel uses AirVPN DNS" and "Force DNS" (this last option only under Microsoft Windows)

DNS Switch mode is by default set to "Automatic", please use it in "Automatic".

If these settings work for you, please use them and confirm in this topic that they work for you.
Otherwise, if some problem occurs, please describe here the problem.
 
Finally, we have a question: without prejudice to the fact that it can be switched on or off anytime by users, do you prefer that by default the option "Exit confirmation" is on or off?

Thanks to anyone who will collaborate!
 
Kind regards
AirVPN Staff
 

No good here!
 
I tested accordingly:  First I dropped my private UFW rules to take it out of consideration.  Next I configured the client as you mentioned, which was to verify the tunnel and "automatic" in expert mode.
 
The connection was immediate and smooth using Linux 14.04.  I launched FF and went to check2ip dot com and ran a test.  My ISP's dns showed up all over the place.  Reminder; I am not using the network lock on 2.5.  Of course that ISP dns would be an issue.
 
Next I set the 2.5 client back to "renaming" in Linux instead of automatic.  I re-booted everything and still left my UFW firewall down.  I again launched FF, and this time as usual, ONLY Air dns shows up on all the tests I conduct.
 
I don't know if having the network lock OFF invalidates this test for what you want.
 
At this time I am running again with the client set to "renaming" and NOT automatic.  And as a reminder; due to my intra net concerns I have also enabled UFW again.  All is well.
 
I hope this helped because many Ubuntu users here will not be employing a UFW firewall on their own.  The automatic setting doesn't work on 14.04 for my machine.
 
I will run the exit confirmation OFF and I don't care which default you use as long as I have the option to set it how I like.

Hello,
 
Regarding exit confirmation= user choice is always best, I prefer off.
 
Have all settings enabled except enable pinger outside tunnel during connection and switch DHCP to static, working fine on W7 prox64 and W8.1.1 x64

First, about the exit confirmation I personally dont care but I can see how that would annoy some people.
 
I have been using those 3 settings above for the past 3 Eddie releases and it has always worked. Windows 7 64. I should also point out, not sure if it matters, but in addition I have "force tap interface up," "switch dhcp to static," and "checking if tunnel effectively works" also enabled.

Works under OS X 10.9.4. I've used this option with the previous client and now also with 2.5 No problems for me. 
 
On the exit confirmation question, I actually don't have a strong opinion. I rarely quit the client so I rarely see that window anyway but in principle I think I'd rest on the side of caution and leave the confirmation prompt as the default option.

I made this test earlier, and it doesn't work that way on several linux systems. I did spent some serious time solving this. The only way to avoid the disconnection/ting loop is to uncheck both options in the airvpn client. I think the openvpn set-up has to be changed to de/increase the basic and default "cheching route time" in the openvpn software.

If cookies fix the issue for you and you're a firefox user there's a tiny addon called 'cookie toggle'.
It puts a little button up next to your address bar that when pressed enables cookies with the no 3rd party option. Clicking it again disables cookies.
 
This sounds like its some sort of poorly setup bot detection script Cloudflare is running.

http://www.comedycentral.com/
Welcome to the Comedy Central homepage. Here you can find funny videos clips, games, jokes and news from our Comedy Central Insider blog and downloads from all your favorite Comedy Central shows.

Status: OK
Native: US servers.
Routing: All other servers.

Website: http://www.syfy.com/
Official site. Syfy is a media destination for imagination-based entertainment. Shows include Being Human, Face Off, Ghost Hunters, Warehouse 13, SmackDown, Eurkea, Haven, Sanctuary, Lost Girl and Original Movies.
 
 
 
Status: OK
Native: US servers.
Routing: All other servers.
Covered by NBCUniversal routing

Website: http://www.bbc.co.uk/
Breaking news, sport, TV, radio and a whole lot more. The BBC informs, educates and entertains - wherever you are, whatever your age.

Status: Not accessible
Native: none
Routing: all servers

Install OpenVPN for Android.Hosted on GitHub: https://github.com/schwabe/ics-openvpn Note: if you don't have access to Google Play Store, you can download "OpenVPN for Android" apk here: https://airvpn.org/repository/ics-openvpn-latest-stable.apk Launch your internet browser.NOTE: don't use the default Android browser because it has an unresolved bug.
Chrome and Opera have been tested by us and work.
Connect to AirVPN website, login and create the configuration files from our Config Generator.Choose Linux as platform (only direct TCP and UDP connections are supported) and finally click the "Generate" button to download it.
Downloaded .ovpn files may be imported directly into the application but the behavior depends on many factors (employed browser, files manager, Android version, etc).For simplicity's sake, we assume in this guide that you saved .ovpn generated files under the Download directory in the Android filesystem.
Open OpenVPN for Android and tap the top right "Import" button:
Click on the import button of the prompt dialog:
Browse to *.ovpn files:
Select your configuration of choice:
Confim the import with the top right button:
Click on the imported profile to connect:
Confirm the Android's security prompt dialog:
Wait for the bootstrap sequence:
The VPN tunnel is now established:
When you need to disconnect from the VPN click on the "Disconnect" button from the app's notification:
Confirm the prompt dialog:

Hello!
 
ipleak.net queries commercial MaxMind database (and we pay for it), which is wrong as well. We'll think about your suggestions and a solution!
 
Kind regards

Got OpenVPN to work on chromebook c720 that also has crouton installed.  
 
1)  Go to crouton chroot and open terminal
2)  sudo apt-get install openvpn (installed 2.3.2)
3)  Generate credentials from airvpn site (linux, UDP, server of your choice) and save .opvn file in ~/Downloads folders
4) cd ~/Downloads 
5) sudo openvpn --mktun --dev tun0  (should get a message that tun0 has been created)
6)  sudo openvpn --config  NAMEOFYOURFILE.opvn --dev tun0
 
That will get you up and going.  Check to make sure IP has changed to airvpn servers and check for DNS leaks.  To end VPN session, hit control C and it will destroy the tunnel and you will be back on clearnet.  When started, the VPN works for both the crouton and chromeOS sides.
 
After step 4, if you try to just start openvpn with the .opvn file, you get the same tun0 error message seen by the airvpn staff earlier.  Making it a two step process of creating the tunnel, and then starting the VPN seems to work.
 
I have not tried this from scratch with the native chromeOS shell, so can't comment if it will work without crouton.
 
Good luck.

Hello!
 
It's not completely clear what you want to achieve. Perhaps some clarifications are necessary.
 
First of all, it must be clear what a port (in networking) is. Wikipedia provides an outstanding, great, precise definition in article http://en.wikipedia.org/wiki/Port_%28computer_networking%29 :
 
"In computer networking, a port is an application-specific or process-specific software construct serving as a communications endpoint in a computer's host operating system. The purpose of ports is to uniquely identify different applications or processes running on a single computer and thereby enable them to share a single physical connection to a packet-switched network like the Internet. In the context of the Internet Protocol, a port is associated with an IP address of the host, as well as the type of protocol used for communication.
 
The protocols that primarily use ports are the Transport Layer protocols, such as the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) of the Internet Protocol Suite. A port is identified for each address and protocol by a 16-bit number, commonly known as the port number. The port number, added to a computer's IP address, completes the destination address for a communications session. That is, data packets are routed across the network to a specific destination IP address, and then, upon reaching the destination computer, are further routed to the specific process bound to the destination port number.
 
Note that it is the combination of IP address and port number together that must be globally unique. Thus, different IP addresses or protocols may use the same port number for communication; e.g., on a given host or interface UDP and TCP may use the same port number, or on a host with two interfaces, both addresses may be associated with a port having the same number."
 
Therefore, a port is said to be "open" when all the following conditions are met:
 
1) it exists
2) packets to it are not dropped or rejected by any packet filtering tool
3) the process identified by the port replies
 
Condition 1 seems trivial but please think about it. If there is no process identified by the host by a certain endpoint, there is no endpoint at all. The port does not exist, period. In common language this is one of the cases for which we say that "a port is closed".
 
When you remotely forward a port on our system, the VPN server will take care to forward packets to your VPN IP address:port number so you will be able to have listening services (i.e. processes identified by a unique endpoint) behind our NAT. Thus:
 
- if your service does not run, our servers forward packets but your system will not reply because it does not know which process it should send the packets to: "the port is closed".
- if your service runs, but a packet filtering tool on your system rejects or drops packets, the port does exist but it is again "closed"
- if your service runs and your packet filtering tool does not reject or drop packets it, but the port is not forwarded on our system, the VPN servers will drop the incoming packets from the Internet: the port is once again "closed" (from the external "Internet point of view")
- if your service runs, your packet filtering tool does not intercept packets to it, and the port is remotely forwarded on our system, the port is "open"
 
The problem you cite with Windows is probably due to the fact that by default a lot of processes (identified by an endpoint on the host) run without the user awareness, therefore a lot of ports "are open" by default. If the process associated to the port has one or more vulnerabilities, it may become the target of an attack: by sending packets to that port (i.e. by communicating with the vulnerable processes) an attacker could exploit such vulnerabilities for various purposes, including taking root control of the machine where such process runs (with privileges escalation, or with some intentional overflow just to make two random examples). Hence the basic rule: not running processes that you do not need is the first, simplest way to "close a port", even before than setting up a packet filtering tool.
 
When you're connected to our service, by default "all ports are closed". This means that the VPN server will not forward anything to your VPN IP. However, this does not mean that ALL of your host ports "are closed". For example, if your computer is behind a router NAT (very common case), AND you have processes running on the computer and listening to the physical network card AND you forward ports on your router matching the same endpoint of those processes, packets can reach those processes through that other forwarded ports. In general, when you are connected to a VPN server you should not forward ports on the router. Not only it is useless, because the VPN tunnel bypasses your router NAT as well as your ISP NAT (if any), but it is also potentially dangerous. In particular if you forward the SAME port numbers both on the VPN and on your router, and you have a process listening to those ports, correlation attacks become possible.
 
Kind regards

What is the difference between protocols?

UDP is a connectionless protocol, so during the handshake it is not always possible to do an effective error correction. As a result, when there's high ping or low quality line during the OpenVPN login, the handshake may fail, although you could see no significant problem after (if) the connection is established.
TCP is capable of handling these problems.

On the other hand, UDP is more efficient once the connection is established. OpenVPN also implements a basic packets error correction even in UDP (only after the tunnel is established).

If you experience problems with VoIP video/audio conversations when connected to the VPN through a TCP port, a typical case for which a difference may be visible (VoIP over TCP - for example UDP over TCP -  is clearly inferior to VoIP over UDP because TCP implements ARQ, UDP does not), then go for an UDP connection.

In general, you should always try an UDP connection if your ISP allows it and you don't experience any problem during the handshake.
However, TCP is mandatory if you need a proxy to reach the Internet. VPN over TOR connections require a TCP connection.

Variety of ports (53, 80, 443) is an additional option to try to bypass country or ISPs blocks, or bandwidth management. When OpenVPN connections are disrupted by your ISP (this happens for sure in China and Iran) then you need OpenVPN over SSL or OpenVPN over SSH supported by every AirVPN server and requiring, again, TCP.

Hello!
 
As we announced repeatedly, there will be no kill switch on Eddie, because forced applications killing is not a safe method for several reasons. On the contrary, there will be a total leaks prevention, to prevent for example packets leaks in case of unexpected VPN disconnection. Eddie 2.5 will include this feature and will be released (unless unforeseen problems come out) during the first half of September (and probably it will be also promoted to "stable", no more beta).
 
Kind regards

Hello!
 
We're very glad to inform you that a new 1 Gbit/s server located in Canada is available: Grumium.
 
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 accepts connections on ports 53, 80, 443, 2018 UDP and TCP.
 
Just like every other Air server, Grumium 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!
 
They block dozens of datacenters, entire IP ranges, and whole ranges from residential ISPs. If they need that, they do not look like very skilled hackers.
 
Kind regards

Hello!
 
We don't want to add security to the SSL layer. The SSL layer has the only purpose to encrypt the OpenVPN headers to prevent OpenVPN usage detection, it must not be thought as an additional security layer: the real security lies on the OpenVPN tunnel inside the SSL tunnel. Anyway, AES-128 is robust, even too much for our purposes. Remember that you should use OpenVPN over SSL only when absolutely unavoidable (for example from China, or whenever an ISP tries to block OpenVPN), because with OpenVPN over SSL you add a significant overhead and on top of that you force OpenVPN to work in TCP, while OpenVPN gives out its best performance in UDP.
 
Kind regards

Hello!
 
We're very glad to inform you that a new 1 Gbit/s server located in Canada is available: Grumium.
 
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 accepts connections on ports 53, 80, 443, 2018 UDP and TCP.
 
Just like every other Air server, Grumium 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 Canada is available: Grumium.
 
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 accepts connections on ports 53, 80, 443, 2018 UDP and TCP.
 
Just like every other Air server, Grumium 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