- I recommend using a Debian VM w/ OpenVPN for your private traffic. That way, 'am I using my VM?' is a quick test for whether your traffic is private or public.
- I can't stress this enough: _be sure to firewall your VM from any traffic not to your VPN provider_. If OpenVPN drops its connection, it will fallback to sending packets normally! At least if you firewall, your connection will just die, instead of potentially sending private traffic in the clear. The article doesn't mention this, and it should.
- Be sure not to log in to your usual services on your VPN, or there is a possibility that someone can connect your real traffic and your VPN traffic. I use LastPass with random passwords to manage all of my accounts, so I solve this problem by simply not installing LastPass on my VM, which makes logging in a very deliberate action on my VM.
I agree with the "don't roll your own" VPN suggestion--I personally signed up with Private Internet Access and haven't looked back since.
But I have a question about this: "be sure to firewall your VM from any traffic not to your VPN provider."
Is there a good generic way to do this on Windows? I've looked around and it's never very clear. I think the PIA client has a "VPN kill switch" that should effectively do the same thing, but not all VPN providers have a client.
Watch out for IPv6 on Windows. I have a PPTP VPN through StrongVPN and the IPv6 interface is unaffected. Unfortunately there doesn't seem to be a way to programmatically disable it.
I was going to post this link for disabling ipv6 http://support.microsoft.com/kb/929852/en-us
then I read the word "programmatically"..
then I was going to suggest using "netsh" but it seems you can't use it to disable IPv6, finally I found that you can modify the registry as illustrated here:
http://technet.microsoft.com/en-us/library/bb878057.aspx
(i.e. with a script launching reg.exe) but then I read that it should require reboot (damn Microsoft..)
"2. Our company currently operates out of the United States with gigabit gateways in the US, Canada, Germany, France, UK, Switzerland, Sweden, the Netherlands and Romania. We chose the US, since it is one of the few countries without a mandatory data retention law. We will not share any information with third parties without a valid court order. With that said, it is impossible to match a user to any activity on our system since we utilize shared IPs and maintain absolutely no logs."
I view it as defense against hotel or coffee shop wifi hackers.
If you have a threat matrix that includes governments or maybe even large corporations, it's definitely not for you. But c'mon, for $4 a month or whatever, what do you expect?
I have used PIA for 6 months or so, the business being US based has worried me. Speeds have been good so far and the pricing is great. I have a question for Linux users with more experience than I. Has anyone wrote a script that could tell if the openvpn connection has been cut, then just kill eth0 automatically?
With respect to the last item, I just want to make a distinction between security and anonymity. I don't care if my bank knows I sometimes a VPN; I just want protection from bad actors who might MITM me.
I agree on principle, but there are some activities for which Tor isn't an option (for example, sending large files). An offshore VPN that doesn't store logs (or even tunneling through several VPN providers/countries) can provide good enough anonymity for the task at hand.
Be careful: many torrent clients (and no doubt that is what ye speak of here) happily report your real IP to every IP you send or request to and from, regardless of VPN use.
servers=( ip1 ip2 ip3 ... )
# Can fwd over internal network
iptables -A OUTPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT
# Can fwd over loopback
iptables -A OUTPUT -o lo -j ACCEPT
# Can fwd over the tunnel
iptables -A OUTPUT -o tun0 -j ACCEPT
# Can send packets to VPN
for server in "${servers[@]}"; do
echo "Installing rules for $server"
iptables -A OUTPUT -d $server -j ACCEPT
done
# Otherwise drop
iptables -A OUTPUT -j DROP
Use it with a package like iptables-persistent so you don't have to run this every time at boot.
You can do this without IPtables, just make wlan0/eth0 the host route for $server and then make the default gateway the tunnel interface. Decent OpenVPN clients do this by default.
I'd kill for a solid in depth write up if someone is willing to put one together. I don't know anything about this kind of stuff but it's piqued my interest lately.
A lot of people have asked me for pointers to write-ups, but there don't appear to be any comprehensive ones on the Internet. When I setup all of this, I had to learn from piecing together information from various tutorials and reading manuals and what not.
I have been meaning for a while now to make a mini distribution of Linux that works well for VPN usage out of the box. If people are interested in this sort of thing, maybe I could try to make time for it.
I guess I don't understand what you are doing. Then VPN is to create a secure link either between your computer and a trusted LAN or from your computer to a better, less-likely-to-be-sniffed exit point than open wifi. It's not to hide who you are from the destination server or from anyone observing the overall WAN traffic (as the NSA can do). People with resources can find out who you are with VPN. Saying one should use VPN for anonymity is a bit like saying that its fine to use 1234 as your password because you've never had a problem before and it keeps people out of your account just fine. The reality is that it seems secure right up until the moment that it isn't.
Anonymity is what something like Tor is made for, and depending on your level of paranoia even that may not be enough on its own.
>If OpenVPN drops its connection, it will fallback to sending packets normally! //
This seems to be a bug in network setups - surely it's highly desirable to be able to control which route traffic takes and whether fallback to a different connection occurs or not.
On Debian 6, the default behavior is to do this. I remember searching high and low at the time to change the behavior, and couldn't figure out how.
If you Google around, a lot of other people seem to have trouble with this as well--there are a lot of tutorials for how to setup iptables to block OpenVPN fallback on dd-wrt and Tomato, for example.
The problem is mostly that Openvpn is responsible for setting up the routes that forward all traffic through the tunnel when it starts, and to remove them when it's done. Openvpn only secures your traffic when it's running. When it somehow quits, you're on your own.
My experience is that when it merely loses the connection, Openvpn will try to reconnect, and in the meantime you have no internet. It won't fallback. But sometimes, when the problem is more serious, the openvpn daemon can quit and then it becomes dangerous.
Of course, running Tails inside a VM is likely slightly safer than running TBB (Tor Browser Bundle) on your normal OS, depending on your threat model. For example, a Firefox exploit that breaks out of its sandbox could access your personal files when you use TBB, but only files within the VM when you use virtualized Tails (without an extra VM or network (fileshare) exploit).
If you're going to use a VM for your Tor browsing, consider Whonix [1] instead, which was developed specifically for that usecase. (Note that this is not developed by the Tor project people!)
But indeed, to get the full benefits from Tails, always use the live boot option whenever you can.
Just to clarify, you don't mean run a VM locally, do you? If your traffic is rolling over the same insecure WiFi, I would imagine your traffic could still be connected and possibly sniffed?
I think the idea is that you can firewall the VM so none of the traffic will leak if the VPN connection is dropped. I'm sure there are easier ways to do this, though.
Cloak is a super simple VPN where both the back-end service and front-end apps are tightly integrated. (We think of it as the "Dropbox of VPNs" in the sense that, like Dropbox, it's so easy to use.)
Basically, it's the VPN service+applications I wanted for myself when I started looking around and couldn't find anything (1) easy enough and (2) non-sketchy. Right now Cloak supports OS X (10.7+) and iOS (6+). We've been around for a while and I know there are a number of happy customers here on HN.
In any case, please let me know if you have any questions, and please do give it a spin. Cheers!
(EDIT for clarity, and because X of Y descriptions are not always loved.)
I see that Cloak uses racoon under the hood for iOS in what I assume to be a roadwarrior config.
Do you mind sharing an appropriately scrubbed config so that I can compare to see what I'm doing wrong in my setup? There seems to be a dearth of viable configs out there and this would be immensely helpful. Thanks in advance.
While Dropbox is simple to use, it's hardly the first thing that comes to mind when you make a comparison to Dropbox. I'd change that phrase because it's very confusing.
Good writeup, but why does this piece recommend running the VPN over TCP? Tunneling TCP over TCP, which will be the end result, is known to provide terrible performance in the presence of even minor packet loss.
Cool. I was looking around a few weeks ago for a good howto on setting up an OpenVPN server, but didn't find anything straightforward enough for the time constraints I was under. Thanks for writing this up, it'll come in handy for me.
I've seen many networks blocking udp entirely. An openvpn on a HTTP tcp port (article says 80, I would say 443 is better) is much less likely to be blocked (openvpn also knows how to go through an HTTP proxy).
I too use (open)vpn for 99% of my traffic because terrorism etc.
I can't recommend it enough, the damn thing is super stable and secure, works via NAT via NAT via NAT etc and super flexible (push routes, push dns, proxy and other settings), works in routed mode, bridged mode and so on.
I recommend you get a server or a VPS somewhere "nearby" and install openvpn software on that.
I can't trust VPN providers that they do not monitor or log my traffic and neither should you.
No root/admin privileges required on your "VPN server" - just the ability to ssh. It solves the tcp-over-tcp issue. It just works.
It only does TCP (with a specific hack for DNS, but no general UDP or IP). But it works exceptionally well, and just needs an sshable account on the server.
While possible, using ssh on iOS as a tunnel is a giant pain and it times out after 10mins. PPTP is not an option and there is preciously little info out there about properly setting up roadwarrior IPSec in a relatively easy manner.
Does anyone know why this is better than a simple SOCKS proxy, which can be set up with one SSH command to your VPS and a quick visit to your system settings?
For this audience, one would assume this isn't anything new.
The next level of 'detail'/risk to consider here is the fact that so many apps, and even browsers, will bind to the "on connection" event of connecting to a wifi hotspot - before you can initiate your VPN your twitter client* has already sent your authenticated token over the wire, etc.
I've tried to hack something together with iptables but that doesn't work either in airports/etc where there are splash screens to negotiate, etc.
( = yes, you could use a better client, but then the reason we need VPNs in the first place is that so many apps and sites don't use https)
A lame workaround would be to close all apps prior to putting your laptop to sleep, then engaging the vpn and only afterwards restarting the apps.
Shouldn't be too big of a deal now that tabs/sessions are mostly saved in chrome/firefox no? And well not like losing your twitter credentials is a big deal anyway. (i'm not a huge twitter fan btw :D)
Evidon provides reports to different types of companies that give them information about what trackers appear where, how prevalent they are and/or whether they're in compliance with privacy laws. High-level reports, not "your data."
pokoleo forgot to mention that 1. GhostRank, the feedback feature of Ghostery, is very explicitly opt-in: no data is collected unless you enable it, and 2. We anonymize all of the data that's collected. We have no interest in tracking individual GhostRank users. What's interesting to us is being able to say "This tracker appears on the most websites, or causes the biggest slow-down of a page load on average."
The wikipedia article[1] of Ghostery gives a quick & fast overview of what they do. MIT Technology review posted[2]:
> Evidon sells two main services based on the data it collects. One allows website operators to see which tracking code, from which companies, is active on their site and how it affects the speed with which its pages load. The other provides ad companies with figures on how common the tracking code from different companies is around the Web.
Sadly, that article is full of shit. And I'll edit our entry later to remove the Criticism, which is only partly correct.
GhostRank is explicitly for collecting tracker information, and in no way does it allow an advertiser (tho most of the customers are publishers) to somehow improve their targeting.
If you're planning to run a VPN server on Amazon EC2, be forewarned that lots of sites are going to block you. For example, Yelp, Craigslist, the StackOverflow family, Hulu, and Bank of America.
Because often, EC2 is used by spammers, botnets, and the like. Turns out when you make starting a box really simple, evildoers will use your service as well. Craigslist & Co. dislike EC2 in general, for that reason.
In the case of things like Hulu, it's an attempt to enforce their geographic boundaries (so that Europeans don't buy cheap EC2 instances to watch America-only licensed content).
I assume most of the others are trying to block scrapers that copy all their content and republish it.
The easiest defense against a pineapple is to create a wifi network titled "Pineapple Connected ALERT ALERT" or something similar to that. No security, no keys, and set it to your highest priority of networks to connect to if you have automatic joining enabled.
As someone who has used these lovely devices to prank others it's a good idea to do so.
Your computer asks "Hey is ____ SSID available?" and pineapple says "Yep! That's me!" Now your computer connects to the pineapple.
Well if you set the "Pineapple detected" SSID in your computer as the top priority, you'll connect to that when the pineapple is around. You're just putting in a dummy network on your computer to warn you that you've just joined the network f*&%ville, and you're not the mayor.
So anyone running a pineapple should alter the code not to respond to any SSID client probe containing the string "pineapple" and just wait for the next probe, and latch on to that as that will result in the MITM'ing of a high-value target.
No problem, it's a hell of a lot easier (and safer) than trying to run a VPN through one of these things. I'm not saying a VPN is pointless, but think of how many services on your computer connect before you can hit that VPN button.
This is true, but I would actually recommend both, still. Once you know you're on insecure WiFi, it's still better to protect some, even if you can't protect all - sometimes you have no choice.
Easy solution and system-wide, if your OS supports it and you can ssh to a trusted server. My personal plan-B tool when a simple ssh -D and firefox's socks-proxy isn't enough.
(BTW, why doesn't Chrome have socks-proxy like Firefox yet?)
If you have a decent internet connection at home with reliable uptime, you can also just set up a VPN at home and connect that way. My router comes with OpenVPN on it, so I don't even need to have extra hardware running.
I like Tinc VPN (http://www.tinc-vpn.org/). It's multiplatform and open source, just as OpenVPN is, but I prefer it for its simplicity and its mesh feature. It doesn't try to do too much (which means you'll have to set up routes yourself).
Of course, you have a problem when the owner of the wifi explicitly prevents anonymisation services.
For example, when I was at Birmingham airport, I couldn't connect to my VPN because they blocked domains of well-known VPN providers and even hijacked all my DNS requests so I couldn't circumvent so easily it.
I guess running your own local DNS server which has your typical requests cached would solve this problem though.
The article doesn't mention IPv6 where things can be a bit more tricky. The Android clients don't let you use TAP (layer 2 tunneling), so if you're going to be accessing your VPN from an Android device you'll have to configure IPv6 NAT, or hack around with scripts to add IPv6 addresses dynamically.
You know what would be great - The ability to do this automatically, especially on Android.
I would love to see the ability to specify 'safe' or 'trusted' WiFi networks and if you connect to a network other than these, the VPN gets initialized and used.
Setup on the phone is once and usage of the VPN happens automatically after that.
BTW, for what it's worth, the (very inexpensive) Synology NAS models out there will all act as an openvpn server. It requires a hit of tweaking to get it to work they way you'd expect, but it's nothing beyond what the typical reader here can do.
Going from your cable/DSL ISP to your house and then back to the ISP adds quite a bit of lag as well, compared to a server sitting in a DC somewhere.
I've made a beefy VM or even used a spare server at the office on a 100/10mb pipe and a $5 VPS is much more responsive. Especially noticeable with things like an IRC shell.
I'm VPNed into a Raspberry Pi back at my house right now. Works fine. I just followed a tutorial or two but if I remember correctly, it wasn't much more than "apt-get install openvpn" and a few configuration steps. It's actually running on my XBMC Pi that's already always on and connected to a TV.
Once your vpn is established do you post to HN, inject SQL, download torrents, or is there something else exciting to do? I'm not in a fraternity (or sorority) so that's out.
But their OpenVPN support is awful and limited, unless you enable developer mode and set it up manually. Prevents Chromebooks from using VPN in our office.
Definitely true that cheaper is definitely possible, but a DigitalOcean droplet or an EC2 micro can be pretty cheap and you don't have to worry about the other VPN clients as much.
It is hell though - recently setup this on a droplet, but getting all the settings right and diagnosed on Ubuntu and some Ubuntu and Android clients was complicated. It never seems to work the first time...
L2TP/IPsec is hell. OpenVPN is not more difficult to set up than a web server. Of course, you need L2TP if you want to use the built-in clients on Android, IPhone, Windows...
Yeah, mobile support was a bit tricky to set up for us as well, but we managed it with just OpenVPN. The OpenVPN app for iPhone at least was able to be configured without too much headache, although it only supports a subset of the OpenVPN options. It should be compatible with the config in the article.
For Android, there's an OpenVPN app too - it uses the very handy and neat Android VPN API and besides needing certificates in the right format (not the text versions), it works well.
If you don't trust a public wifi hotspot with your cleartext traffic because of passive snooping, why would you trust a VPN provider with your cleartext traffic?
A lot of these torrent-anonymously consumer VPN services look pretty dodgy.
Use a non-dodgy VPN service, such as https://www.privatetunnel.com/ (run by the OpenVPN people) or https://privacy.cryptoseal.com/ (run by HN's rdl). You may be trusting them with your cleartext traffic, but that's really no different than trusting e.g. Comcast with your cleartext traffic when you're at home.
- I don't recommend rolling your own on EC2: pick a VPN with a good reputation and a policy of not retaining logs. See: http://torrentfreak.com/vpn-services-that-take-your-anonymit... (you don't have to use torrents to need a VPN, btw!!)
- I recommend using a Debian VM w/ OpenVPN for your private traffic. That way, 'am I using my VM?' is a quick test for whether your traffic is private or public.
- I can't stress this enough: _be sure to firewall your VM from any traffic not to your VPN provider_. If OpenVPN drops its connection, it will fallback to sending packets normally! At least if you firewall, your connection will just die, instead of potentially sending private traffic in the clear. The article doesn't mention this, and it should.
- Be sure not to log in to your usual services on your VPN, or there is a possibility that someone can connect your real traffic and your VPN traffic. I use LastPass with random passwords to manage all of my accounts, so I solve this problem by simply not installing LastPass on my VM, which makes logging in a very deliberate action on my VM.