Staff

Hello!
 
We are very glad to announce new features aimed to improve your experience with our service.
 
The web site menus have been rationalized for a quicker and easier access, while several web pages have been completely rewritten to improve clarity and effectiveness.
 
We have added a page which we feel particularly important: the mission page. In it, you will find a complete overview of our mission https://airvpn.org/mission to understand "why we do what we do". Thanks to the excellent and fast growth of AirVPN customers base, of which we are very proud, we have been able since some months ago to fulfill an additional task: "Support when possible a range of projects and NGOs whose aim is compatible with AirVPN mission statement".
 
In the same "Mission" page you will find projects, initiatives, NGOs that we gladly decided to support, as well as side projects that are managed directly by us. Whenever possible, we will continue such support and also expand it to other projects. In a separate article we will explain the reasons of our choices for each supported project. We have published a new forum https://airvpn.org/forum/32-no-profit where you can suggest a project that covers our mission.
 
Let's examine now the additional features of the web site and the service.
 
In the servers status page https://airvpn.org/status you can now see a list of the latest issues occurred on the service. The list of issues is displayed on the top. It can be very helpful to backtrack possible issues you experienced with the service or with specific servers. The list is updated automatically by our monitoring system.
 
A completely new page has been added, the "Checking routes". In this page you can instruct every and each VPN server to perform a routing check to any destination. The results will be displayed within 60 seconds and cached for 10 minutes. Output includes several, relevant data. You can use this tool for troubleshooting, routing evaluation, name resolution verification, HTTP answers (in case of web sites) blocks discovery, target latency time and more.
 
Last but not least, we have implemented a series of "backend" modifications which in some cases you can't directly see but you will benefit from. In particular, the handling of the clustered database has been improved, the queue tasks of the VPN servers have been optimized and the monitoring system has been remarkably powered up. An additional part of the monitoring system has been made public, allowing an organized and fancy view of several stats for every and each VPN server.
 
We are confident that the new stuff will be useful and appreciated. We will be very glad to receive comments and feedbacks about it!
 
Enjoy AirVPN!
 
Kind regards & datalove
AirVPN Staff

Hello!
 
We are very glad to announce new features aimed to improve your experience with our service.
 
The web site menus have been rationalized for a quicker and easier access, while several web pages have been completely rewritten to improve clarity and effectiveness.
 
We have added a page which we feel particularly important: the mission page. In it, you will find a complete overview of our mission https://airvpn.org/mission to understand "why we do what we do". Thanks to the excellent and fast growth of AirVPN customers base, of which we are very proud, we have been able since some months ago to fulfill an additional task: "Support when possible a range of projects and NGOs whose aim is compatible with AirVPN mission statement".
 
In the same "Mission" page you will find projects, initiatives, NGOs that we gladly decided to support, as well as side projects that are managed directly by us. Whenever possible, we will continue such support and also expand it to other projects. In a separate article we will explain the reasons of our choices for each supported project. We have published a new forum https://airvpn.org/forum/32-no-profit where you can suggest a project that covers our mission.
 
Let's examine now the additional features of the web site and the service.
 
In the servers status page https://airvpn.org/status you can now see a list of the latest issues occurred on the service. The list of issues is displayed on the top. It can be very helpful to backtrack possible issues you experienced with the service or with specific servers. The list is updated automatically by our monitoring system.
 
A completely new page has been added, the "Checking routes". In this page you can instruct every and each VPN server to perform a routing check to any destination. The results will be displayed within 60 seconds and cached for 10 minutes. Output includes several, relevant data. You can use this tool for troubleshooting, routing evaluation, name resolution verification, HTTP answers (in case of web sites) blocks discovery, target latency time and more.
 
Last but not least, we have implemented a series of "backend" modifications which in some cases you can't directly see but you will benefit from. In particular, the handling of the clustered database has been improved, the queue tasks of the VPN servers have been optimized and the monitoring system has been remarkably powered up. An additional part of the monitoring system has been made public, allowing an organized and fancy view of several stats for every and each VPN server.
 
We are confident that the new stuff will be useful and appreciated. We will be very glad to receive comments and feedbacks about it!
 
