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.

I had the same problem up to some minutes ago. 
For me it helped to get the newest version of the openvpn software, which is 
 
openvpn-install-2.3.2-I003-x86_64
 
this is very new ! (22 Aug I guess)
 
From the site I downloaded my installer initially,  I got the ... I002... version, which seems to have no valid signature for the drivers. 
 
I did
uninstall openvpn reboot ( to be sure everything is out of memory) install new version. and then could immediately connect ...

I wish the Air VPN window could be resized. It's tiny. I'd like to be able to see more server choices at one time.

I looked again into my problem and came to the following solution.
I'd like to share it with you, so that nobody has to do the same work again.
 
my vpn setup:
/etc/openvpn # ll -Gg total 100 -rw-r--r-- 1 604 Aug 29 11:04 AirVPN_America_UDP-443.ovpn -rw-r--r-- 1 602 Aug 29 11:04 AirVPN_Europe_UDP-443.ovpn -rw-r--r-- 1 599 Aug 29 11:04 AirVPN_NL-Castor_UDP-443.ovpn -rw-r--r-- 1 599 Aug 29 11:10 AirVPN_NL-Corvi_UDP-443.ovpn -rw-r--r-- 1 601 Aug 29 11:10 AirVPN_NL-Leporis_UDP-443.ovpn -rw-r--r-- 1 601 Aug 29 11:11 AirVPN_NL-Lyncis_UDP-443.ovpn -rw-r--r-- 1 602 Aug 29 11:11 AirVPN_NL-Ophiuchi_UDP-443.ovpn -rw-r--r-- 1 603 Aug 29 11:11 AirVPN_US-Andromedae_UDP-443.ovpn -rw-r--r-- 1 601 Aug 29 11:11 AirVPN_US-Arrakis_UDP-443.ovpn -rw-r--r-- 1 598 Aug 29 11:11 AirVPN_US-Heze_UDP-443.ovpn -rw-r--r-- 1 600 Aug 29 11:12 AirVPN_US-Librae_UDP-443.ovpn -rw-r--r-- 1 602 Aug 29 11:12 AirVPN_US-Pavonis_UDP-443.ovpn -rw-r--r-- 1 600 Aug 29 11:12 AirVPN_US-Persei_UDP-443.ovpn -rw-r--r-- 1 600 Aug 29 11:13 AirVPN_US-Pollux_UDP-443.ovpn -rw-r--r-- 1 599 Aug 29 11:13 AirVPN_US-Sirius_UDP-443.ovpn -rw-r--r-- 1 1562 Aug 22 16:51 ca.crt lrwxrwxrwx 1 29 Aug 29 11:04 default.conf -> AirVPN_NL-Castor_UDP-443.ovpn drwxr-xr-x 2 4096 Aug 26 21:51 log/ -rwxr-xr-x 1 2766 Aug 29 11:09 setupIPtables.sh* -rwxr-xr-x 1 3139 Aug 29 11:06 switch.AirVPN.sh* -rwxr-xr-x 1 1357 Jun 16 2011 update-resolv-conf* -rw-r--r-- 1 5127 Aug 22 16:51 user.crt -rw------- 1 1675 Aug 22 16:51 user.key I saved the VPN servers I'd like to use from airvpn.org under /etc/openvpn.
I added the following lines on each ovpn file:
script-security 2 up /etc/openvpn/update-resolv-conf down /etc/openvpn/update-resolv-conf status log/openvpn.status.log So here one example how it looks like. I blackenend the remote line.
cat AirVPN_NL-Castor_UDP-443.ovpn # -------------------------------------------------------- # Air VPN | https://airvpn.org | Tuesday 27th of August 2013 02:48:58 PM # OpenVPN Client Configuration # AirVPN_NL-Castor_UDP-443 # -------------------------------------------------------- script-security 2 up /etc/openvpn/update-resolv-conf down /etc/openvpn/update-resolv-conf status log/openvpn.status.log client dev tun proto udp remote IPADRESS PORT resolv-retry infinite nobind ns-cert-type server cipher AES-256-CBC comp-lzo verb 3 explicit-exit-notify 5 ca "ca.crt" cert "user.crt" key "user.key"  
I wrote a simple script, so I can switch between my selection of vpn servers:
cat switch.AirVPN.sh #!/bin/bash while : do clear cat << EOF 1) Switch to Europe VPN 2) Switch to America VPN 3) NL-Castor 4) NL-Corvi 5) NL-Leporis 6) NL-Lyncis 7) NL-Ophiuchi 8) US-Andromedae 9) US-Arrakis 10) US-Heze 11) US-Librae 12) US-Pavonis 13) US-Persei 14) US-Pollux 15) US-Sirius 22) stop VPN 31) show iptables 32) show route 33) show ifconfig 44) exit EOF read input case $input in 1) /etc/init.d/openvpn stop; sleep 15s; rm default.conf; ln -s AirVPN_Europe_UDP-443.ovpn default.conf; /etc/init.d/openvpn start ; /etc/openvpn/setupIPtables.sh ;; 2) /etc/init.d/openvpn stop; sleep 15s; rm default.conf; ln -s AirVPN_America_UDP-443.ovpn default.conf; /etc/init.d/openvpn start ; /etc/openvpn/setupIPtables.sh ;; 3) /etc/init.d/openvpn stop; sleep 15s; rm default.conf; ln -s AirVPN_NL-Castor_UDP-443.ovpn default.conf; /etc/init.d/openvpn start ; /etc/openvpn/setupIPtables.sh ;; 4) /etc/init.d/openvpn stop; sleep 15s; rm default.conf; ln -s AirVPN_NL-Corvi_UDP-443.ovpn default.conf; /etc/init.d/openvpn start ; /etc/openvpn/setupIPtables.sh ;; 5) /etc/init.d/openvpn stop; sleep 15s; rm default.conf; ln -s AirVPN_NL-Leporis_UDP-443.ovpn default.conf; /etc/init.d/openvpn start ; /etc/openvpn/setupIPtables.sh ;; 6) /etc/init.d/openvpn stop; sleep 15s; rm default.conf; ln -s AirVPN_NL-Lyncis_UDP-443.ovpn default.conf; /etc/init.d/openvpn start ; /etc/openvpn/setupIPtables.sh ;; 7) /etc/init.d/openvpn stop; sleep 15s; rm default.conf; ln -s AirVPN_NL-Ophiuchi_UDP-443.ovpn default.conf; /etc/init.d/openvpn start ; /etc/openvpn/setupIPtables.sh ;; 8) /etc/init.d/openvpn stop; sleep 15s; rm default.conf; ln -s AirVPN_US-Andromedae_UDP-443.ovpn default.conf; /etc/init.d/openvpn start ; /etc/openvpn/setupIPtables.sh ;; 9) /etc/init.d/openvpn stop; sleep 15s; rm default.conf; ln -s AirVPN_US-Arrakis_UDP-443.ovpn default.conf; /etc/init.d/openvpn start ; /etc/openvpn/setupIPtables.sh ;; 10) /etc/init.d/openvpn stop; sleep 15s; rm default.conf; ln -s AirVPN_US-Heze_UDP-443.ovpn default.conf; /etc/init.d/openvpn start ; /etc/openvpn/setupIPtables.sh ;; 11) /etc/init.d/openvpn stop; sleep 15s; rm default.conf; ln -s AirVPN_US-Librae_UDP-443.ovpn default.conf; /etc/init.d/openvpn start ; /etc/openvpn/setupIPtables.sh ;; 12) /etc/init.d/openvpn stop; sleep 15s; rm default.conf; ln -s AirVPN_US-Pavonis_UDP-443.ovpn default.conf; /etc/init.d/openvpn start ; /etc/openvpn/setupIPtables.sh ;; 13) /etc/init.d/openvpn stop; sleep 15s; rm default.conf; ln -s AirVPN_US-Persei_UDP-443.ovpn default.conf; /etc/init.d/openvpn start ; /etc/openvpn/setupIPtables.sh ;; 14) /etc/init.d/openvpn stop; sleep 15s; rm default.conf; ln -s AirVPN_US-Pollux_UDP-443.ovpn default.conf; /etc/init.d/openvpn start ; /etc/openvpn/setupIPtables.sh ;; 15) /etc/init.d/openvpn stop; sleep 15s; rm default.conf; ln -s AirVPN_US-Sirius_UDP-443.ovpn default.conf; /etc/init.d/openvpn start ; /etc/openvpn/setupIPtables.sh ;; 22) /etc/init.d/openvpn stop ;; 31) iptables -L -v -n --line-numbers ;; 32) route ;; 33) ifconfig ;; 44) exit ;; *) echo wrong insert;; esac read foo done  
I also setup my iptables with the following idea:
1) All traffic should go over the vpn tunnel tun0.
2) No traffic leak if the vpn tunnel drops.
3) SSH Access over my public IP, and only over my public IP, should always be allowed.
 
 
I blackenend the remote ip again. Copy the remote IP from  your ovpn files to XXX.XXX.XXX.XXX;
#!/bin/bash ### iptables # flush existing rules iptables -F INPUT iptables -F OUTPUT iptables -F FORWARD # allow loopback access iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # allow already established/accepted connections on all devices # put in front for performance reasons iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # make sure that you can communicate within your own network iptables -A INPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT iptables -A OUTPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT # disable ssh connections over vpn. You just need to disable it, if you have setup port forwarding to your ssh port iptables -A INPUT -i tun0 -p tcp --dport ssh -j DROP # allow outgoing connections to through VPN iptables -A OUTPUT -o tun0 -m conntrack --ctstate NEW -j ACCEPT # allow to establish vpn tunnel americaIp=$(dig +short america.vpn.airdns.org) europeIp=$(dig +short europe.vpn.airdns.org) iptables -A OUTPUT -o eth0 -d $americaIp -m conntrack --ctstate NEW -j ACCEPT iptables -A OUTPUT -o eth0 -d $europeIp -m conntrack --ctstate NEW -j ACCEPT iptables -A OUTPUT -o eth0 -d XXX.XXX.XXX.XXX -m conntrack --ctstate NEW -j ACCEPT iptables -A OUTPUT -o eth0 -d XXX.XXX.XXX.XXX -m conntrack --ctstate NEW -j ACCEPT iptables -A OUTPUT -o eth0 -d XXX.XXX.XXX.XXX -m conntrack --ctstate NEW -j ACCEPT iptables -A OUTPUT -o eth0 -d XXX.XXX.XXX.XXX -m conntrack --ctstate NEW -j ACCEPT iptables -A OUTPUT -o eth0 -d XXX.XXX.XXX.XXX -m conntrack --ctstate NEW -j ACCEPT iptables -A OUTPUT -o eth0 -d XXX.XXX.XXX.XXX -m conntrack --ctstate NEW -j ACCEPT iptables -A OUTPUT -o eth0 -d XXX.XXX.XXX.XXX -m conntrack --ctstate NEW -j ACCEPT iptables -A OUTPUT -o eth0 -d XXX.XXX.XXX.XXX -m conntrack --ctstate NEW -j ACCEPT iptables -A OUTPUT -o eth0 -d XXX.XXX.XXX.XXX -m conntrack --ctstate NEW -j ACCEPT iptables -A OUTPUT -o eth0 -d XXX.XXX.XXX.XXX -m conntrack --ctstate NEW -j ACCEPT iptables -A OUTPUT -o eth0 -d XXX.XXX.XXX.XXX -m conntrack --ctstate NEW -j ACCEPT iptables -A OUTPUT -o eth0 -d XXX.XXX.XXX.XXX -m conntrack --ctstate NEW -j ACCEPT iptables -A OUTPUT -o eth0 -d XXX.XXX.XXX.XXX -m conntrack --ctstate NEW -j ACCEPT # ssh iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT # set default policy iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP  
 
