Jump to content
Not connected, Your IP: 3.145.172.146

Staff

Staff
  • Content Count

    10932
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1843

Everything posted by Staff

  1. Hello! When you connect OpenVPN over TOR, if you run a browser that's configured to connect over the same TOR proxy which OpenVPN connects to, that browser traffic will be tunneled over TOR only. In order to tunnel a browser traffic over OpenVPN over TOR, first connect OpenVPN over TOR, then run a browser that is NOT configured to connect to the TOR proxy. In order to tunnel a browser traffic over TOR over OpenVPN, first connect OpenVPN directly (i.e. NOT over the TOR proxy), then launch TOR and use a browser that IS configured to connect over the TOR proxy. With OpenVPN over TOR our VPN servers can't see your real IP address and the TOR nodes can't see your traffic. Your packets "get out on the Internet" with the VPN server exit-IP address. With TOR over OpenVPN our servers can't see your traffic and the TOR entry-node can't see your real IP address. Your packets "get out on the Internet" with the TOR exit-node IP address. Kind regards
  2. Hello! Ok. Please remember that you need to run OpenVPN GUI with administrator privileges. From the piece of log you sent us, OpenVPN had "access denied" to interfaces. Kind regards
  3. Hello! Why? It's not necessary at all to keep logs for those stats. You just increase counters of servers and accounts when they are online, when they disconnect they are lost. Kind regards
  4. Hello! Apparently your local proxy is not running or not listening to port 9150, can you please check? Can you tell us which proxy are you running, is it a TOR proxy? Kind regards
  5. Hello! The percentage shows the BUSY bandwidth on a server. Please do not pick 100% bandwidth busy servers. Kind regards
  6. Hello! We're very glad to inform you that a new 100 Mbit/s server located in France is available: Furud. 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, Furud 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
  7. Hello! Is the Verizon DNS inserted somewhere in your router or in the device used to perform the DNS check? If so, wipe it out. Kind regards
  8. Hello! Assuming that you use the Air client: - in order to change port, after you have picked a server click on the "Modes" tab, select a port and protocol (for example 53 UDP) and click "Enter". - in order to send us the logs, please right-click the Air dock icon (a white cloud), select "Logs", click "Copy to clipboard" and paste into your message. Kind regards
  9. Hello! Yes, that's normal: in your case OpenVPN is commanded by the Air client, not by OpenVPN GUI. In reality, you should not even launch OpenVPN GUI and the Air client simultaneously. Just run whichever you prefer, but not both at the same time. That's normal, it's an old-time Windows glitch based on an unreliable method to determine whether a connection is working or not. The 10 Mbit/s value is just a bogus hard-coded parameter (it's there since so many years in OpenVPN tun/tap package), it does not mean anything. The tun/tap adapter is the virtual network interface used by OpenVPN. Kind regards
  10. Hello! First of all, please try connections to different servers AND different ports. In particular, please test port 53 UDP and 80 TCP. Can you also please send us the client connection logs? Kind regards
  11. Hello! Can you please send us the Air client logs taken just after the problem occurs? Please right-click on the Air dock icon (a white cloud), select "Logs", click "Copy to clipboard" and paste into your message. Kind regards
  12. That sounds very unlikely. I use ufw on Linux with 2 extremely simple rules. Allow out anything on tun0 and allow in from anywhere to port xxxxx on tun0 (where port xxxxx is the one I open and forward to use in Transmission). Otherwise all packets are dropped. That's all. I can post my exact rules if you'd like. Hello! The problem is here (or at least part of the problem). You should allow anything to tun0 on all ports, because you can't foresee which source port will be used by any application (remember that tun0 is the virtual interface used by OpenVPN, where packets are still/already unencrypted). So in several circumstances you actually block everything except incoming connections to Transmission from the Internet. But tun0 must also communicate with eth+ or wlan+. According to the exact rule definition, it might even block communications between eth+ (or wlan+) and tun0, causing a total tunnel disruption, and that would also explain the apparently erratic behavior you observe. There is one more thing to check, i.e. if there are packet inspection tools on the router which could trigger a traffic block in case of elevated UDP traffic, but this is most probably not the case, because the ultimate proof is that when you disable ufw everything works fine. Kind regards
  13. Hello! That's not necessary, our TLS web server implementation includes Perfect Forward Secrecy, so a different TLS key is negotiated (through ECDHE or DHE, according to your browser) with airvpn.org server at each SSL/TLS connection (provided that you don't run an obsolete browser or IE 8 in Windows XP). The underlying preferred encryption is AES-256 (but you can change your preferences on the cipher from you browser) making any attack revealed by the recent leaks ineffective. Please check here: https://www.ssllabs.com/ssltest/analyze.html?d=airvpn.org Anyway you can change your web site password as many times as you wish from your control panel. Yes, until the account subscription expires or you explicitly require account de-activation. Kind regards
  14. Hello! Ok, another of our DNS servers runs on 54.246.124.152, it is a failover DNS in case the first VPN DNS server fails. So it's not a leak. However, you should see it only when the first DNS fails. It remains to be seen why ipleak.net does not display it and dnsleaktest.com does. From various tests, dnsleaktest does not display it (at moment of this writing) from Cephei. Maybe 184.75.214.163 DNS failed just when you run the test, causing the query to be sent to the "backup" DNS. We will investigate, anyway no action from your side is required and no DNS leak is occurring from your system. Can you please tell us whether you get those results on a regular basis? If so, can you please try to delete "10.5.0.1" and "10.6.0.1" (using therefore only 10.4.0.1) and test again? Kind regards
  15. Hello! 1) This is typically caused by ISPs which hijack packets to port 53 UDP to their own DNS servers (for example Vodafone Italia). 2) As far as we can see, most firewalls do not cause any performance hit, provided they are not configured to inspect packets or to log excessively. Packet inspection of encrypted packets can cause heavy system load (and it's not useful, because the packets are encrypted). Can you please tell us which firewall you disabled to have better performance? Kind regards
  16. Hello! The discrepancy is very strange. Is the 2nd DNS displayed by dnsleaktest a "plausible" one? We'll need to investigate on the matter. In the meantime, can you please tell us your DNS settings in your DD-WRT router? Kind regards
  17. Staff

    Uptime?

    Hello! 24/7 connections are of course allowed. We plan to publish the VPN servers uptime in some statistically significant time frame very soon. In the meantime have a look at the tables on the right in the servers monitor https://airvpn.org/status Kind regards
  18. Hello! Yes: please see the list of available servers and additional information here: https://airvpn.org/status Servers switches are unlimited and free. Kind regards
  19. Hello! PKCS#12 is not supported. Which point of failure are you referring to? user.key is transmitted to you over a TLS connection, and anyway possession of the key by an adversary does not allow him/her to decrypt any of your past, present and future communications to/from the VPN server. Kind regards
  20. Hello, we don't understand. or should i do something else, such as reinstall OpenVPN? First try to insert the correct full path to the .ovpn file or make that path your shell current directory Kind regards
  21. Hello! Yes, this is provided by the remote-random directive. Please generate a configuration file in the following way: - tick "Advanced Mode" - tick "Resolved hosts in .ovpn file" - tick "All servers for area or region" It might be that you have some old IP addresses of servers that are no more operational. Now and then we lose servers due to conflicts with the provider. Kind regards
  22. Correct! Kind regards
  23. Hello! We're glad to know that you discovered where the problem lied. The button works just fine. When you pressed that button, your device reconnected automatically (and correctly) in a matter of seconds. That's why you and us saw different connection times, and why the web page never refreshed. Everything has been explained now. Kind regards
  24. Hello, currently your account is not connected. Can you please send us the OpenVPN logs pertaining to one of this type of failed connections? Kind regards
  25. Hello, sorry, we do not offer this option by default, which is considered substantially useless and less secure in comparison to TOR over OpenVPN (or OpenVPN over TOR), because all the nodes are operated by the same entity. Kind regards
×
×
  • Create New...