Staff

Thank you!
With the "tun+" tip I was able to get it working. P2P port forwarding seems to work now. I have some other, more complex applications I look forward to trying in the future. 
I am planning on extending my 3 day trial to a full year. I'm impressed with how helpful you have been. Thanks again!

You provide Remote Port Forwarding, what is it?
 
"Remote port forwarding" forwards traffic coming from the Internet to our VPN server ports to a specified local port of your client.

By default, your account has no forwarded ports, and this is good as long as you don't wish to have a service reachable from the Internet. For example, suppose that you want to run a web server behind our VPN, or that you wish to receive incoming connections to your BitTorrent client in order to improve p2p performance, or to seed a file. Without at least one remotely forwarded port, your service could not be reached from the outside, because our VPN server would reject the proper packets to your service.

Usually this is a good security measure against attacks, but it prevents your services to be reached from the Internet.

When you remotely forward an inbound port, our servers will open that port (TCP, UDP or both, according to your selection) and will properly forward incoming packets to you on that port. The service will be reachable from the exit-IP address of the VPN server your system is connected to.

You can forward up to 20 ports simultaneously. You can do that on our website, in your account "Client Area". You can't forward ports lower than 2048.

You can map a remotely forwarded port to a different local port: this is useful for a variety of cases, for example when your service listens to a port lower than 2048 or when the port is already reserved. More details about it here below.

Once you reserve an inbound remote port for your account, you have two options:

1) Leave the "Local" field empty. In this case, packets arriving to the VPN server exit-IP address port n will be forwarded to your machine IP address inbound local port with the very same number n

2) Fill in the "Local" field with a different port number x. In this case packets arriving to port n will be forwarded to your system inbound local port x.

In both cases you need to reach the service on the VPN server exit-IP address port n.


IMPORTANT: do NOT forward on your router the same ports you use on your listening services while connected to the VPN. Doing so exposes your system to correlation attacks and potentially causes unencrypted packets to be sent outside the tunnel from your client. However, if you connect a router (for example DD-WRT, Tomato based firmware router) an additional step is required, please see https://airvpn.org/topic/9270-how-to-forward-ports-in-dd-wrt-tomato-with-iptables/  
NOTE: you can't reach your listening service(s) through the VPN server exit-IP address from the very same machine that's running it/them and is connected to a VPN server, or from any other machine connected to that same VPN server.

PJ,
 
first and foremost: You and your staff are doing a great job. At no point did I intend to imply any incompetence from your side, quite on the contrary.
 
I do not care much for trackers, as you said with DHT they have become pretty much obsolete, and I especially don't give a rat's behind about stats. It was just a behaviour mismatch within the AirVPN environment that I, with my limited knowledge, especially of low-level routing, could not explain to myself. On the off chance that it was some misbehaviour occuring within AirVPN I submitted my observations. Thank you for your explanations, the possibility that these trackers, while independent, use a common blocklist makes perfect sense.
 
Expect a full subscription from me.

What a five star support you are guys!!!

Hello,
 
datacenter solved the problem on Pavonis.
 
Useful tools to check the servers status are the Status page (click on "Status" on the upper menu) and the Ping Matrix (linked inside the Status page).
 
Kind regards

Hi,
 
no, the problem is not serious and it has been solved, we are investigating the cause.
 
Kind regards

Hello!
 
We're glad to inform you that in your "Client Area" you can now find a "Disconnect Now" button. If you click it, your account will be forcefully disconnected from any VPN server it is connected to within 60 seconds.
 
Use it with caution!
 
Kind regards

Hello!
 
To keep you informed: the problem appears quite complex and we're still investigating. One of the backend servers stopped working for a kernel panic (the causes of which are still to be determined). When this happens the VPN servers simply can switch to another backend server with no strict time pressure. However, in this case, lots of OpenVPN daemons (especially those for port 443 UDP) on many different servers crashed, causing disconnections to the clients (if this did not happen, you would have not noticed anything - this is the major issue in our point of view, why so many OpenVPN daemons crashed all at once) and of course preventing re-connection. Additionally, since the VPN servers were still working, the remaining working backend servers did not consider any of them as "dead", and therefore did not release the connected accounts, causing another impossibility to re-connect.
 
