InactiveUser

They are relevant, but in agreement with rainmakerraw, I would say they're poorly argued: 1. Whonix blog's target audience must surely already know that you can't equate VPN providers with anonymity networks. 2. I think it's indeed a safe assumption that many VPN users have a "false sense of security", but it's hypocritical to then talk about "anonymity guarantees of Tor". Tor Project can't, never has, and never will guarantee anything. The use of the word "guarantee" suggests a false sense of security - which, ironically, was supposed to be the author's main argument. Certainly, Tor has many valuable properties that VPNs can't offer, but not a single one of them is "guaranteed" - the author might want to remember what happened to Silk Road 2: Tor Project security advisory: Later that year, FBI/DHS affidavit: Coincidence? I think not! 3. Whether or not VPNs make sense for someone depends on their threat model. Tor is excellent but not the right tool for every job - or every person.

Option A: use the AirVPN Eddie client and its network lock Option B: compare your rules to Eddie's network lock documentation, section "Mode 'iptables' in depth" You're missing these three rules: iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i tun+ -j ACCEPT iptables -A FORWARD -j DROP you don't need these two at all: iptables -A INPUT -s 10.4.19.221/16 -j ACCEPT iptables -A OUTPUT -d 10.4.19.221/16 -j ACCEPT i would also replace these two of your rules: iptables -A INPUT -s 127.0.0.1 -j ACCEPT iptables -A OUTPUT -d 127.0.0.1 -j ACCEPT with: iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT to allow all DHCP, you might also to replace: iptables -A INPUT -s 10.4.255.255 -j ACCEPTiptables -A OUTPUT -d 10.4.255.255 -j ACCEPT with:iptables -A INPUT -s 255.255.255.255 -j ACCEPTiptables -A OUTPUT -d 255.255.255.255 -j ACCEPT

You need not worry - DRIPA will be back soon, because DANGER, DANGER, TERRORISM! Thousands of lives at risk after High Court rules snooping powers unlawful One particular phrase piqued my spidey senses: Oh, I see! You say you need all this access to solve crime and prevent terrorism, but you also use it for "non-crime enquiries"? I have no further questions, your honor

This thread is at risk of getting out of hand, so I'll keep my arguments as concise and neutral as possible: 1. Asking for an unbiased comparison in one of the competitor's forums is not ideal. This sort of topic is better discussed on a neutral platform. 2. No matter which VPN provider you choose; no matter which jurisdiction they're in, there are a few constants: they're all companies, compelled to make money and abide law you have to trust them: you're unable to get an inside look of their operation (which you would need for a proper evaluation)which means: some aspects of your evaluation will be based on opinion/experience/conjecture, but not fact3. Sure, three laws in particular: 18 U.S. Code § 3123 - Issuance of an order for a pen register or a trap and trace device: Also, 18 U.S. Code § 2703 - Required disclosure of customer communications or records. And, most worrying, 18 U.S. Code § 2709 - Counterintelligence access to telephone toll and transactional records (commonly known as "National Security Letter" / gag order): While these laws are designed to subpoena individual customer records, their application will likely and regularly affect the whole customer base. Remember Lavabit: "The service suspended its operations on August 8, 2013 after US government ordered it to turn over its Secure Sockets Layer (SSL) private keys" (affecting all Lavabit users). 4. They only publish warrants they're allowed to publish, see 18 U.S. Code § 2703. Companies are much more likely to behave like Hushmail (silently comply) than to behave like Lavabit (resist and be forced to close shop). There is no middle ground. 5. I am convinced that European Union data protection laws provide a better environment for VPN providers. 6. I am not convinced that it makes a huge difference to be located outside of the US. It would be a fallacy to assume "US = bad, Non-US = good": similar laws exist in all jurisdictionsgovernments tend to ignore legal restraints anyway

I suspect everything is working as it should be - port 443 would never be "open" on your machine anyway! It sounds like you're confusing local and remote ports as well as destination and source ports: stunnel connects to an AirVPN server's listening port 443 from an arbitrary, local source port.stunnel then listens on another local port (usually 1413)AirVPN-client/OpenVPN then connect to that local listening port in order to establish the OpenVPN session through the SSL tunnelThe local port 50800 you saw is either the local source port for the connection between OpenVPN and stunnel, or the local source port for the connection between stunnel and the AirVPN server.