Enjoy AirVPN!
 
Kind regards & datalove
AirVPN Staff

Hello!
 
We are very glad to announce new features aimed to improve your experience with our service.
 
The web site menus have been rationalized for a quicker and easier access, while several web pages have been completely rewritten to improve clarity and effectiveness.
 
We have added a page which we feel particularly important: the mission page. In it, you will find a complete overview of our mission https://airvpn.org/mission to understand "why we do what we do". Thanks to the excellent and fast growth of AirVPN customers base, of which we are very proud, we have been able since some months ago to fulfill an additional task: "Support when possible a range of projects and NGOs whose aim is compatible with AirVPN mission statement".
 
In the same "Mission" page you will find projects, initiatives, NGOs that we gladly decided to support, as well as side projects that are managed directly by us. Whenever possible, we will continue such support and also expand it to other projects. In a separate article we will explain the reasons of our choices for each supported project. We have published a new forum https://airvpn.org/forum/32-no-profit where you can suggest a project that covers our mission.
 
Let's examine now the additional features of the web site and the service.
 
In the servers status page https://airvpn.org/status you can now see a list of the latest issues occurred on the service. The list of issues is displayed on the top. It can be very helpful to backtrack possible issues you experienced with the service or with specific servers. The list is updated automatically by our monitoring system.
 
A completely new page has been added, the "Checking routes". In this page you can instruct every and each VPN server to perform a routing check to any destination. The results will be displayed within 60 seconds and cached for 10 minutes. Output includes several, relevant data. You can use this tool for troubleshooting, routing evaluation, name resolution verification, HTTP answers (in case of web sites) blocks discovery, target latency time and more.
 
Last but not least, we have implemented a series of "backend" modifications which in some cases you can't directly see but you will benefit from. In particular, the handling of the clustered database has been improved, the queue tasks of the VPN servers have been optimized and the monitoring system has been remarkably powered up. An additional part of the monitoring system has been made public, allowing an organized and fancy view of several stats for every and each VPN server.
 
We are confident that the new stuff will be useful and appreciated. We will be very glad to receive comments and feedbacks about it!
 
Enjoy AirVPN!
 
Kind regards & datalove
AirVPN Staff

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.

Hello,
 
it is explicitly forbidden by the Terms of Service, article 4, point 6.
 
Kind regards

Hello,
 
that's just fine. The 54... IP address you see is used by one of our failover servers. On this one, a frontend web server runs as well. That's why you can see our web site.
 
Kind regards

@refresh
 
In order to discern whether the problem lies in pfSense or not, try a connection from one of your computer and check whether the same thing occurs. If so, might it be that your ISP "leases" your IP address for a definite time frame (and therefore DHCP-re-assigns it every x hours or at some fixed time of the day)? Just speculation but it's worth a check. If it happens, your OpenVPN connection needs necessarily to be re-established, because of course the OpenVPN server has no way to know "your" new IP address until the client re-contacts.
 
To answer to the thread topic question: no, the Air servers keep the connection alive even when this connection is "inactive".
 
Kind regards

Would it be possible to explain this in more detail. I tried what you suggested but it does not seem to work. I have the following setup and would like to exclude my entire DHCP range from the VPN.
 
Static IP's are 10.0.0.30-10.0.0.39 ---> Want these IP's to use my VPN connection.
DHCP Range is 10.0.0.40-10.0.0.49 - Want any of these IP's to use my ISP's connection.
 
Router IP is 10.0.0.1 / 255.255.255.0
 
Any help would be greatly appreciated.
 
Regards,
Bubbba
 
Update:
I got it to work but it was not just a matter of using the "Policy Based Routing". I also needed to modify my iTables firewall entries.
 
Added 10.0.0.37 to the "Policy Based Routing" in the Open VPN client. This is one of the IP's I want to ALWAYS use the VPN.
 
Added the following to my firewall :
 
iptables -I FORWARD ! -o tun1 -s 10.0.0.37 -j DROP
 
Not sure why this worked but it did. This was information found in multiple messages.

Hello,
 
