Jump to content
Not connected, Your IP: 18.119.172.146

Staff

Staff
  • Content Count

    10626
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1772

Everything posted by Staff

  1. Hello! That message shows clearly that our system was able to reach some service on your computer on your REAL IP address and that it received an answer from your real IP address. This might expose you to correlation attacks. First of all, please make sure that all your router ports matching the ports remotely forwarded on our system are NOT open. For example, if you have forwarded ports 12345 and 12346, check that ports 12345 and 12346 on your router are closed or stealth. Also, can you please let us know which service you're running when you receive that warning? Kind regards
  2. Hello! Your system has been unable to load the certificate: which caused lack of connection since 7.08 PM till 9.52 PM. Determining why your system had this problem is impossible from the logs: the subsequent connections are just fine, except for a minor, inessential packet loss. Please make sure that you give the Air client administrator privileges when you run it. PeerBlock should have nothing to do with this problem, anyway its usage is not necessary when you're connected to the VPN. On the contrary, we would strongly recommend you to install Comodo personal firewall (free edition) and secure your connection, in order to prevent any leak and IP exposure in case of unexpected VPN disconnection and in case your system routines fail again to load files or in any other unexpected failed connection. Please see here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 Kind regards
  3. Hello! As far as we know, this setup can work, but only if the DLink Router is set to work in pure bridge mode. Can you please check that DLink Router is in bridge mode? This may be a problem. You might like to read here for a setup extremely similar to yours which is now working: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1840&limit=6&limitstart=6&Itemid=142#1866 This is correct. Kind regards
  4. Hello! In order to verify that, you might like to monitor the in/out traffic through the Comodo firewall "Show active connections" window or, even better, with Wireshark. http://www.wireshark.org Kind regards
  5. Can you check Tauri ? Thank you Hello! Done, everything is in order, but we could not check your account because at this very moment it does not appear connected to Tauri. Please let us know at your convenience if it's all right. Kind regards
  6. Hello! We don't detect port forwarding problems with your account or with Sirius, could you please check that: - the service is running and listening to the correct remotely forwarded port - the service has been launched after you have connected to the VPN server (in case, restart it) - no firewall is blocking packets to and from your service We're looking forward to hearing from you. Kind regards
  7. Hello! Thank you! It might be a client glitch or bug. We'll pass the information to the Air client programmer. Kind regards
  8. Hello! In the "Checking" phase the Air client asks airvpn.org "Which IP address do you see me connecting from?". The frontend replies and if the IP address is one of the VPN servers exit-IP addresses the Air client is sure that the tunnel is working. If the IP address is not one of them, the Air client starts a new connection. Kind regards
  9. No, the server is not connected by OpenVPN to one of the Air servers. Hello! In this case you don't need to remotely forward port 2242. Not necessarily. Port 2242 is reserved to some other client and it is dynamically forwarded to that client only when it is connected and only on the server it connects to. Kind regards
  10. Hello! The connections is correctly established but the check from the Air client fails. Usually there are two main reasons for this: - the connection drops immediately after it has been established, OR - after the connection the client can't access anymore airvpn.org for the security check of established connection Can you please try a connection directly with OpenVPN, or with the OpenVPN GUI? When you have connected (or tried a connection) with OpenVPN, can you please send us the output of the commands "route print" and "ipconfig /all" (from a command prompt or the PowerShell)? Kind regards
  11. Hello! The backend server was replying to VPN servers but incorrectly and it also had a low load. So the VPN servers assumed that the 1st backend server they queried was ok and would not try a connection to the subsequent backend server. On the contrary the primary frontend (website etc.) correctly connected to a different backend server (the backend servers have a clustered database so they are constantly "aligned"). The result was a refusal of any new connection from the VPN servers, while the website was still up. Another detrimental consequence was that the monitoring system did not detect any problem, so it did not send any urgent warning message to the techies. Some changes have been applied on the backend server which had this problem. Since it has happened for the first time after we implemented, some months ago, a clustered database, we're still investigating to gain a deeper understanding of the issue. Kind regards
  12. Sorry, I tried to upload more than 1 screenshot. Hello! Ok, now we have all the information we need. A rule is missing: iptables -I OUTPUT -o ! --dst a.b.c.d -j DROP # if destination for outgoing packet on is NOT a.b.c.d, drop the packet, so that nothing leaks if VPN disconnects # the above line can be duplicated for as many Air servers as you wish to connect to, just insert the appropriate Air server entry-IP This is the rule which will prevent leaks. a.b.c.d is the entry-IP address of the Air server DD-WRT router connects to. is your router network interface (probably br0, determine its name with command "netstat -r"). Important! Please note if you use the last entry above in the firewall (iptables -I OUTPUT -o br0 ! --dst a.b.c.d -j DROP) you will lose access to the router. Thus if the tunnel goes down ...well you know. So you may want to leave this entry off the GUI and if/when you are set up properly and then run it from the telnet prompt. That way if you need router access you can reboot and be OK. Please see also zdrifter post for more details. Kind regards
  13. Before there were several dns servers listed including my isp, now only my isp. Hello! Ok, this new screenshot shows what you say. We should examine the iptables rules. Kind regards
  14. Before there were several dns servers listed including my isp, now only my isp. Hello! They are not visible on the screenshot which is pertaining to the DD-WRT web interface. You should watch at the DNS servers displayed in the leak test site. Anyway, does the dns leak site display your ISP DNS? If so, can you please post your complete iptables rules list? Kind regards
  15. Hello! Can you please try again now? Kind regards
  16. Hello! We don't detect any problem anymore. Should you have any further issue, please do not hesitate to contact us. Kind regards
  17. Hello! We have detected a problem on Serpentis port forwarding and potentially on other servers. It is probably related to the previous backend problem (the VPN servers need to know which ports are to be dynamically forwarded to which IP address inside the VPN). While all the connections between all the servers are re-established, this problem will be solved automatically. Please let us know which server(s) you detect the problem if it's not solved within a few minutes. Kind regards
  18. Hello! Thank you very much, we're very glad and proud of this review. We would love to read the whole book as well! Can you give us the coordinates to buy the book? True, especially thanks to how OpenVPN works (if properly configured). Also, the different entry-IP and exit-IP addresses of each server prevent nasty correlation attacks against which even OpenVPN is powerless (it's not an OpenVPN fault, it's how the Internet works ). You will see a constant infrastructure expansion on various countries, some of them included in your list. We are also preparing new services which will be available in the next weeks to help people connect in countries where OpenVPN connections are disrupted. Unfortunately OpenVPN does not support XTS. In the future we will evaluate a change of cypher-system, however this is a delicate operation because it will force our clients to re-download configuration files. DD-WRT users might be forced to re-flash their router with new firmwares which implement latest OpenVPN versions. Currently AES-256-CBC, RSA 2048 bit key, double certificate authentication and TLS renegotiation provide a higher-than-military degree of security on the cypher-system side, without an excessive computational burden on older CPUs. It's true that our servers are (also) networking sharing devices. Sharing a device is a necessary prerequisite to keep a strong anonymity layer. The WIMIA test software is closed and undocumented. Currently, experts suggest that WIMIA maintainers also add IP addresses and IP ranges from dedicated servers providers on their database. Therefore there's no way to fool a WIMIA test if any person sends them one of our servers exit-IP addresses (they also have a form that can be used by snitches). This may become a problem if more and more web administrators will bar access from VPNs using WIMIA, however the more privacy awareness (as well as usage of NATs from ISPs) spread, the more this problem will heap only on those websites. We're looking forward to hearing from you. Kind regards
  19. After reading zdrifter's post I found that I use tun1 interface. I added the new iptables (except for the last line) in the firewall and saved. I still have a dns leak confirmed with http://www.dnsleaktest.com Hello! Can you please tell us which DNS servers are displayed by the dns leak test? Kind regards
  20. Hello! A backend server is a machine which works "behind the scene". No client ever communicates directly with it, but the VPN servers do for various purposes (remember, we don't keep ANY database on VPN servers for security reasons). When a backend server does not respond, the VPN server queries the next one (and so on) - a redundancy system to keep the system up even if one or more servers are down. In this case, the system worked partially when a backend server began to have problems: the website could remain up, but establishing new connections to VPN servers was not possible. We're investigating. Kind regards
  21. Hello! We have had a major problem on one of our backend servers. The problem did not affect already established connections or the website, but it did prevent new connections. The failover system worked only partially . The problem has been now fixed, however we are still working on the system so please do not hesitate to contact us for any further issue. Kind regards
  22. Hello! We have had a major problem on one of our backend servers. No attacks, no pressure from any entity (except the usual spammers, but that goes on by default ). The problem prevented new connections to our servers and has been now fixed. However, we're still working on the system in order to ascertain why the failover redundancy system worked only partially, therefore please do not hesitate to contact us for any further issue. Kind regards
  23. Hello! We have had a major problem on one of our backend servers which prevented new connections. The problem has now been fixed, can you please try again? We're still working on the system, so if you find any issue please do not hesitate to contact us. Kind regards
  24. Hello! We have had a major problem in one of our backend servers. It did not affect already established client connections but it did prevent new connections for 5 hours. The problem has been now fixed. However, we're still working on the system, so please do not hesitate to contact us for any issue. We apologize for the inconvenience. Kind regards
  25. Hello! We have had a major problem in one of our backend servers. The failover system worked only partially and we needed some time to restore everything. The problem did not affect already connected clients, but it did prevent new connections for about 5 hours. The problem has been now fixed. We're still working on the system, therefore please do not hesitate to contact us for any issue. We apologize for the inconvenience. Kind regards
×
×
  • Create New...