Jump to content
Not connected, Your IP: 18.224.31.82

Staff

Staff
  • Content Count

    11042
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1866

Everything posted by Staff

  1. Hello! A general solution is layer 7 filtering on your physical interface (so that p2p will be blocked only when you are not connected to the VPN). pf is perfectly capable to do that, but it's not an easy solution. Since you want to block "yourself", you don't have to bother about all the possible cases. You can just block all and every port used by your p2p client (either with a "whitelist" or a "blacklist") on your physical network interface, so the p2p client will be able to send and receive packets only through tunx. Kind regards
  2. Hello! You can also accept BTC for (some of) your work / sales / services or anything else you do in your life. Usually this is the easiest way to earn BTC. About anonymity, we recommend you tunnel your Bitcoin client over TOR (the default client has an immediate option to do that). If you feel that your wallet compromise your anonymity, just use another one to subscribe to the VPN. You have no limits on the number of wallets, obviously, and you can transfer anonymously BTC from a wallet to another. Kind regards
  3. Hello! You're welcome. Just for your and other readers information, a quick clarification (otherwise someone might think that security is compromised). The router might be the cause of such dramatic fluctuations, but not for the number of connections. The router sees only one connection on one port. The effective number of connections are handled on one side by your OpenVPN client and on the other side by our servers. The "real" headers and payload of every packet (both outgoing and incoming) are already/still encrypted when passing through the router, therefore they are not accessible to it. You might like to check the CPU load on your computer when you experience a bandwidth drop, just to see if there's some bottleneck on the OpenVPN client side (our servers have usually an approximate 0 average load). Kind regards
  4. Hello! AndyG, should you use OpenVPN in DD-WRT with your router you should expect 7-8 Mbit/s at best, due to CPU power as explained by yerozard. 20 Mbit/s on Draconis with a connection from your computer appears perfectly normal. You have to also consider that the 70/10 Mbit/s provided by your ISP are the maximum peak bandwidth you can obtain, not a guaranteed bandwidth. Routing and peering are to be taken into consideration. That said, please test all the other EU 1 Gbit/s servers (Tauri, Castor and Delphini) to check whether you can obtain a better performance. All of them are located in data centers with POPs directly connected to all the major tier1 EU providers (including the "big four"). Please feel free to let us know your experience with the above servers. Kind regards
  5. Hello! Usually this is a problem with some firmwares, and the solution is flashing a newer firmware. However, the quoted log line poses some questions. Can you please tell us what the address 10.2.1.2 is? Is it the router's address? The remaining log looks just fine (apart, of course, the series of connections and disconnections). Also, your DD-WRT router is using tun1 interface. Therefore, you need to modify accordingly your iptables rules, because in our examples we assume tun0 as the interface managed by OpenVPN. Kind regards
  6. Hello! AirVPN Client requires the .NET Framework 2 (not 4). This framework is pre-installed in XP and above, but maybe you use a minimal XP. Try to download and install Framework 2 from here: http://www.microsoft.com/en-us/download/details.aspx?id=19 Kind regards
  7. Hello! Can you please send us the failed connection logs? Kind regards
  8. Hello! First, please keep in mind that the Air client is for Windows only. For other OS, you can use OpenVPN directly or any OpenVPN GUI/wrapper. You have at least two options. 1) Tunnel your host over Air over TOR and connect the guest(s) with the VirtualBox NAT (not bridged). In this case all the guests will be tunneled transparently IF they are connected with the VirtualBox NAT. You'll need to install OpenVPN and Tor Browser bundle in your host. Also, you'll need to forward ports in VirtualBox NAT to make your guest capable to use the remote port forwarding feature of our system. You'll just need one account. 2) Tunnel your guest over Air over TOR. In this case only the guest (regardless whether it is bridged or NATted) will be tunneled over Air over TOR, while the host will not be tunneled, not even over Air. You'll need to install OpenVPN and Tor Browser Bundle in each guest. Also, you'll need a different account for each guest which connect simultaneously. Kind regards
  9. Hello! We're very glad to know that you could manage to solve your problem. Yes, if this setup works on your system, it's not worth to modify anything. It already works in this way. However, your tun interface must be able to send and receive packets from/to any IP through your physical adapter, and the physical adapter only sees packets that have "real" header and payload already encrypted. When there's a VPN disconnection, the original routing table is restored. Therefore the "key factor" to prevent leaks is that your physical adapter must be authorized to communicate only with our VPN servers, so Comodo needs to know the entry-IP addresses of the servers. A different solution with Comodo is allowing outgoing packets only if coming from the tun adapter (i.e. only if coming from the IP range 10.4.0.0->10.9.255.255), as it has been described in the main thread. In this case, you don't need to set rules for your physical adapter, but you'll have to configure every and each application that you use (or any relevant application) and system applications (especially svchost.exe, to prevent DNS leaks) with the above rule. This is a solution particularly suitable for clients who just want to block certain traffic (for example p2p) while allowing other traffic when disconnected from the VPN, so probably your current setup is the one which really meets your requirements. Kind regards
  10. Hello! We re-send you a synthesis of our replies here in the forum for your comfort. The logs show that you have been connected without interruptions for several hours (since 5:59 AM till 6:40 PM). The connection was working because, as you can see, OpenVPN renegotiated successfully the TLS key every hour, as it is expected to do with our configuration. The TLS key renegotiation is an additional OpenVPN security feature which causes no delays in the connection, since the key renegotiation is performed with "overlapping windows" (another nice OpenVPN feature). After the disconnection, caused by an intervention on your system, your system could not resolve "airvpn.org" in order to reconnect, a problem you can immediately solve (instead of changing Comodo rules each time) by editing your hosts file, just add the line: 46.105.19.36 airvpn.org Kind regards
  11. Hello! We confirm that our setup uses a TUN interface (routed VPN), not a TAP one (not bridged VPN). The name of the interface can vary according to your system setup, by default anyway it's tun0. When writing such an application, the key problems to consider are the time between disconnection detection and applications kills or disconnection. We have seen some utilities for which such time is enough to potentially allow leaks. If you opt for application kill, another consideration is the "violence" of the technique, which potentially may result in lost or corrupted data. Kind regards
  12. Hello! We'll consider your suggestion, thank you. Bitcoin can be easily given a strong anonymity layer, just tunnel it through TOR. Kind regards
  13. Hello! Under a privacy point of view, they are all the same. So you can concentrate on the servers which give you the best performance (due mostly to geographical and peering considerations). Choosing servers which have a low bandwidth usage is another key factor to be considered. Currently we don't limit connections on any server, we leave our clients total freedom on that, so we recommend to have a look at our real time monitor to see immediately the current bw usage. The quickest way is keeping different configurations for each server and port, so you can switch between them with a click. Kind regards
  14. Hello! You clearly have problems in receiving e-mails. Please check the issue, otherwise we will keep sending you e-mails and you will never be able to read any of them. That said, we tend to avoid duplicates in the forum, so already answered questions will be replied only via mail, not again and again on the forum. Kind regards
  15. Hello! Can you please disable "Monitor connection" and check whether it solves the problem? Please see also: http://code.google.com/p/tunnelblick/wiki/cKnown If "Monitor connection" is checked, Tunnelblick monitors the network interface that connects to the VPN and will restart the connection if changes to DNS or WINS are detected. With some network configurations this causes repeated disconnects/reconnects every few seconds. To avoid this, uncheck "Monitor connection" for the problematic configuration on the "VPN Details…" window. Please post your complete log (showing the problem with "Monitor connection" checked) to the Tunnelblick Discussion Group so we can fix this problem. (Be sure to cross out any sensitive information such as server IP addresses before you post your log.) Kind regards
  16. Hello! It's possible, there is just some work to achieve that if you have UAC enabled. We have prepared the instructions on the following page: https://airvpn.org/windows_autostart Kind regards
  17. Hello! Probably you've already performed all the necessary steps to obtain the best performance from our servers. Now you could concentrate on your system: with Comodo you can check whether some applications are intermittently devouring bandwidth without your knowledge. Kind regards
  18. Hello! We don't detect any problem with Lyra at all... currently several clients are connected and exchanging data. No packet loss is detected, all the processes run smoothly and the CPU load is almost 0. Perhaps a momentary issue between Lyra and your ISP? Kind regards
  19. Hello! More and more ISPs around the world disrespect Net Neutrality and deprioritize or shape packets on some or all UDP ports. Please try a connection to ports 443 TCP and 80 TCP to see whether the performance improves. They display the bandwidth being used by clients in that moment. Kind regards
  20. Hello! We don't monitor connections and we don't perform packet shaping of any kind. Did you change something in your torrent client configuration? Did you change firewall or antivirus program? What is your OS and torrent client? Kind regards
  21. Hello! The Air client, which is basically an OpenVPN wrapper with additional commodities, performs a check at the beginning of the connection and then waits for messages from OpenVPN (in particular, it monitors the connection to detect disconnections). Since you say that using OpenVPN gives you no problems, chances are that the Air client is not running properly. If you wish, you can send us the connection logs for troubleshooting. You might also like to read here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&Itemid=142 Kind regards
  22. Hello! Perhaps the SOCKS proxy you are using is not accepting connections or maybe it is listening to another port? Which SOCKS proxy do you use? The logs can give precious hints. Kind regards
  23. Hello! Please check whether your firewall is blocking the AirVPN client and/or OpenVPN and/or the ports used for the connection (for example 443 UDP). Finally, please send us all the relevant information: your OS, the client you use to connect, the connection logs and any other displayed error (if available). Kind regards
  24. Hello! We confirm you that port forwarding is working perfectly on all the VPN servers (last check a hour ago). Please check that you have forwarded a port both TCP and UDP and that the port your torrent client listens to matches the remotely forwarded port number. Also, make sure: - NOT to remap the remotely forwarded port to a different local port because this may cause troubles with uTorrent - that you have disabled in your torrent client the "random listening port" feature, which causes a port change at each run - that you have disabled the UPnP / NAT (or any other port remapping feature) and uTP options in your torrent client - that your firewall is not blocking your torrent client on any network Kind regards
  25. Staff

    Trial

    Hello! Yes, we do offer free trials, but it's currently not possible to meet the very large amount of daily requests. Please feel free to re-send your request if you don't get an answer within 2 days. Kind regards
×
×
  • Create New...