we have read that "review". We reserve the right to reply, therefore our comments follow.
 
 
 
That's not exact. You fail to mention that iVPN is a VPN service competitor.
 
 
 
False, Air is based in Italy as clearly stated in the Privacy Notice.
 
 
False: "These data are not collected to identify, through elaboration or any other technique" has an unequivocal legal meaning in the EU. It means that personal data, including IP addresses (regardless of the debate whether an IP address is a personal data or not), are not collected at all and in any way. Therefore not only we legally state that they are not stored when a client accesses a VPN service, but we also say that they are not even sent to third-parties WHILE a client is connected to a VPN server, which is a higher privacy condition. It seems, to say the least, bizarre that a higher privacy protection policy is interpreted as a lower one.
 
 
Once again, the sentence has a very precise legal meaning in the EU. The service is erogated when a client is connected, therefore when a client is disconnected the service is not erogated, ergo when a client disconnects those data are no more on the servers and the data retention period is, in the worst case, the timeout period (up to 60 seconds), in the best case 0 seconds.
 
 
 
False. The Privacy Notice states, since three years ago:
 
 
 
And also:
 
 
 
This fact alone shows that iVPN either did not even read our documents, or the writer(s) voluntarily lied.
 
Additionally, we don't need to cite ads or affiliates because: we have no ads and we don't plan to host any ad; and affiliates (if any) are totally separated from the system and can't access in any way any personal data, according to our Privacy Notice (see again above: data are not transmitted to third parties).
 
 
 
That's true and IT MUST BE SO. We will never mention how we "respond" to laws that are outside our jurisdiction and that are therefore inapplicable, simply because we are not forced to and we MUST NOT comply (and of course we must not even "respond") to such laws. An USA Act "has jurisdiction" on the USA. We are not subject to every single law existing in the world and we will NEVER mention them as if we recognized their validity. Doing so would imply an utter incompetence on the legal field. Ironically, we would like to ask to iVPN staff why they do not state in their policy how they "respond" to every single law in the world which makes VPN business illegal.
 
 
 
Broken English or illiterate iVPN reviewer? We recommend iVPN people to open a dictionary, for example the Webster dictionary, and search for "erogate", which means "give, lay out, provide, deal out".
 
And about you, centerc3290=@3, why don't you actually read our Tos and Privacy Notice, instead of relying on a COMPETITOR review, spreading it as a review "from IT professionals"? Use your own brain!
 
Kind regards

Hello,
 
no, that's perfectly normal and does not compromise security in any way. One of our services runs and listens to port 88 of the VPN servers exit-IP addresses. Packets are not forwarded to th Virtual Private Network or to the VPN nodes. The fact that our system replies to ping is deliberate, and it must be so, otherwise we could not gather reliable data for the Ping Matrix that you can access through our Servers Monitor, see https://airvpn.org/status and https://airvpn.org/pingmatrix
 
Actually what GRC web site states ("of YOUR system...") is technically wrong. It is in many cases true just for the coincidence that a long ago, when IPv4 addresses were still available, NAT and VPN were relatively uncommon. The GRC system sends packets not to your system, but to the exit-IP address of our VPN servers, i.e., so to say, "the IP address your node is visible on the Internet". This assumption is quite trivial and it is probably the reason for which it is not clarified by the GRC web site, but we understand that it can be confusing for a network-unexperienced user.
 
By default, all accounts ports are closed. Each account can anyway remotely forward up to 20 ports, in which case the system will properly forward packets to the VPN, to the appropriate client VPN IP address.
 
Kind regards

Hello,
 
no, that's perfectly normal and does not compromise security in any way. One of our services runs and listens to port 88 of the VPN servers exit-IP addresses. Packets are not forwarded to th Virtual Private Network or to the VPN nodes. The fact that our system replies to ping is deliberate, and it must be so, otherwise we could not gather reliable data for the Ping Matrix that you can access through our Servers Monitor, see https://airvpn.org/status and https://airvpn.org/pingmatrix
 