Finally, about the button "Disconnect Now"... it did not work, because the command has remained "stuck" to the non-working backend server (no backend switching on the frontend occurred).
 
Now that we have re-built the chain of events (which anyway were solved in less than 20 minutes) we are proceeding with further investigation.
 
Kind regards

The Speedtest.net Mini flash embed at speedtest.air claims it will expire in 5 days so better update it.
 
Thank you

Summary of analysis:
 
AirVPN speeds over Bell Canada infrastructure are apparently limited by technical ITMPs to under 2Mbps.  Neither SSH, not SSL successfully evades ITMPs. 
 
The ITMPs for controlling SSL appear to be less unfavourable to uploading than the general VPN throttle.  This finding is independent of hardware on which OpenVPN is running and can be replicated.  The gateway router is a constant, and so could be the source of speed reductions, but this seems unlikely.
 
Bell Canada is not publicizing it's ITMPs and it remains to be seen if they are compliant with CRTC guidance in this regard.  I am assuming that my member-owned 3rd party service provider is not the source of IMTPs, but this is to be confirmed.

Hello!
 
Thanks, problem fixed! There were huge delays in DDNS updates. You should see now quick updates as usual.
 
Kind regards

This guide shows how to set rules to prevent leaks in case of unexpected VPN disconnection and provides you with clear scripts ready to be used with basic modifications on Red Hat Enterprise Linux and RHEL rebuilds such as Oracle Linux, Scientific Linux, X/OS, CentOS etc.

THANKS TO JESSEZ - ORIGINAL POST BY JESSEZ (minor editing & clean-up by Air staff)

This method requires the ipset package:
sudo yum install ipsetRHEL 6 and rebuilds (Oracle Linux, Scientific Linux and CentOS) do not have a kmod-ipset that I could find.

The ip_set module has to be loaded manually as neither netfilter, iptables nor conntrack call the module themselves. As far as I know some Linux distros do have a kmod for ip_set so that would make usage of sysconfig/ipset.conf not necessary and also could cause a boot-time error (fatal nor not).

The ip_set module has to be loaded and a script run to load the ip_set script (creates and contains the AirVPN server IP addresses) so that there is a table to be read by the time iptables_restore runs (otherwise iptables_restore throws the error that no ipset "airvpn" exists).

So there are 3 files. The first and the second file can be found attached to this message. The last one is a system file that needs a modification.

1
/etc/sysconfig/ipset.conf

This script tests whether the ip_set module is already loaded. If not it loads it into the kernel (modprobe).

ipset.conf.txt

2
/etc/sysconfig/ipset-airvpn.sh

This file creates and fills the ip_set table of AirVPN server addresses. I haven't listed the servers, so that no-one can just open the file and get the server IPs. Add the ones you want where the a.b.c.d 's are. Add or subtract lines as necessary. I think I added enough buffers so that all the servers should be able to go into the table (which lives in RAM while the system is up and is lost at shutdown/re-start). After running the script use:
sudo ipset -L airvpn -to make sure all the servers you added to the script are there (It's easiest just to count the lines if you know how many servers you added in the first place), if not, change the part: hashsize 65536 to the next larger: hashsize 131072 (doing this obviously eats up RAM, so don't change it unless you need to) and note that the hashsize can start at 1024 and can only be a power of 2 (1024, 2048, 4096, ..., 131072...)

If you're only using one or two servers and you need to save RAM, just change it down, re-run the script and issue the command sudo ipset -L airvpn again to check that all the desired servers are listed. Keep doubling the hashsize until they are. If anyone is wondering about the -exist option, it's there so that in case of accidental duplication of an IP address the script won't fail.

