-
Content Count
11043 -
Joined
... -
Last visited
... -
Days Won
1866
Everything posted by Staff
-
Hello! It's already pushed by the OpenVPN server: 10.x.0.1 (see also here for more details: https://airvpn.org/specs ). 10.4.0.1 is anyway accessible regardless of the port your system connects to. Kind regards
-
Hello! If you wish to tunnel DNS queries to Comodo, set Comodo DNS in your TAP adapter. Using non-VPN DNS ours prevents you to access VPN internal services (currently only speedtest.air) and also prevents you to access geo-discriminatory services from all servers (for example, if you wish to access BBC iPlayer from servers NOT located in the UK you must use our DNS). Kind regards
-
Hello! Try and monitor the packet flow in your interface (while disconnected from the VPN and everything should be blocked) with Packet Peeper or similar tools: http://packetpeeper.sourceforge.net If you see that packets flow out from your network card to various destinations, re-check your pf setup, make sure it is active, and if everything is confirmed please report to pf developers and/or Apple customer support. Kind regards
-
Hello! Actually it's interesting, those instructions suggest to restart the DHCP client service before trying a complete stack reset. In our tests, when the problem occurred, if an ipconfig /renew and a normal reboot did not work we jumped to reset the winsock catalog and perform a reboot, we did not try to restart the DHCP client service. If it works and it does not require the aforementioned reset, then the real cause of the problem would be detected, it would probably be a bug in the DHCP Windows service which is there since so many years. That would also explain why the problem has more chances to occur when default gateways are repeatedly DHCP-pushed. Kind regards
-
Hello! You don't have to reinstall, although re-installing and rebooting will for sure reset the TAP-Win32 Adapter, of course. When you have the problem, try the following steps (each successive step to be performed only if the previous did not solve the problem) - "ipconfig /renew" (from a command prompt with administrator privileges) - turn off and then turn on your physical interface - disable and re-enable the TAP-Win32 Adapter (this will cause it a reset), reset the TCP/IP stack and reboot, see http://support.microsoft.com/kb/299357 As far as we have seen, the last step always works, saving you the need, time and annoyance to uninstall and reinstall OpenVPN. It's an extremely rare condition, so it's not in the FAQ, sorry. It's also not easy to reproduce the issue, however a condition to enhance occurrence probabilities of such a behavior is repeatedly changing the default gateway. Kind regards
-
Hello! There's no such thing as an Air installation (the Air client is portable). If you noticed that after OpenVPN installation on the TAP-Win32 Adapter, it's probably just fine. 169.254.0.0/16 are the link local addresses in IPv4, they are only used to assign IP addresses to network interfaces when no external, stateful mechanism of address configuration (such as DHCP) exists (typically before the DHCP push from our OpenVPN server). The parameters with which Windows tries to determine if an Internet connection works or not are not reliable and can easily result in false messages. A typical example is when you block DNS queries outside the tunnel to prevent DNS leaks. When unable to resolve names, Windows will show you that you're disconnected from the Internet, while it is obviously false. Kind regards
-
@azarenko Hello! Apparently the screenshots you posted seem to confirm, not to deny, that pf is successfully dropping Skype packets. Kind regards
-
Hello! The tun interface did not come up. It might be a bug or a crash in the TAP-Win32 Adapter driver (unlikely) or a TCP/IP stack Windows handling problem. We have noticed that all Windows versions (tested on XP, Vista and 7) have issues when they are "stressed" with repeated changes of default gateway and routing table. Sometimes these problems require an "ipconfig /renew" to be solved, but (rarely) it's not sufficient, they require also a Windows socket (WinSock catalog) reset followed by a reboot (unfortunately a Winsock catalog reset seems to require a reboot to be completed...) or a reset of the physical network card. Kind regards
-
Hello! We have not had any failure or interruption of service on Cygni. The server performs very well and the latency times in a 10 countries continuous check are very good. https://airvpn.org/pingmatrix Swedish infrastructure is largely oversized at the moment, in relation to clients numbers and bandwidth requests. Any other feedback on Cygni from different premium users? Kind regards
-
@berniesnoek Hello! The problem is that the router tries to connect to a non-existing public IP address (10.x.x.x.). Please insert, in the "Server/IP" field of the OpenVPN configuration page of your router http interface, the entry-IP address of the Air server you wish your DD-WRT router connects to. An e-mail has been sent to you with further information. Kind regards
-
Hello! Yes, of course. If you connect to the same service with the same account with and without VPN, even without session cookies the service administrators can successfully perform a correlation. Another way to perform such correlation attacks against those who connect to the same service while connected and not connected to the VPN is via Flash cookies, which are not deletable by the browser. BetterPrivacy for Firefox takes care of Flash cookies ("supercookies") and allows their full deletion. Kind regards
-
Hello! Unfortunately it's unclear why you're trying to connect to a private IP inside the VPN (10.5.0.1). Can you please send us a screenshot of your OpenVPN configuration page in your DD-WRT router and the connection logs? Kind regards
-
Hello! Do you access the service status page while logged in? Do you allow javascript? You might like to look at the page source code for more hints. Kind regards
-
Hello! A guide to prevent any leak (including DNS leaks and leaks in case of unexpected VPN disconnection) for Windows with Comodo firewall: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 If you just want to prevent DNS leaks, you can either follow the guide in http://dnsleaktest.com or force the following DNS in your physical network card (ethernet and/or wireless): 10.4.0.1 as primary (preferred) DNS 10.5.0.1 as secondary (alternate) DNS In the above case please consider that your system will not be able to resolve names when disconnected from the VPN, therefore you'll need to edit your hosts file to add the resolution for airvpn.org in order to allow connection in case you use the Air client (future release of the Air client will adopt a different approach which will solve this issue and will be much more aggressive against censorship). See the above guide for more details about the hosts file. Kind regards
-
If you're behind a VPN, even if your DNS is leaking, your IP cannot be determined directly. If a site manages to find out your real IP, that's because it was likely done via cookies. Other mechanisms exist as well, via Javascript, Java and Flash. There may be other ways, as well. If you clear out your cache and cookies, then install a bunch of gatekeeper add-ons via Firefox, you should be alright. Maybe I'll write another guide on how to do this... Hello! Javascript by itself does not allow to read your network cards. If you accept to run .NET, Java and Flash code with administrator/root privileges, they can read your network cards. However, this operation by itself in general is not sufficient to disclose your real IP address with OpenVPN in routing mode, because none of your network cards know the real IP address assigned to you by your ISP: the tun adapter has the internal VPN address, while the IP address of the physical network adapters is the one assigned to the computer by the router (if the system is behind a router NAT, a very common situation). You can imagine malware which tries to read the router configuration, but then again you must provide the malware with root privileges AND give it the password to access the router configuration, unless the router is totally unprotected, or unless the router publishes on the home page of its web interface the assigned ISP IP address, in which case the malware can detect the router IP address by reading your network cards and then access the router http interface and parse it to extract the real IP address. If your router publishes on its home page the IP address assigned by your ISP, a trivial but effective protection against such malware is dropping packets toward your router IP address port 80. For example, in Comodo, defining a top global rule (before the Allow rules in our guide) like the following: Block TCP Out From IP In [Home Network] To IP Where Source Port Is Any And Destination Port Is 80 (remember to delete this rule when you need to access your router configuration page via http). Important: if any of your network cards contains the IP address assigned to you by your ISP (for example if your computer is directly connected to the ISP network without any NAT router) then letting root privileges to any unknown application is an unacceptable risk. But also in general no application that you don't know very well should be authorized to run with elevated privileges and it is mandatory, as a general rule, not to leave the configuration router settings accessible without a password. Kind regards
-
Hello! The alleged "NL menace" is currently a fantasy, the cited legal framework is a mix od draft proposals which can't in any way infringe the EU legal framework on privacy and data protection, the ECHR and the Charter of Fundamental Rights of the European Union. That said, if you assume that your adversary has the power to wiretap in real time (even illegally) all the VPN servers, capture the traffic, correlate the incoming and outgoing traffic, you can defeat such an adversary with partition of trust. You might like to read the following article: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=54&limit=6&limitstart=6&Itemid=142#1745 Kind regards
-
Hello! The problem is caused by your proxy, either it is not running, refusing connections or not listening to port 9050. Please make sure that your proxy is properly configured and that the proxy type (http or socks) matches the proxy type you have chosen in the client settings. If you don't have a proxy (i.e. you don't want to connect over OpenVPN over a proxy), please set back to default (Proxy-->Type: "None") the Proxy combo box in the Air client "Preferences" window (right-click on the dock icon and select "Preferences"). Kind regards
-
Hello! Can you please send us the connection logs? Kind regards
-
Wrong open port indication on the forwarded ports page
Staff replied to Someone Else's topic in General & Suggestions
Hello! Probably it's just a false positive from the UDP system check. We'll look into the issue. Kind regards -
Hello! As far as this admin knows no, it is not possible on Windows with our setup and our server pushes. You can anyway achieve the same purpose by running a VM and performing an OpenVPN connection on the host and a different OpenVPN connection on the guest OS. Connect the guest OS to the host via NAT, not bridged mode. In this way in the guest OS you will have connections over OpenVPN over OpenVPN. Kind regards
-
Keeps disconnecting after establishing connection
Staff replied to emilysplace's topic in Eddie - AirVPN Client
Hello! Don't worry, it's a problem easily fixable. It is caused by the fact that Tunneblick 3.2.8 is not compatible with Mac OS X 10.8.x. Please upgrade to Tunnelblick 3.3beta21b: http://code.google.com/p/tunnelblick/wiki/DownloadsEntry?tm=2 Kind regards -
Hello! Excellent! Everything you did is correct and the tests you have performed confirm that you are protected against any leak. The uTorrent application rules are superfluous but you can keep them, they do no harm (but see below). As a side note, you might like to disable logging for the "Allow" rule in the uTorrent application rules in order not to overload Comodo logging which in some cases might slow down your system slightly. Kind regards
-
Hello! This is a copy & paste of an e-mail from the support team you should have received a few minutes ago, this admins pastes it here for general knowledge: On 02/06/2013 04:55 AM, fawkesguy wrote: > I have port forwarding enabled, and it's working for my web server and webcam, but I can't get it setup for Xbox Live. Xbox Live needs port 3074 UDP & TCP opened. I have my AirVPN forwarded port set to UDP & TCP, local port 3074. I've also tried it without setting the local port. Doesn't work either way. I'm also using DNAT. Below is what's in my firewall. The Xbox is 192.168.1.50 I've deleted the entries for the web server and webcam. > > iptables -I FORWARD -i br0 -o tun1 -j ACCEPT > iptables -I FORWARD -i tun1 -o br0 -j ACCEPT > iptables -I FORWARD -i br0 -o eth0 -j DROP > iptables -I INPUT -i tun1 -j REJECT > iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE Hello! The rule iptables -I FORWARD -i br0 -o eth0 -j DROP might be right or wrong (it depends on your setup) try to delete it for testing purposes (only after you have corrected another rule, see below). > > iptables -t nat -I PREROUTING -i tun1 -p tcp --dport 2127 -j DNAT --to-destination 192.168.1.50 > iptables -t nat -I PREROUTING -i tun1 -p tcp --dport 2127 -j DNAT --to-destination 192.168.1.50 Why the above rules are duplicated? Maybe the Xbox needs UDP packets as well, try to change the second one to: iptables -t nat -I PREROUTING -i tun1 -p udp --dport 2127 -j DNAT --to-destination 192.168.1.50 (note "-p udp" instead of "-p tcp" on the second rule) Kind regards AirVPN Support Team
-
Hello! Please note that 4 Mbit/s is the minimum guaranteed allocated bandwidth per each user, please see here for more details: https://airvpn.org/faq#speed In order to pick the server which can provide you with the best performance please: - connect to various server which are NOT at 100% capacity on different ports (in particular try 443 UDP, 53 UDP and 80 TCP) - perform the internal speed test on different times for each connection to every server, every port and every protocol, so that results are not biased by further, external servers and time fluctuations: http://speedtest.air Kind regards
-
Hello! The Air client is portable, it is not installed in the system. OpenVPN installation does not change anything pertaining to port forwarding. If you could be more specific, we should be able to provide you with additional support. Kind regards