Actually what GRC web site states ("of YOUR system...") is technically wrong. It is in many cases true just for the coincidence that a long ago, when IPv4 addresses were still available, NAT and VPN were relatively uncommon. The GRC system sends packets not to your system, but to the exit-IP address of our VPN servers, i.e., so to say, "the IP address your node is visible on the Internet". This assumption is quite trivial and it is probably the reason for which it is not clarified by the GRC web site, but we understand that it can be confusing for a network-unexperienced user.
 
By default, all accounts ports are closed. Each account can anyway remotely forward up to 20 ports, in which case the system will properly forward packets to the VPN, to the appropriate client VPN IP address.
 
Kind regards

Hello,
 
it makes sense on a particular circumstance: if you wish to connect to a VPN server from the Windows machine, with the Air client and with the Windows machine unable (for example because it is "secured" against any leak) to resolve names via DNS queries.
 
Kind regards

Hello,
 
after the thread was written a "Disconnect Now" button in the web site and a "Disconnect" API service were implemented. Please see here https://airvpn.org/topic/9612-what-is-api
 
Kind regards

Hello,
 
yes, 10.0.0.0/8 IP addresses are private addresses. This solution:
 
Static DNS 1: 10.4.0.1  
Static DNS 2: 50.116.23.211
Static DNS 3: (optionally another OpenNIC DNS server)
 
looks perfect. It will let your device use the VPN DNS when it's in the VPN and a public and trusted DNS when it's not.
 
Kind regards

Hello,
 
10.4.0.1 etc. are private IP addresses which can be reached only inside the VPN. In your case you can either set, in the router OpenVPN client configuration, the entry-IP address of the server you wish to connect to (so that it does not need any name resolution) or use a public DNS as a secondary DNS after 10.4.0.1. Keeping 10.4.0.1 as primary and a public DNS as secondary will allow you to use the secondary DNS when the router is not in the private network, and VPN DNS when the router is in the VPN.
 
Kind regards

@degas432
 
Yes, we're saying that, but we're saying even more.
 
We're also saying that if (just to make bad science fiction, because all the elements point to the contrary) NSA could break the encryption for ONE of your keys AND discern AND capture the packets stream of a client for THAT key, it could decrypt ONLY the packets stream included in the time frame between two TLS re-keyings (see also on Wikipedia "Perfect Forward Secrecy").
 
An interesting discussion is here http://crypto.stackexchange.com/questions/579/how-can-we-reason-about-the-cryptographic-capabilities-of-code-breaking-agencies
 
one paragraph of one of the posts is particularly worth to be quoted. It's one month old but it was prophetic in light of the most recent leaked documents:

Reading the slides for PRISM the cost of the program is way too low to include any sort of computationally intensive pursuits. It's not a far leap to infer PRISM being a key sharing effort. Several accounts seem to indicate the NSA are actively subverting security on the standards level or in collusion with software developers. If either proposition is true, any serious cryptographer needs to use systems where every component is known and excludes closed source operating systems and software black boxes.
 
One side note as a figurative example: being worried about NSA decrypting your one-hour AES-256 traffic while at the same time running Windows is like being worried exclusively about an asteroid hitting your head when you walk at night alone in San Pedro Sula while happily waving 10000 dollars in your hand.

Kind regards

Hello!
 
The apparent reason from Freenode (from their communications to us) is a single abuse on their IRC network from one of our nodes and our subsequent message informing them that we don't keep logs to detect the alleged abuser.
 
Real identity protection and true, effective anonymity layer are probably the most important features of our service.
 
The above features are not negotiable for us unless we are provided with clear proof about infringements of the ECHR, urgent matters which involve physical safety of a person etc. (see our Terms of Service) by a competent authority. We will not start logging as a consequence of a request from any private entity or from any not competent authority.
 
Freenode therefore let us understand us that since we don't log, they would ban every AirVPN server. We did not add anything after the ban about this policy; as we said no-logging policy is not negotiable with private entities.
 
This issue is just another hint for you about how serious and determined we are in respecting our commitments, policy and mission. Our determination in handling such issues and above all much more complicated matters is, in our opinion, comparable to the determination of several TOR exit-node operators.
 
