InactiveUser

​Yes, there is. It has to be configured per network connection, not per network interface. Launch nm-connection-editor (GUI name: "Network Connections" - it's part of NetworkManager, if you can't find it, start it from the commandline). Choose your WiFi or LAN connection, click "Edit", select the "General" tab. There, you can enable "Automatically connect to VPN when using this connection". It will let you choose from NetworkManager's list of VPN connections. Screenshot attached:

lsat, you make a great point there! To be pedantic: I wouldn't consider Chromium to be true FOSS. It's a FOSS wrapper to download proprietary Google blobs (Firefox is not much better in this regard.) EDIT: removed link to Chromium story - I missed that lsat already included it.

I must say, I was not aware that AirVPN actively integrates Tapatalk, I am not in favor of that! Third parties should not have any access to AirVPN resources. Tapatalk's license agreement is very up-front about siphoning off email databases: Tapatalk Forum Owner License Agreement

No, I haven't. I only use applications from F-Droid - besides the FOSS requirement, applications are also vetted for tracking libraries, which either get removed or generate a warning ("This application tracks and reports your activity"). Thanks for bringing up this topic. The behavior of apps like UC Browser really is despicable. Grabbing unnecessary information (a map application does not need IMEI/IMSI to function), not telling the user about it, and then even failing to secure the transmission. Somewhat related story: Samsung epicly fails to securely fetch software updates, putting 600 million phones at risk of total exploitation. People, use Free & Open Source software. If you aren't permitted to read an app's source code, the app will read you.

guppy, I've run into this myself - the config generator has changed recently. Unless I missed something, you can't get a single .ovpn file anymore that contains multiple server addresses. The only way to do this now: manually pick a selection of serverslet the config generator spit out individual config files for all the servers you pickeddownload the files and extract the relevant "remote $ip $port" lines from all the ovpn files - for example by using: grep -h 'remote ' *.ovpncreate a new ovpn file (or simply modify one of the downloaded ones), put in all the "remote 1.2.3.4 443" lines you just extractedadd the directive remote-random to your ovpn file (else, openvpn would try to connect to the servers in order, not randomly)There is one major caveat: A single ovpn file must not contain more than 64 remote addresses, so don't pick more than 64 servers. Air already has 82 servers in total and currently 50 in Europe alone, so it makes sense for Air to ensure that the Config Generator would not generate invalid ovpn files. On the other hand, the Config Generator could be smarter. Simplified pseudocode example: if picked_servers <= 64: generate_individual_files() generate_combined_file() else: generate_individual_files() display_warning("You picked more than 64 servers. Pick no more than 64 if you need a multi-server ovpn file") I will suggest this later today by opening a support ticket, unless we get a staff member to comment on this thread first.

It's not unusual for Facebook to require phone verification. However, it's not related to your browser's data or incognito mode. Instead, I assume they (correctly) detected your IP to be a VPN or proxy. Air has two CH servers. If you look them up in Maxmind's IP database: Kitalpha: GeoIP Country Edition: CH, Switzerland Virginis: GeoIP Country Edition: A1, Anonymous Proxy I'm not sure to what lengths Facebook goes to "classify" IP addresses, but it's easy to see how a geoiplookup result of "Anonymous Proxy" would trigger their verification process. If none of Air's servers let you join Facebook without going through phone verification (and if you don't find it acceptable to register "in the clear"), I suggest you buy an unregistered prepaid SIM. Do keep in mind that inserting a new SIM into your present phone will allow your phone service provider to link your two identities (see: IMEI) So, if you're worried about your government, you need a burner phone for your prepaid SIM. But if you only want to avoid handing over your real phone number to Facebook, a prepaid SIM alone will do the job.

Quoting staff from this post: "Since AirVPN birth we have never used VPS for our VPN servers. We have dedicated servers with redundant uplink ports and bandwidth (with the exception of Hong Kong, where we were forced to accept a sufficient compromise) and PoP with tier 1-2 transit providers."