1. Whatever you read about proxies does not apply to VPNs, they operate in a different way. VPNs operate on data link / network layer, making it possible to: use them as a network tunnel for your whole internet traffic (that's how you use AirVPN!)access remote network resources (think of a company's intranet remotely accessed by employees via a VPN)Proxies on the other hand (at least the kind of proxy these websites are talking about), work on the application layer: configure a browser to establish HTTP connections through an HTTP proxy2. There is no clear definition for the term "transparent proxy". Most common definition A proxy that's transparent to the user. The user has not configured a proxy but their connections transparently go through a proxy server at some point of the route. Such a proxy might be run internally by your ISP for caching purposes, for example to cache and speed up DNS requests. IPLeak.net's definition IPLeak.net is unable to determine whether your connection is going through a proxy - meaning if you're indeed using a proxy, it is "transparent" to IPLeak.net. xroxy's definition ... is not even worth talking about, it's a terribly incorrect website. What they mean by proxies "that provide anyone with your real IP address": Some HTTP proxies modify your HTTP headers to include your real IP in the "X-Forwarded-For" field. Again, you don't have to concern yourself with that, AirVPN's servers aren't HTTP proxies.

Adding to what staff said - 0.2.6.9 is not an old version of Tor, in fact, it's the current stable version (correction, 0.2.6.10 has been released just a few moments ago). Tor Browser and Tor have separate version numbers: Tor Browser is currently at version 4.5.x, Tor itself at 0.2.6.x. The alpha versions of Tor (currently 0.2.7.x) are not meant for everyday use - they are made for testing purposes.

HTTPS is not perfect, but far from being a joke. Remember NSA's QUANTUMINSERT? It modifies HTTP traffic. They can't inject into HTTPS connections. Or let "Hacking Team" explain to us how they intercept HTTPS and also Tor traffic: "Place an in-line Active Probe in the ISP’s network""Exploit the target transparently by injecting a browser-based exploit while he’s surfing the web (http)" <<< !!!!!"Insert a trusted root CA certificate(s) for MITM""Decrypt and Decode the traffic!"Under "Challenges", Hacking Team lists: "Pay attention to EFF SSL Observatory" <<< HTTPS Everywhere feature!"Tor manipulation is possible only through clear-text traffic" Hacking Team is a very capable attacker, so is the NSA. Both love HTTP and consider HTTPS to be, at the very least, a big obstacle. Certainly not a joke. Source for the Hacking Team statements I quoted: https://ht.transparencytoolkit.org/rcs-dev%5cshare/HOME/Naga/httpX/Presentation.pptx Caution! It's a direct link to a .pptx Powerpoint presentation.

Mass surveillance is global, you won't escape it by picking one country over anotherIf you feel particularly bad about your own country, feel free to pick servers in another country, but it's unlikely to make much of a differenceStay on the same continent if you don't want performance to sufferIt would be considerate to avoid US servers for activities that might trigger DMCA noticesYou should be able to override Startpage's "search language" on their Preferences page. I don't remember seeing any Dutch results on Dutch servers after changing SP's language to english.

That would be odd. Whonix FAQ: I still think you don't need to modify torrc, though. That is expected and explicitly mentioned in one of my links to the Whonix doc. While I am sure you could come up with a create solution for this problem, the Whonix maintainer doesn't think so. In any case, this is more related to Whonix than it is to (Air)VPN, so you might have a better chance directly asking the Whonix community for ideas.