For example, think about the following:
Freenode advertises Private Internet Access (a large VPN provider) Private Internet Access claims an absolute no logging policy: "No logging. Period." is written in their "Buy VPN" page Private Internet Access nodes can access Freenode IRC servers, since the ban against AirVPN and at the time of this writing Therefore, either Private Internet Access in reality is able and willing to detect a user, start logging etc. as a consequence of a simple request by Freenode (or any other private entity), or Freenode does not enforce against Private Internet Access the same policy it enforces against non-logging VPN services such as AirVPN.
 
We don't know, Freenode did not give us any detail about any abuse. Hopefully this message has clarified the most probable reasons.
 
Kind regards

People (who are involved in IT security in first place) read about the open port 32764 in routers from Cisco, Linksys, Netgear and Diamond having strange backdoor access to the configuration files of those routers.
 
Long story short, there is a service listening on this port which accepts a variety of commands such as resetting the router or printing out all kinds of information, even passwords in plain text. Connecting to the router through telnet should return the string "ScMM" or "MMcS" if the service is running (it's for SerComm).
 
It could be smart to check if your Cisco/Linksys/Netgear/Diamond router is listed here. Or use this python script. Or just connect to your router via
telnet [your.router.ip] 32764 and see if you get one of the aforementioned strings back.
 
Source #1
 
Source #2
 
 
---- Update #1 ----

First statements of manufacturers Linksys and Netgear. Both of them allegedly are "going through all possible vulnerabilites" and will publish more information on this after they did some analyzing. Fact is that they didn't even warn the users of those routers... strange, too...
Source
 
---- Update #2 ----
Cisco released a Security Advisory and is working on a fix. There are no workarounds so you have to wait for Cisco's update.
 
---- Update #3 ----
 
It's not over!

Hello,
 
Google DNS (as well as OpenNIC and any other public DNS we have tested) have no problems in resolving our names and this suggests that your ISP is hijacking DNS queries (please see below). For example:
 
 
 
dig @8.8.8.8 asia.vpn.airdns.org ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @8.8.8.8 asia.vpn.airdns.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52404 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;asia.vpn.airdns.org.        IN    A ;; ANSWER SECTION: asia.vpn.airdns.org.    300    IN    A    119.81.1.125 ;; Query time: 647 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Jan  3 02:09:04 2014 ;; MSG SIZE  rcvd: 53   
 
It might be that your DNS queries are hijacked in any case REGARDLESS of the DNS server you try to reach. This occurs with some ISPs around the world (for example Vodafone) AND it might occur with several ISPs in China. In this case, please do not use names at all. Insert directly the entry-IP address of the server you wish to connect to. For example, instead of asia.vpn.airdns.org, insert the entry-IP address of one of the Singapore servers.
 
Kind regards

@shadow1011
 
Hello!
 
That's correct, our micro-routing system against geographical discriminations will allow access to Neflix USA from every server except UK ones, and to Netflix UK from UK servers.
 
Kind regards

Fixed it using info from here - basically replacing the existing venet ip address with a veth network device for the container instead. Works a treat now

Why don't you add many more servers locations?

A new server location must comply to every AirVPN requirement. Contrarily to some of our competitors, we don't add locations just to have "one more country flag", in disrespect of service quality and customers' security. We take every care in order to provide high quality of service and high security. The servers datacenters must comply to our requirements for privacy, bandwidth, traffic, peering, net neutrality and usage policy. All these factors together restrict significantly the range of viable choices. The privacy requirements alone cuts out entire countries, while several other countries are discarded because they have an insufficient infrastructure. This is the only way to keep the service in line with our vision and our quality and security standards. 
Under a security point of view, picking a server outside the country you live in is a superior choice: an adversary with the ability to monitor your Internet line will have more difficulties in re-building your connections paths and enlarge its monitoring powers into different jurisdictions.
 
Under a performance point of view, geographical proximity does not always imply network proximity. Also, we can't ensure 1 Gbit/s for every and each location. A better way to select a server to get higher performance is determining, through our servers monitor, the servers with the lowest relative latency and pick, between them, those not at capacity.
 
If you need a particular location to bypass geo-IP-location based restrictions, first have a look here.
 
If the service you're interested in is included in our anti-blocking system, you will probably get higher comfort and performance from a connection to the network-nearest server to you. An example: if you are in Europe and you wish to access Hulu, it is likely that connection to an European server, instead of a connection to an USA server, will result in a better performance (especially if your ISP is not a tier1) and at the same time will allow you to access European services more swiftly.
 
If the service is not included in our anti-blocking system and/or it is in a country where we do not have servers, ask for it: routing anti-geo-IP-location based restrictions servers are not bound to our requirements for privacy legal framework etc., so we will evaluate your request without prejudice deriving by our strict requirements.

Hello!
 
We're very glad to inform you that a Dynamic DNS service is now available to all Premium members at no surcharge.
 
The DDNS service lets you define up to 20 domain names to make the services running behind Air VPN servers more comfortably reachable, and keep a domain name persistent across all Air VPN servers.
 
Please see here for every information:
https://airvpn.org/topic/9314-what-is-dynamic-dns
 
Kind regards and datalove
AirVPN Admins

Hello!

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

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, Megrez 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
 

For this:

23/12/2013 - 15:29 C:\WINDOWS\system32\route.exe ADD 127.0.0.1 MASK 255.255.255.255 192.xxx.xxx.xxx
23/12/2013 - 15:29 ROUTE: route addition failed using CreateIpForwardEntry: Parâmetro incorreto.   [status=87 if_index=2]
23/12/2013 - 15:29 Route addition via IPAPI failed [adaptive]
23/12/2013 - 15:29 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 xxx.xxx.xxx.xxx
23/12/2013 - 15:29 Route addition via IPAPI succeeded [adaptive]

Adding this to the end of the .ovpn file might help:

route-method exe
route-delay 30

but you cannot do this (as far as I know) with AirVPN client.


For this:
23/12/2013 16:37:29.867 [NOTICE] Tried for 120 seconds to get a connection to [scrubbed]:443. Giving up. (waiting for circuit)
23/12/2013 16:37:29.868 [WARN] Proxy Client: unable to connect to xxx.xxx.xxxx.xxxx:443 ("TTL expired")
23/12/2013 16:37:32.170 [NOTICE] Tried for 120 seconds to get a connection to [scrubbed]:9001. Giving up. (waiting for circuit)

It might be an indication that a bridge would help.

For this:

"23/12/2013 - 15:39 recv_socks_reply: TCP port read timeout expired
23/12/2013 - 15:39 SIGTERM[soft,init_instance] received, process exiting
23/12/2013 - 15:39 Failed to start."


I've seen some posts suggesting to use the PreferSOCKSNoAuth which you have done.

The only other thing I can think of (w/ AirVPN client) is to disable your Internet Security on the machine. Perhaps the firewall is interfering? This wouldn't be a resolution or workaround.
Maybe try TCP 443/53 instead of TCP 80 but I don't think that'll help.

Lastly, I'd try installing the OpenVPN GUI wrapper, create a config using the Config Generator and trying it with that.
http://openvpn.net/index.php/download/community-downloads.html
 
In the AirVPN Client Area > Config Generator-
Select your:
1. OS
2. Server

3. Connection Modes:
check Advanced Mode

Select your TCP port

Proxy
Socks
Port 9150

4. Terms of Service
Check those

5. Generate

Place your .ovpn file in the %Program Files%\OpenVPN\config directory

Run OpenVPN GUI with administrative priviledges.

Right-click the OpenVPN GUI applet on the System Tray > go to your (generated) config name > connect.

You can also access your connection log from there.
 
EDIT: If you want to stop DNS and other leaks using OpenVPN, @Nadre posted a method here: https://airvpn.org/topic/9787-the-pros-and-the-cons/?p=11501
 
His post here is about stopping other leaks::
https://airvpn.org/topic/9797-blocking-non-vpn-traffic-without-firewall-using-routing-router/
 
there are also posts within this forum using firewall rules such as this:
https://airvpn.org/topic/3405-windows-comodo-prevent-leaks/
 
for Windows. These would apply to OpenVPN or OpenVPN over Tor, not Tor over OpenVPN.