Run switch.AirVPN.sh on your linux system in a tmux/screen session. So you can connect per ssh and load a new vpn server if needed.
 
I hope this post can help others, too

Hello!
 
Problem solved.
 
Kind regards

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!
 
A - If you connect any application to the same TOR proxy OpenVPN connects to, that application traffic will be tunneled over TOR only. That's normal and correct.
 
B - Normal again.
 
1. The question is a little unclear. Anyway, a packet tunneled over OpenVPN over TOR will be encrypted by OpenVPN and then by TOR. The TOR encryption will be no more when the packet gets out of the TOR exit-node to reach the Air server. The OpenVPN encryption will be no more when the packet gets out of the AirVPN server. When passing through all the TOR nodes, your packet "real" payload and header will be still encrypted by OpenVPN.
 
2. Yes, basically, oversimplifying: your node->TOR entry->TOR relay->TOR exit->Air server->the Internet
 
3. Assuming that with TOR -> VPN you mean "OpenVPN over TOR": if OpenVPN is connected over TOR: NO. If OpenVPN is NOT connected over TOR: YES.
 
To say it with different words: if you wish TOR over OpenVPN (without using VM), connect OpenVPN directly, then use TOR. In this case remember that only applications configured to connect to the TOR proxy will have their traffic over TOR over OpenVPN, all the others will have their traffic over OpenVPN only.
 