iptables-airvpn_2013-01-19.txt

3
/etc/init.d/iptables

This is the system file, so be careful; add 2 new lines that become line 55 and line 56:

# Load /etc/sysconfig/ipset-airvpn.sh to make the airvpn table
sh /etc/sysconfig/ipset-airvpn.sh



Ok, that should be it, iptables and the "airvpn" ipset table should now survive a reboot with no errors. Test by rebooting, and trying Internet access of any and /or several kind(s) before starting a VPN connection when the desktop is up. If it's working you will have no Internet before starting a VPN connection, and you will be able to connect to any of the servers you added to ipset-airvpn.sh without OpenVPN throwing an error (probably: write UDPv4 []: Operation not permitted (code=1)).

Note: rename the attached files according to the names given above. Put the files in the appropriate folders as listed above.

Regards,
jz

Absolutely.
 
Our mission is "defence of net neutrality, privacy and against censorship".
 
The core part of the service covers this mission, but we are thinking also about spin-off projects (under the same mission), that can be:
- developed and financed by us, or
- developed/managed by members of this community and financed by us, or
- simply financed or supported with donations by us.
 
For ideas, we opened this topic.
 
 
It is possible only with injection of Google Translate javascript in our website pages. We don't allow this kind of trust. In fact, we have removed the "Google Plus" and "Facebook like" in pages of this website, for the same reason.
 
We can add an opt-in option that shows this automatic translations feature. But those who need it can simply install a toolbar, right?
 
 
If you add these routes with OpenVPN directives, look at the OpenVPN docs about the "route" directive: you can use "vpn_gateway" as alias of the assigned VPN IP, so it doesn't matter if they are dynamic.
Note that we implemented recently custom directives in our configuration generator.
Feel free to open a separate topic for this if you need more help.
 
Anyway, a new client 2.0 is under development. It provides the user the option to choose a range of IP (route) and choose if it must be it tunneled or not. So, detection of the VPN IP interface is done automatically.
Note: the new client will be released for Windows, Linux and OSX, under GPL.
 
 
Done, feel free to open a separate topic to expand these requests.
 
 
There are already these kinds of domains with all servers.
The idea to maintain other domains with only one server, updated according to lowest usage, is nice. But probably not really usable because of high DNS TTL. We are still thinking about it.
 
The best, right, and correct implementation is planned in our next client: servers have a "score" computed on each server, based on availability, latency time (test performed in background), usage level and other parameters.
It will have a auto-connection based on server score, and level/triggers about reconnection to other servers with better scores.
Please only be patient, we'll explain in details how it works when we release the first beta.
 
 
We are working on that: more detailed servers informations (for example bandwidth charts) and improved notification of issues. We are thinking about user-notifications.
 
 
This feature is under development into the new client.
 
 
This is very interesting, great hit of our mission.
 
Glastnost/MLab tests must be done by experienced members, we can collect results here and provide how-to support. Subject deserves to be explored.
 
 
Almost everything of the above is planned in the new client. When we proceed further with the beta stage, test it, and please remind us the missing suggestion.
 
 
Yes, but probably notifications are not a solution, they are a workaround.
 
We are working on a solution of leaks in our new client. This kind of notification will also available for people that don't want or can't use our client.
 
 
Anyone here can open a poll, help us probe the community.
When we have many topics about the same subject, we can open a section in the forum dedicated to the subject.
 
 
Absolutely. We will add a payment option soon. We are also investigating other payment gateways, with a special focus to systems than can allow people to buy with cash a prepaid card and use it for our service.
 
Bitcoin: we are currently undecided about advantages/disadvantages of accepting payments directly or use a third-party (like we do now with bitcoincodes).
 
Mail server or seedboxes are under evaluation.
 
Thanks, thanks, thanks to all.

Hello,
 
the backend servers are not communicating properly with each other causing db desync, we're working on it.

Hello,
 
the backend servers are not communicating properly with each other causing db desync, we're working on it.