I don't have time to dive deep into this topic right now but I might be able to offer some pointers: 1. torrc-defaults is not the file you want to modify. From Tor manual: "The contents of this file are overridden by those in the regular configuration file, and by those on the command line." Adding to that, I doubt that changing Tor Browser's torrc would do you any good because Whonix' actual tor process is running on the Gateway with its own torrc, probably in /etc/tor/ 2. I don't think you need to modify your torrc at all because your problem lies elsewhere: The AirVPN client expects a local Tor client and looks for a control cookie at the following paths: /var/run/tor/control.authcookie /var/lib/tor/control_auth_cookie I suspect your Whonix Workstation doesn't have auth cookies in any of these locations, so the AirVPN client's check will fail. I don't use Whonix but the way I understand it, cookie auth happens on the Gateway, not the Workstation (according to their documentation, Tor control messages are sent from the Workstation using what looks like password auth to a Control Port Filter Proxy running on the Gateway which in turn uses cookie-auth with Tor). 3. I'm sure you can make it work but probably not with the AirVPN client's Tor mode - you could try to simply run the client without hooking it up to Tor, that's what Whonix' transparent proxification is there for, right? Or, instead follow Whonix' own instructions on how to use VPNs in Whonix here and here.

There have already been multiple threads about this. Staff statements here and here.

There are two ways to use AirVPN's service - by using AirVPN's client software - codename "Eddie" - or by downloading config files for direct use with openvpn or other network applications such as NetworkManager (Linux) or Tunnelblick (Mac). In most cases, you're better off using Eddie, especially if you want to use AirVPN over Tor. Go to AirVPN's Enter page. Once you've selected your operating system, you will be able to download AirVPN's client software "Eddie". It's available for Linux, Mac and Windows. Install and run the appropriate version for your system, then find the menu items I highlighted in my screenshot.

rickjames, thanks, that's a valuable hint: libnetfilter-conntrack3 is installed in my Mint VM (the package is part of a default Ubuntu 14.04, according to .manifest), but not in one of my minimal Arch installs - thus, no conntrack enabled there. conntrackd, contrack-tools are not part of any default Mint/Ubuntu/Fedora install. To my understanding, you only need those for interfering with or monitoring tracked connections, but not for the actual conntracking. Edit: ufw uses state-tracking as a fallback. On my conntrack-less Arch: iptables-save | grep state -A ufw-before-input -m state --state RELATED,ESTABLISHED -j ACCEPT -A ufw-before-input -m state --state INVALID -j ufw-logging-deny -A ufw-before-input -m state --state INVALID -j DROP -A ufw-before-output -m state --state RELATED,ESTABLISHED -j ACCEPT -A ufw-logging-deny -m state --state INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN

All valid points, especially if OP already uses Eddie. One note about ufw/gufw and conntrack: even if you don't see it in the GUI(s), ufw does use conntrack by default: iptables-save | grep conntr -A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny -A ufw-before-input -m conntrack --ctstate INVALID -j DROP -A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A ufw-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN

It is possible, with a bit of iptables pattern-matching trickery. I have tried the following: ufw 0.34 (Mint 17) with an empty ruleset, all defaults set to "deny" (no connectivity whatsoever)a reachable DNS server in /etc/resolv.conf iptables -A OUTPUT -p udp --dport 53 -m string --hex-string "|03|vpn|06|airdns|03|org|00 00 01|" --algo bm -j ACCEPT Then I tried DNS resolution: dig +short google.com as expected, no DNS resolution dig +short airdns.org as expected, no DNS resolution dig +short gb.vpn.airdns.org 94.229.74.90 Voila! Pattern matched! I get an IP back! You can permanently add iptables rules to ufw by editing the file: /etc/ufw/before.rules Add the following line somewhere to the end of the file, but before the very last "COMMIT" line: -A OUTPUT -p udp --dport 53 -m string --hex-string "|03|vpn|06|airdns|03|org|00 00 01|" --algo bm -j ACCEPT Finally, reload ufw: ufw reload Edit: Replaced the pattern "|03|vpn|06|airdns|03|org|" with "|03|vpn|06|airdns|03|org|00|" to rule out unwanted subdomain matches Edit 2: Further improvement to the pattern, see gizurr's reply If you make any changes to your firewall setup, test them thoroughly before relying on your new configuration. You would probably want to make sure that openvpn, when connecting, replaces the original DNS server in /etc/resolv.conf and restores it when disconnecting. Credit goes to: Corey's answer on stackoverflow