This reeks of a PR move to drive home the message that, quote, "nobody should be in any doubt that Edward Snowden has caused immense damage". I think there are three possible scenarios for how this actually went down, but none of them really fits their story! Scenario 1: CHI/RUS cracked the actual encryption. Extremely unlikely for three reasons: 1. We know Snowden instructed journalists to use TrueCrypt and gpg, so there's no reason to believe he used anything inferior himself. He's no dummy, come on. 2. So, now that we can safely assume he used proper crypto, they would have to have, at the very least, cracked AES. Verrrry unplausible doomsday scenario. 3. How in the world would US/UK spooks even know about this? If they had high-up double agents in CHI/RUS, they would keep this quiet, right? You don't waste them for a little news story. On the same token, CHI/RUS wouldn't just let US/UK know about this, either. Scenario 2: CHI/RUS "convinced" Snowden to "cooperate". Compared to cracking AES, it's much more plausible they "cracked" Snowden. But in that case, US/UK would be flat-out lying (shocker, I know!) - so how believable does that make anything in this story? Scenario 3: Snowden's files are not related to US/UK pulling out spies. It's just too convenient to blame this on Snowden when you just had to suffer a devastating Chinese hack of federal personnel files EDIT: Also read Gallagher and Greenwald on this subject

Answering question 1: Most routers can act as a DNS server/forwarder. They will forward your DNS requests to a DNS server of your choice - or, by default - your ISP's DNS server. In most cases, people configure their network interfaces using the automatic DHCP process. With DHCP, your computer tells the router: "I want to be part of your LAN, please give me an IP address!" The router answers: "Fine, you can have 192.168.1.39, my address is 192.168.1.1! Oh, and I can also be your DNS server!" Your operating system will configure your network accordingly. That's why you usually see your router as your default DNS server. You can override that by going into your network interface's settings and manually setting a DNS server. Answering question 2: When you connect to the OpenVPN server, your OS will (usually) be told to use the server as its new default gateway. From this point on, any traffic to remote IPs will go to that gateway, including DNS requests to an OpenDNS server. In this case, no leak can happen. Of course, if your OS is configured to send DNS requests to a local address (your router), they will not be tunneled and your router then resolves the DNS requests using your real IP. That's how a DNS leak happens, and you correctly mentioned that tools like the AirVPN client will prevent that by overriding your system's DNS settings for the duration of the VPN connection. On the other hand, other tools like for example the Linux NetworkManager might only add the VPN's DNS server to your network configuration but not replace the default one.

Yes! The AirVPN XMPP server does allow its users to create chat rooms. This feature has not seen much usage yet but you can try it out by joining the room "lounge" or by creating your own room.

First of all, I think it's better to avoid the term "kill switch" as it describes a (bad) idea that's completely different from a firewall setup such as AirVPN's network lock feature. Now to address your question, please clarify what you are trying to do: a. use the AirVPN client and its network lock featureb. don't use the client (instead, connect through NetworkManager, or use openvpn directly) and configure iptables yourself, in a way that resembles AirVPN's network lock featureIn case of option a, you don't need to touch iptables yourself! The AirVPN ("Eddie") client will do that each time you run it. If you want to use Eddie, there's no need at all to read the rest of my answer. In case of option b, your iptables rules must contain the following: a general rule set (allow local traffic, allow tunnel forwarding, block traffic by default, ...) exceptions for all of the VPN servers you want to connect toThe rules you quoted from Air's website would serve just fine as your general rule set. Now you only need to manually create exceptions for the servers' entry IPs. There are two ways to get a hold of these entry IPs: DNS lookup, very convenient, as explained by AirVPN staff hereuse the Config Generator, tick all the servers you want to use, enable both "Advanced Mode" and "Resolved hosts in .ovpn file", then check the config file for the "remote " IPsHere's an example: Let's pretend you wanted to use the servers Nihal, Pavonis and Rastaban. You would issue the following commands to get the entry IPs dig +short nihal.airvpn.org dig +short pavonis.airvpn.org dig +short rastaban.airvpn.orgto get back the following IPs 46.182.35.14 149.255.33.154 62.102.148.135 You would then create iptables rules to allow outgoing connections to these IPs: iptables -A OUTPUT -d 46.182.35.14 -j ACCEPT iptables -A OUTPUT -d 149.255.33.154 -j ACCEPT iptables -A OUTPUT -d 62.102.148.135 -j ACCEPT That's basically it. If you decide to roll your own firewall configuration, be sure to test it properly! It's usually better to use Eddie's network lock. The biggest difference (and reason why some people prefer their own setup over Eddie): Eddie's network lock gets activated when you launch the program (and deactivated when you quit the program) whereas your own iptables configuration would be activated as part of your system's boot process.