Kind regards

Hello!
 
That's a good suggestion. Since the birth of AirVPN in 2010, we have never received any request or interference from any government body or representative.
 
Kind regards

Hello!
 
It's an alternative entry-IP address, to be used for OpenVPN connections in case the main entry-IP address is blocked by your ISP.
 
Kind regards

Hello!

The problem in the first article pertains to SSL certificates issued by "authorities", so it may affect us on the website, in case the certificate were stolen from the authority which issued it to us, not on the OpenVPN connections.

Kind regards

Hello,
 
we regret to inform you that Diadem VPN server has been withdrawn because of incompatibility between us and the provider FDC Servers. We received this communication from FDCServers:
 
 
 
Of course we will not comply to requests that have the arrogance to tell us how to conduct our business and would force traffic monitoring and logging that is not required by any law and that is potentially illegal. Additionally, such request comes as a consequence of unproven claims of copyright infringements from one third-party private entity, several of which (and this is very important) we know for sure are fabricated and false (because they refer to alleged copyright infringements on servers ports that are not used at all). FDCServers can rest assured that its services will no more attract our and your money,
 
Kind regards

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.

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.

@Royee
 
Yes, actually they are planned in Eddie, the next client release for Windows, Linux+Mono and OS X. Traffic splitting is not planned though.
 
