-
Content Count
11528 -
Joined
... -
Last visited
... -
Days Won
2037
Everything posted by Staff
-
Tunnel only traffic on a couple of ports
Staff replied to PsychoWolf's topic in General & Suggestions
@PsychoWolf Hello! It definitely looks like a firmware OpenVPN known bug. Probably a re-flash with a different firmware is necessary. Please see here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=4684&Itemid=142#4687 and here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=4684&Itemid=142#4690 for Linksys E2000 and E3000 DD-WRT firmware versions that are reported as fully functional. Kind regards -
Hello! We're very glad to inform you that a new 1 Gbit/s server located in Switzerland is available: Virginis. 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 "Member Area"->"Access without our client"). The server accepts connections on ports 53, 80 and 443 UDP and TCP. 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 admins
-
Tunnel only traffic on a couple of ports
Staff replied to PsychoWolf's topic in General & Suggestions
Hello! Can you please send us the connection logs? Kind regards -
Hello! You might like to start from here: http://en.wikipedia.org/wiki/Vpn AirVPN is based on OpenVPN: http://en.wikipedia.org/wiki/Openvpn http://openvpn.net/index.php/open-source/335-why-openvpn.html Kind regards
-
Hello! Thank you for the great job. Don't worry, messages are not lost, they just need to be approved by a moderator before they show up. Kind regards
-
Hello! Remember that you can have a full refund within 3 days since you subscribed. That said, have you tried different ports? Several ISPs cap bandwidth on some UDP ports. Also, can you please send us your client logs? You can see normal bandwidth which most clients with high bw lines are able to use on our servers in the "Top 10 Users Speed" in our monitor https://airvpn.org/status Kind regards
-
Any Swiss replacement servers planned? Hello! Yes, we should be able to provide more connectivity in Switzerland during the next week. Kind regards
-
Hello! Setting up Comodo rules requires a basic knowledge of Comodo firewall. This simple guide will let you use the firewall at its best: http://personalfirewall.comodo.com/Comodo_Internet_Security_User_Guide.pdf You can concentrate on the firewall section, skipping all the other parts. Kind regards
-
Hello! Due to repeated copyright alleged infringement notices (three in one month ) we have no choice but to dismiss Aquarii (the ISP will shut it down anyway). Please disconnect from Aquarii as soon as possible. Kind regards
-
Hello! TPB is now accessible from Vega. Kind regards
-
Hello! Using PeerBlock is surely a courtesy toward us, because it may slightly help us receive less bogus copyright infringement notices. However, the PeerBlock protection against them is so small, that you can safely renounce to it. If you wish to use PeerBlock anyway, you will have to remove from the blocklist you're using the LeaseWeb entry and exit-IP addresses of our servers with LeaseWeb: - all the NL servers - Tauri in Germany - Librae and Sirius in the USA or you'll have to use a non-LeaseWeb server. The solution to allow our servers entry and exit-IP addresses is the safest one. Kind regards
-
Hello! Unknown. Possible explanations: - momentary congestion/packet loss/high latency between your and our ISPs - bad WiFi connection (to rule out if you are cable-connected to your router) - crash/misbehavior of some network card driver (including the TUN/TAP adapter) - misbehavior/crash of your router - a replay attack (https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3773&Itemid=142#3784) If it occurs again please notify us and at the same time try a connection to the same server but on a TCP port, and also to UDP ports of different servers. Kind regards
-
Hello! We haven't tested the program you cite. Generally speaking, the problems with this approach are: - the time between disconnection detection and program forced kill might allow anyway a leak; about this, you should test carefully the program in order to determine whether it's the case or not - a forced program kill may potentially cause lost or corrupted data, so please be aware of that - contrarily to firewall rules, this approach might not protect you against correlation attacks Kind regards
-
Hello! Can you please tell us, at your convenience, how the "Authenticate/Decrypt packet error: bad packet ID" problem was solved on your system? Did it disappear by itself or did you do something? Kind regards
-
Hello! Can you please send us your client logs? Kind regards
-
Hello! Can you please try to connect again and send us the beginning of the logs, before all the packet authentication/decryption errors? For comments about the part of the logs you already sent us, please see here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3773&Itemid=142#3775 and here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3773&Itemid=142#3784 (replay attacks explained) Kind regards
-
Hello! We're glad to inform you that a string encryption tool is now available to all Air website visitors. The tool allows to exchange encrypted messages on the Air website without letting anyone on the network (not even AirVPN website administrators) see the message, eventually not even the encrypted message. All the encryptions and decryptions are performed by the browsers without sending out any data. On the tool web page you will find all the instructions to use it and an explanation on how it works. The tool is accessible through menu "More"->"String Encryption Tool", direct link https://airvpn.org/encrypt Kind regards and datalove AirVPN admins
-
Hello! Ok. Can you please send us your client logs? Kind regards
-
Hello! We're glad to know that the problem is solved. However the behavior you report is odd. Can you please send us the content of your hosts file and how your system resolves airvpn.org? Thank you for your nice word, they are much appreciated. Kind regards
-
Hello! A possible explanation is that you were browsing the Air website before you established a VPN connection. Even if you establish a connection while the browser is browsing websites, already established connections to those websites will remain open (that's perfectly normal). Try to run your browser after you have connected to an Air server. Kind regards
-
Hello! Please feel free to report here any website not accessible from Vega. We're already aware about yahoo.com. Kind regards
-
Hello! We confirm the issue. There is no block from Vega or from Vega datacenter and the routing is correct. The packets are rejected or dropped somewhere in the piratpartiet network, or by The Pirate Bay itself (perhaps TPB blacklisted Vega exit-IP for some abuse). We will be working to circumvent the block. In the meantime, we kindly ask you to connect to any other server in order to have access to TPB. Kind regards
-
Hello! You can achieve your purpose with DNATting. Make sure that you have remotely forwarded the ports you wish. Then please add the following iptables rules for each TCP/UDP port you wish to forward: iptables -t nat -I PREROUTING -i -p tcp --dport -j DNAT --to-destination iptables -t nat -I PREROUTING -i -p udp --dport -j DNAT --to-destination where: - is the port number of the port you want to forward to a device - is the IP address (for example 192.168.x.y) of the device you wish to forward packets on that port to - is the TUN/TAP adapter name (for example tun1) Kind regards
-
Hello! It's the TLS rekeying, an OpenVPN smart feature. You can't increase that time (it should be done on the server side) but you don't need to. It is a nice security feature which does not add any practical overhead. During SSL/TLS rekeying, there is a transition-window parameter that permits overlap between old and new key usage, so there is no time pressure or latency bottleneck during SSL/TLS renegotiations. The main load on the CPU is the encryption/decryption on the data channel, currently AES-256-CBC. We're sorry, we have no plans to lower encryption strength on the data channel. On the contrary, we are evaluating whether to raise it up in the future. A dual core Atom can handle at least 35 Mbit/s throughput with AES-256-CBC, while even old processors (from Athlon64 and newer) should have no problems to handle at least 100 Mbit/s. Low-consumption old CPU on DD-WRT routers can handle up to 7 Mbit/s. Kind regards
-
Hello! The rules you published are blocking any packet from and to 95.211.169.3, the server you're trying to connect to. In order to allow access to 95.211.169.3 please add the following rules and put them higher than the block rule: Allow IP In/Out From IP 95.211.169.3 To MAC Any Where Protocol Is Any Allow IP In/Out From MAC Any To IP 95.211.169.3 Where Protocol Is Any Also, the airvpn.org IP has changed to 85.17.207.151, please modify it. The Network Zones look fine except perhaps the [Home Network]. Just make sure that in your Home Network the IP range is the one you specified, just in case you need [192.168.0.0 - 192.168.255.255] instead of [192.168.1.1 - 192.168.255.255] (if everything is fine, then you don't need this change). Kind regards