If network lock is enabled, it will take effect as soon the AirVPN client comes up. I have posted some autostart instructions for Linux Mint but they are virtually identical for Ubuntu. They include a way to launch the application without having to enter your Linux user password each time.

Thanks, link fixed!

The virus claim on that page is pretty much nonsense. What's actually happening is that CloudFlare, a CDN used by a worrying number of sites, "uses threat data from a variety of sources to build a reputation for every visitor online". Using shared networks like a VPN or Tor will always lower your "reputation" in their eyes. CloudFlare is a severe hindrance for privacy-conscious users. There's not much you can do other than: letting CloudFlare know how unreliable their "threat data" is and how severe the side effects areletting websites know how much you struggle to access their content due to their use of CloudFlare

@difflehuffy: Difficult question. There are many, very different ways to go about unmasking hidden services - some of them mentioned in this Tor blog post. Most of these attacks are actually not too advanced (follow the money trail / exploit and take control of the website / personal infiltration). Something in that vein would not directly lead to the deanonymization of individual users. We do know that the FBI uses commandeered hidden services to spread unmasking malware. Thanks to the disgusting practice of parallel construction it is unclear to what extent an agency like the FBI would be able to make use of NSA's capabilities for network-level unmasking attacks.

It's true that .onion sites (Hidden Services) don't utilize exit nodes. Here's how it (roughly) works: The Hidden Service advertises its existence and its public key to a few relays (which act as "introduction points")The Hidden Service publishes that information to a hash table (which is stored by relays known as "HSDirs")The client contacts such a relay and requests that informationThe client randomly picks another relay to act as a "rendezvous point"The client sends a message (encrypted to the Hidden Service's public key) to one of the introduction points to tell the Hidden Service about the rendezvous pointBoth Hidden Service and client use their circuits to the rendezvous point to establish a connection to each otherA more detailed explanation can be found here. Now, to answer your question: No - while an impressive piece of technology, they are not completely safe (nothing will ever be completely safe). In 2014, an attacker used a combination of malicious HSDir and guard nodes to deanonymize users. One of the biggest advantages of Hidden Services - one that often gets overlooked - is their built-in end-to-end crypto. A website hosted as a Hidden Service does not have to use SSL on top, which is a huge deal as it totally eludes the compromise of certificate authorities and man-in-the-middle attacks. If you're interested in further improving Hidden Services, keep an eye on the upcoming crowdfunding campaign.

Have you tried SSH tunneling over port 22? Your work place might block outside SSH connections though. Has the SSL tunnel approach stopped working only at work or at home, too?

There are services that generate a personalized torrent link for you, you download the torrent, then the service tells you what IP it saw. You can use: AirVPN's own IPLeak "torrent address detection" or try CheckMyTorrentIP

Yeah that would work. Or just download the sig through Tor and the file through VPN. Of course, if the source (website) is compromised, it doesn't matter how you download. In that case, only checking the key will help.

