Jump to content
Not connected, Your IP: 18.188.183.21

Staff

Staff
  • Content Count

    11046
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1867

Everything posted by Staff

  1. Hello, luckily this is partial nonsense, and total nonsense about OpenVPN (if correctly configured) please see https://airvpn.org/topic/9981-fbi-admits-it-controlled-tor-servers-behind-mass-malware-attack/?do=findComment&comment=12441 Also see https://airvpn.org/topic/9949-us-and-uk-spy-agencies-defeat-privacy-and-security-on-the-internet/?do=findComment&comment=12224 and https://airvpn.org/topic/9949-us-and-uk-spy-agencies-defeat-privacy-and-security-on-the-internet/?do=findComment&comment=12227 and https://airvpn.org/topic/9949-us-and-uk-spy-agencies-defeat-privacy-and-security-on-the-internet/?do=findComment&comment=12242 This is an interesting point, however privacy is a fundamental right as enshrined in the Universal Declaration on Human Rights (art. 12) and in many countries it is a right granted by the Constitutional Charter. Usage of VPNs is massively spread (most of the small and all of the big companies use them for obvious reasons). Probably the more encryption will be properly used, the more the "curiosity" about encrypted traffic will necessarily fade away, because diluted amongst an enormous number of citizens and companies. Kind regards
  2. Hello! It's not planned at all and will not be planned as long as it does not exist in final version. Latest stable version is 2.3.2. Kind regards
  3. Interesting response! How about this senario.1. A court orders the data centre to provide them with logs of all network traffic associated with AirVPN server (source IP address, source port, destination IP address, destination port, time, bytes). Hello! So, they already can see your real IP address in the first place, if that VPN server is the first hop you connect to. So, even if they can't see your real IP address, they can see the exit-IP address of another server of the same company. It can slow it down. OpenVPN over TOR can make it impossible. It is useless in comparison to OpenVPN over TOR. Additionally, OpenVPN over TOR protects you against the VPN provider itself, while multi-hopping to different servers of the same provider does not. Kind regards
  4. @DemonsRuns You mean that you get: RESOLVE: Cannot resolve host address: europe.vpn.airdns.org regardless of the DNS server you query? Can you please give us the list of such DNS servers? We have checked a few minutes ago that the domain name is correctly resolved on every public DNS (except OpenDNS, as usual) we have tested. Kind regards
  5. Hello, please remember to ALWAYS state the exact VPN server(s) name. We can't check if you don't state that, sorry. Kind regards
  6. Hello! The problem is here: 2013-09-18 08:31:14 UDPv4 link remote: [AF_INET]67.215.66.132:443 This is caused by OpenDNS hijacking our *.airdns.org to one of their servers IP address, as if the domain name did not exist. 67.215.66.132 is an OpenDNS server and of course OpenVPN connection fails. You can solve this problem in two different ways: 1) Change DNS (use for example OpenNIC, http://opennicproject.org) and discard OpenDNS once and for all - after all, you might not like to use a poisoned DNS that hijacks your queries 2) Solve the problem at its roots by generating .ovpn configuration files which contain only IP addresses (and not names) in the following way: - in the Configuration Generator tick "Advanced Options" - tick "Resolved hosts in .ovpn file" - tick "All servers for area or region" Kind regards
  7. @nunz Hello! Your account is successfully connected to some VPN server since approx. 15 hours ago. You can see anytime the reason of the last failed connection in your account panel (please click "Client Area" from the upper menu). Kind regards
  8. Hello, some significant advantages of such a setup is the option to keep the whole VM encrypted when it is off, with the additional security that no unencrypted file can ever leak on the host system. These may be extremely important features in some cases (imagine an activist working in a country controlled by a human rights hostile regime). Then there are the 'usual' advantages of a VM: portability (just a file) and isolation of "disasters" in particular. The most important cons you have to consider are: more resources required from the host, slower performance of the guest system (mitigated if you have a CPU supporting hardware virtualization). However, setting up a firewall will be necessary anyway to prevent leaks in case of unexpected VPN disconnection. If the VM is connected to the host machine via NAT, the firewall settings may be simpler on the host side. If the VM is attached to a bridged network adapter, firewall rules will be necessary on the VM itself. You have also another option, i.e. connecting the host to a VPN server, and attaching the VM via NAT to the host. In this case you always need firewall rules on the host side, and all the VMs will have their traffic tunneled 'transparently'. This setup can be additionally hardened (under a security point of view) by connecting the VM itself to TOR or to another VPN, to obtain (in the VM) a multi-hop connection (traffic over VPN1 over VPN2 for example) with multiple layers of encryption at the price of a remarkable network performance decrease. Kind regards
  9. Hello! Yes, port 9150 is the default SocksPort in the TOR proxy bundled with the latest TBB versions, other packages can have the TOR proxy configured to listen to port 9050 or other ports, please check. Kind regards
  10. Hello! Can you please publish the Tunnelblick logs, taken after the problem has occurred? Kind regards
  11. Hello! By default (when you register an account) it's already off. You must specifically turn it on if you wish it. It can be useful for troubleshooting, in case of issues, or to monitor the traffic volume (for example for users on a traffic-volume-limited connection). Kind regards
  12. 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
  13. 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
  14. 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
  15. 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
  16. Hello! The percentage shows the BUSY bandwidth on a server. Please do not pick 100% bandwidth busy servers. Kind regards
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
×
×
  • Create New...