At this point it's unclear whether you need leaks prevention or traffic splitting. The first will take just one minute configuration, the latter can be very simple or quite complex according to how you wish to split traffic (for example, the NaDre solution, which at the beginning seemed what you needed, will take just a couple of minutes - not considering basic network knowledge acquisition, that vary of course, but the guide is in itself a good lesson/course on the matter as well).
 
Kind regards

Richard Stallman explains the problem with Ubuntu.
 


http://www.fsf.org/blogs/rms/ubuntu-spyware-what-to-do


Linux Mint is also out since it does not support full disk encryption, despite users requesting it for a year.

http://community.linuxmint.com/idea/view/2144

I am not that concerned that I will become a target of surveillance. But as someone with a technical background I have to shake my head that "people in charge" still think it is a good idea to have back doors into products "just in case we ever need it".
 
It is this kind of thinking that lead to the situation described in this CERT alert:
 
https://www.us-cert.gov/ncas/alerts/TA13-207A
 
The description there may not sound very alarming. But if you follow the links to the summary page by the guy who discovered the problem (Dan Farmer - famous in security circles), you may get a better appreciation:
 
http://fish2.com/ipmi/itrain-gz.html
 
The title is "IPMI: Express Train to Hell". And the last paragraph is, "In any case, good luck. We may all need it."
 
If there is back door in Windows, no matter how secure they may think this back door is, I have to think this is begging for trouble.
 
UPDATE:
 
This link by Farmer may not be that easy to find:
 
http://fish2.com/ipmi/
 
There is another line there (at the end) that caught my eye, "It's interesting to note the ubiquity of China in all of these."

@Royee
 
You don't see anything outside Windows because DNS leaks occur on Windows only. In the "How-To" section of the forum you can find various guides to prevent any leak on systems running iptables.
 
Kind regards

Is it not best to assume if anyone is worried the AirVPN servers get raided or we are monitored in any shape or form just to do AirVPN with TOR ?

Do you allow p2p? How can I optimize performance of eMule and BitTorrent with AirVPN?

Yes, p2p is allowed, as well as any other protocol. Currently p2p is a set of the most efficient protocols to share and access information on the Internet. We do not discriminate against any protocol.

To obtain the best performance with a BitTorrent client or an eMule client, log your account in our web site and proceed to remotely forward a port from the menu "Client Area"->"Forwarded ports". Pick a port or let the system choose an available one for you. Pick "TCP & UDP". Remember the port number.

Then, configure the "Port used for incoming connections" (also called "Listening port") in your BitTorrent client so that it matches the port number you have just forwarded remotely. On eMule, go to "Options"->"Connection" tab. Write in both fields of "Client ports" the number of the port that you have forwarded. Disable UPnP, NAT-PMP and any possible automatic port mapping feature that can modify the listening port. 
If you run uTorrent or any other software with bandwidth management, make sure to disable such management (such as uTP in uTorrent).

In this way your clients will be able to accept incoming connections from the Internet, enhancing performance in several cases and making initial seeding possible. This procedure can be performed just once and for all, as long as you don't wish to change port(s) on your clients. On BitTorrent clients, make sure to disable the option to pick random ports at every startup.