Just sent my third party ISP the following question:
 
 
If Bell is applying Internet Traffic Management Policies (ITMPs) they are to follow CRTC Guidance (see: http://www.crtc.gc.ca/eng/archive/2009/2009-657.htm)

This includes in the case where they throttle VPN generally for both their own retail customers and for wholesale customers like NCF that they need to give NCF prior notice and in any case inform you of the :

"91. For technical ITMPs applied to wholesale services that do not require prior Commission approval, the Commission considers that a description of the ITMPs in the tariffs of primary ISPs is the best means of providing information to secondary ISPs. Accordingly, primary ISPs are required, as a condition of providing service, to issue updated tariff pages describing such ITMPs. Primary ISPs are to issue revised tariff pages, sending copies to their wholesale customers, a minimum of 60 days prior to implementing the ITMP or implementing changes to the ITMP. "

Can you confirm whether the tarrif for wholesale Fibre services includes notification of VPN speed traffic management?

Hello!
 
ISSUE (CRITICAL)
Just 4 days ago Tunnelblick 3.3beta44 was released. We can now surely recommend the upgrade to 3.3beta44 (or beta46) to all Mac OS X 10.8.x (Mountain Lion) users, however it is now clear that there's a critical problem with this version of Tunnelblick and OpenVPN 2.2.1 which prevents connections to our service.
 
SOLUTION
Switch to OpenVPN 2.3.x from inside Tunnelblick menu.
 
Kind regards

Hello!

We're very glad to inform you that a new 100 Mbit/s server located in Spain is available: Algol.

The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access it 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, Algol 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 the USA is available: Diadem.

The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access it 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, Diadem 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

There is a post about this on the Tor blog.
 
https://blog.torproject.org/blog/calea-2-and-tor

Hello!
 
You're right, something happened on the image hosting service (we see that the images were not uploaded on our servers, but they were just fine some time ago... something went wrong when we migrated to the new system).  As a temporary, quick work-around, refer to the pictures here:
http://www.pixhost.org/show/3984/15431130_1-tomato_config_basic.png
http://www.pixhost.org/show/3984/15431131_2-tomato_config_adv.png
 
or to the guide in the "Enter" menu https://airvpn.org/tomato
 
to get the parameters you miss for the configuration. Feel free to contact us for any doubt in any field.
 
EDIT: the pics in the original post have been fixed.
 
Kind regards

Hello!
 
We have already been contacted by Freenode a few hours ago, they kindly explained that the problem is abusive behavior from user(s) from our nodes. Probably they have gone ahead by themselves and started blocking all our exit-IP addresses. This could make things worse because we could start multi-hopping and rotating as many IP "secret" addresses as we wish from 4 continents, making their task desperate, but in this case we will NOT do so at the moment: Freenode is an IRC platform that supports free & open source software and their users, as well as any other service and any other user of any other service, must NOT be harassed by our nodes. We could have studied alternative solutions with automatic triggering, but if they have already chosen to block indiscriminately, that's their legitimate right. We will do nothing to circumvent the blockade before we carefully evaluate the problem and get also an informal opinion by Mr. Stallman, Mr. Cerf and Sir Berners-Lee (if they will wish to give us one, of course) on such general matters next time we meet them in person or virtually.
 
The general point is if it's ethically acceptable for a service like ours, which provides free access to people working in human-rights hostile countries, to fight net neutrality violations and end-to-end principle violations from private entities over their private will when such fight will help harassing behavior.
 
Kind regards

Hello!
 
Frankly we are not documented about what you say (it's very hard to keep following every and each draft law pertaining to privacy, data protection etc. in 14 countries). We'll investigate, thank you!
 
Kind regards
AirVPN Support Team

Hello!

We're very glad to inform you that a new 100 Mbit/s server located in Spain is available: Algol.

The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access it 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, Algol 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 the USA is available: Diadem.

The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access it 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, Diadem 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