I'm not on Windows so I can't really use or contribute to this, but, I like the idea! Three suggestions - I'm just brainstorming, either for you or anyone else wanting to add "polish": 1. Tell the user what sites you use to get the information - I know, it's in the source, but a README.txt would be nicer Another reliable site is wtfismyip.com, offering xml and json 2. If you plan on making and releasing any changes, think about putting it on some code platform like github 3. Another idea would be to use Air's API (either additionally or exclusively), to let the user check info on all of their current sessions

They don't count against the number of total AirVPN connections. Only the (one) VPN connection you establish within that container does! Within that tunnel, it's entirely up to your usenet provider how many concurrent connections you can establish. On a side note: 50 seems like overkill for most internet connections and most usenet providers, try and start with a lower value and work your way up until you don't notice any difference in speed. An unnecessarily high number of concurrent connections will likely impact your internet connection's latency.

Eddie version 2.9: Tor Browser's tor client: no changes necessary System daemon tor client: change port and control port to 9050 and 9051

I don't see how setting up your router fits into AirVPN's troubleshooting forum. Anyway, it sounds like you reset your router to its factory settings, correct? That includes login credentials. Look them up in your router's manual or on this website.

I consider The NoScript Misnomer to be a very important article. By "exploiting" an entry on NoScript's whitelist, the author shines light on several pitfalls that not every NoScript user might be fully aware of: NoScript comes with a default, enabled whitelist.whitelists are inherently flawed, even more so if you don't even maintain them yourselfif you use a security tool without fully understanding its operation and configuration, you lull yourself into a false sense of securityblocking all malicious scripts is unrealistic - you will need to think about defense in depth and sandboxingI personally use NoScript in combination with uBlock Origin in its advanced dynamic filtering mode. I also sandbox applications like Firefox, Thunderbird, Pidgin using Firejail, a small application that provides a convenient interface to built-in Linux kernel features (seccomp, namespaces, caps). Ideally, I would be using Qubes OS for better isolation, but it's not like hypervisors are somehow magically flawless, either.

I think I can: The Windows Firewall, as configured by the Network Lock, correctly blocked untunneled connection attempts to 54.172.47.69. Sounds like WebRTC - let's see what this IP is up to: Sure enough, it's one of Mozilla's STUN servers hosted on Amazon AWS. If ... a website makes use of your browser's WebRTC implementationyour firewall allows direct connections to one of the STUN servers and ...you haven't disabled WebRTC in your browseryour IP will leak as you experienced. Solutions: Don't touch Air's firewall setup.Regardless of the particular firewall you use, never allow any direct connections between your local network / local router and a remote host - other than to Air's servers, of course.Disable WebRTC in Firefox. Open about:config, find the following entry and set it to false:media.peerconnection.enabled

From https://airvpn.org/tor/ "Set Tor as connection mode in AirVPN -> Preferences" Also carefully consider the differences of "Tor over AirVPN" and "AirVPN over Tor" to find out what suits you best.

First of all, I'd file a complaint with whoever you're with - why would any service block a customer's IP on an authenticated mailserver? Makes little sense to me. Anyway, if you do want to bypass the VPN for this IP, you need to set a route for it. Routes are not handled by iptables. In NetworkManager, edit your VPN connection. In the IPv4 tab, you will find a "Routes" section. Add a route for: Address 68.178.213.37 Netmask 255.255.255.255 Gateway X.X.X.X Replace X.X.X.X with your home router's local address (192.168.0.1, for example) You only need to touch iptables if you're already using it to block non-VPN traffic. In that case, create a rule that allows outgoing traffic to 68.178.213.37 on your ethernet or wifi interface.

No, you shouldn't rename it to .conf, that's only necessary if you put the file in /etc/openvpn for use with openvpn in system daemon mode. By the sound of the error message I assume Britman tries to use the NetworkManager GUI. 1. Most likely, the package network-manager-openvpn-gnome is missing sudo apt-get install network-manager-openvpn-gnome 2. Not related to your error message, but still worth mentioning: I'm pretty sure NetworkManager is still unable to handle inline keys/certs. Air's Config Generator has the option "Separate keys/certs from .ovpn file" (in Advanced Mode).