If you forward a port for a p2p torrent client, do NOT remap it to a different local port and make sure that the torrent client port matches the remotely forwarded port number, otherwise your client will communicate to trackers (if you use them) and DHT the wrong port: torrent clients will communicate to trackers and DHT the port number you have configured in them. As a result, you will get no incoming packets from the swarm and the torrent client network status token will remain yellow.

IMPORTANT: do NOT forward on your router the same ports you use on your Bittorrent or eMule client (or any other listening service) while connected to the VPN. Doing so exposes your system to correlation attacks and potentially causes uncencrypted packets to be sent outside the tunnel from your client.

Hello,
 
we regret to inform you that Diadem VPN server has been withdrawn because of incompatibility between us and the provider FDC Servers. We received this communication from FDCServers:
 
 
 
Of course we will not comply to requests that have the arrogance to tell us how to conduct our business and would force traffic monitoring and logging that is not required by any law and that is potentially illegal. Additionally, such request comes as a consequence of unproven claims of copyright infringements from one third-party private entity, several of which (and this is very important) we know for sure are fabricated and false (because they refer to alleged copyright infringements on servers ports that are not used at all). FDCServers can rest assured that its services will no more attract our and your money,
 
Kind regards

Hello!
 
Yes, to our frontend, not to the VPN servers. It's an ordinary https connection like a web site login. The Proxy option of the Air client is meant for OpenVPN, not for the client (remember that the client is an OpenVPN wrapper). If you don't want to disclose your IP address to the frontend server, just run OpenVPN directly (or OpenVPN GUI). We don't force (and we will never force) to run any proprietary software to connect to the VPN servers.
 
Kind regards

Hello,
 
no, the Air client itself does not connect to a VPN server, so it does not "communicate" anything to a VPN server.
 
Kind regards

@janern
 
We are not removing the link because it gives us the option to talk about an important security issue.
 
With our service, you don't even have to create manually a file. Our Configuration Generator will generate all the files needed by OpenVPN.
 
Make sure to tick "Advanced Mode", and then tick "Separate certs/keys from .ovpn file".
 
Unfortunately, the instructions you linked talk only about a ca certificate, as if the Astrill authentication method is based only on that (with, optionally, login and password, which would be even worse). That's really a very bad way to build a secure & trusted VPN. Our authentication method is based on client certificate, server certificate and client key, with TLS re-keying at each connection and every 60 minutes (Perfect Forward Secrecy). No VPN server keeps any database of login names, passwords, user names or anything else. This is the correct way to provide a higher security service with OpenVPN. It is so obvious that we are astonished that you even compare a service without the aforementioned features with AirVPN.
 
Since security and strength of the anonymity layer are one of our highest priorities, we're sure you'll understand our decision to never compromise the system to meet the needs of devices that do not implement all the OpenVPN features (IF it's your case, of course), even if that would mean to have some gullible customers that with the current system we can't have.
 
If some services meet your need and our service does not because it provides a much higher security level, it's unfair to blame us, and not only in consideration of the fact that we clearly list all the systems that are compatible with our service. You should blame VPN providers and manufacturers that do not offer the better security options. We see that you have already asked for a refund and that the refund has been granted, so you are free to pick the service that you prefer. If you think that security is not of your concern, there are literally hundreds of low security, low privacy VPN services on the Internet that you can use. Our service will not compromise security and/or privacy for marketing reasons.
 
Kind regards

Hello,
 
old CPUs like Intel P4 2.6 GHz can encrypt/decrypt at least 15 AES-256-CBC Mbit/s. Some time ago it was reported on this forum that an AMD C-60 (a dual core processor from 2010 normally mounted on laptop and netbook computers) running DD-WRT x86 could handle 24 Mbit/s
 
https://airvpn.org/topic/5553-x86-dd-wrt-build/?do=findComment&comment=5575
 
Kind regards

Hello,
 
we regret to inform you that Diadem VPN server has been withdrawn because of incompatibility between us and the provider FDC Servers. We received this communication from FDCServers:
 
 
 
Of course we will not comply to requests that have the arrogance to tell us how to conduct our business and would force traffic monitoring and logging that is not required by any law and that is potentially illegal. Additionally, such request comes as a consequence of unproven claims of copyright infringements from one third-party private entity, several of which (and this is very important) we know for sure are fabricated and false (because they refer to alleged copyright infringements on servers ports that are not used at all). FDCServers can rest assured that its services will no more attract our and your money,
 
Kind regards