The developers use their private key to create the signature. In order to verify a signature, gpg needs to have the corresponding public key. Take a closer look at gpg's output: gpg --verify file.tar.sig gpg: assuming signed data in `file.tar' gpg: Signature made $some_date using RSA key ID 1234ABCD gpg: Can't check signature: public key not found It tells you the ID of the key you need to import: gpg --recv-keys 1234ABCD gpg: key 1234ABCD: public key "John Doe" imported Now gpg will be able to verify the signature: gpg --verify file.tar.sig gpg: assuming signed data in `file.tar' gpg: Signature made $some_date using RSA key ID 1234ABCD gpg: GOOD signature from "John Doe" There is, as you may have guessed, a major problem here: How do you know this key actually belongs to the person you think it does? If your download of both file and signature had been man-in-the-middled, you might have imported a fake key and blindly accepted a spoofed "GOOD signature" result. That's a somewhat tricky problem to address. Ideally, you would have a "Web of Trust", meaning that people you already trust have signed this key. Practical example: here are two keys, both claiming to belong to "Erinn Clark <erinn@torproject.org>": Key #1: Key #2: Weird, right? Over the years, one key has been signed by many people from Debian, Tor, Guardian Project, while the other key has no sigs at all. Of course, all of Key #2's sigs could be fake too, but ideally you would find at least one among them that you already trust - that's the whole idea of the Web of Trust. But even without a proper WoT, you can easily spot the suspicious key in this particular case. If you want to spend even more time thinking about this problem, the Tails Project has elaborated on some interesting ideas on how to trust their signing keys. What to use for file/folder encryption on Linux: I use gpg / gpg-zip, it's not the most convenient solution but I don't need it a lot. Truecrypt or one of its hopefully trustworthy forks is probably still the most secure and convenient solution. EncFS is also worth a look (doesn't Ubuntu use it for /home/ encryption?) but its security audit wasn't exactly cheerful.

You can't do that. AirVPN provides you with an OpenVPN tunnel account but no shell/server access of any kind. You have many options to run a web service: dedicated server, VPS, shell account, webspace, cloud platform (OpenShift, AWS, Azure, ...) or simply a machine at home. You can, if you're so inclined, configure your own server to use AirVPN. Port forwarding is available.

AirVPN doesn't block trackers, trackers block AirVPN! More info in this old staff statement: https://airvpn.org/topic/9499-connecting-to-trackers-fails-from-different-servers/?do=findComment&comment=10370

Do feel free to use Tor on top of AirVPN for improved anonymity and tracking resistance. Don't run Tor exit nodes on AirVPN - doing so would put AirVPN servers on certain blacklists, causing problems for your fellow AirVPN users, such as constant captcha challenges on many websites or even blocked services. However, AirVPN won't stop you from running Tor exit nodes. Do feel free to use any kind of P2P network. Don't violate ToS. I don't think there's anything else you should be particularly wary of. If you encounter a site or service that seems to block you for using a particular AirVPN server, try other AirVPN servers until you find one that works. There are some anti-fraud detection systems that you may trigger by using VPNs (for example, think of banks or online shops trying to figure out if your login is legitimate). Such problems are relatively rare (most anti-fraud systems are smarter than that).

I'm not sure I understand your question. Do you mean: make apps believe you're in the US? No, that's not impossible at all, if you disable location access as we discussed and use US AirVPN servers. However, you might run into some content providers (especially video streaming services) that try and actively block known VPN IPs. Not much you can do in that case apart from trying each and every VPN server. On a tangentially related note, I think the XPrivacy framework offers the ability to provide apps with fake location data (or any other data it requests). That's another fun idea to play around with, perhaps.

If 5.1 is a show-stopper and you don't care about future updates, keep using cm-12-20150428-NIGHTLY. cm-12* is based on 5.0 whereas cm-12.1* is based on 5.1. Or try stock Android + DroidMate's AppOps. Use AFWall+ in combination with AirVPN to avoid disconnection leaks. Also, Android is known to leak data during boot (way before you enable your VPN). AFWall provides an experimental fix ("Fix Startup Data Leak").