Here's how it went. On a whim, even though I'd just given my Raspi a full software update just two days ago when I made that earlier post, I repeated the process again today:
sudo apt-get update
sudo apt-get upgrade
...and lo, there were some important packages that updated. Sniffing further, I attempted the first step of the installation process for installing a "real" PPTP VPN onto Debian Linux:
sudo modprobe ppp-compress-18 && echo success
No error was reported! The formerly-missing MPPE module has been added to the kernel.
Well now. This poses the tantalizing possibility of setting up a real, Point To Point Protocol (PPTP) Virtual Private Network using the Raspberry Pi as a gateway.
A VPN strategy for every situation
Among the highly non-trivial benefits of the PPTP VPN versus the ssh proxy tunnel I documented previously include compatibility with iPhones, iPads and other mobile devices which might not offer ssh port forwarding capabilities in their operating systems. That was the basic trick of the ssh proxy tunnel.On the other hand, PPTP VPNs utilize the GRE 47 protocol which is some routers find indigestible while others can accommodate only one GRE 47 connection at a time and will block all others-- a recipe for trouble in hotels and public hotspots. By comparison, the ssh proxy trick I documented--which leveraged the https or other common port for the ssh proxy tunnel--will be more likely to always work as you travel, at least for your laptops. Frankly, at this point I have both the ssh proxy tunnel and the PPTP VPN set up on my Raspberry Pi, and I might as well leave it that way so I'm covered for just about any circumstances.
Here's how
There are many tutorials available for setting up the PPTP server daemon (pptpd) on a generic Debian Linux machine. However, I've found that the Raspberry Pi presents a few quirks and needs its own instructions. The following steps worked for me and resulted in a robust VPN that has held up to my usage so far-- this blog post was constructed entirely while connected via my Raspberry Pi's new PPTP VPN.
- Open port 1723 on your router, pointing it to your Raspberry Pi's IP address on your LAN.
- Your Raspberry Pi should have a static IP address on your LAN. Good instructions for that are here.
- Next, if your home ISP does not give you a static IP address on the Internet, you'll need to set up an account with a dynamic DNS (DDNS) service. This will give you a URL which will always point to your router.
My D-Link DIR-655 router (a truly excellent router, by the way) earns me a free DDNS account on D-Link's service; there are plenty of alternatives. In D-Link's case, the url will look like [username].dlinkddns.com.UPDATE: My trusty DIR-655 died, and the units currently being sold now are totally different. I switched to an Apple Time Capsule, which necessitated a new dynamic DNS provider. I chose DynDNS.org... you get one free host name for trying their 14-day "pro" account (which you can cancel, keeping the host name, though their services are powerful and quite cost-effective for what you get). - Log into your Raspberry Pi either via its local console or via ssh.
- Issue sudo apt-get install pptpd
- Issue sudo nano /etc/pptpd.conf --this will start a simple text editor on your Raspi. Note that most lines are comments and are commented-out with a "#" at the beginning. Scroll down until you find the lines which set localip and remoteip.
- Set localip to your Raspberry Pi's IP address. For me, that line becomes localip 192.168.0.202.
- Set remoteip to encompass a small block of IP addresses on your LAN that will be made available to your remote client(s). For me, that line became localip 192.168.0.240-255 ...there are various rules for how that block can be constructed; use the format shown here or it might not work.
- Hit ctrl-X and save the file.
- Now issue nano /etc/resolv.conf and make a note of the nameserver identified in this file --for me, and I'd bet most other folks, it's the LAN address of my router, 192.168.0.1. Hit ctrl-X to close the editor.
- Issue sudo nano /etc/ppp/pptpd-options and scroll down until you find references that set ms-wins and ms-dns. You want to set thise to the nameserver address you just noted. For me, these lines became ms-wins 192.168.0.1 and ms-dns 192.168.0.1 respectively. Hit ctrl-X and save the file. This completes the basic IP setup for your new VPN.
- Issue sudo nano /etc/ppp/chap-secrets and scroll down to an empty line. Here is where you will specify your users who can use your VPN. For a user named Ralph with a password of SuperSecret123, the line would simply be Ralph pptpd SuperSecret123 * --the asterisk at the end is important as it specifies that Ralph can tunnel in from any IP address. Repeat with additional lines to specify other users you want to allow to tunnel in via your Raspberry Pi. Then hit ctrl-X and save the file.
- Issue sudo nano /proc/sys/net/ipv4/ip_forward ...see the zero? Change it to a 1. This tells your PPTP daemon to forward remote clients to the Internet. Hit ctrl-X to save the file and exit the editor.
- Issue sudo nano /etc/sysctl.conf and scroll down until you see the commented-out line that states net.ipv4.ip_forward=1 ...uncomment this line (remove the"#"). This will tell your Raspberry Pi to always allow remote clients to access the Internet via their tunneled connection.
- You're done! Reboot your Raspberry Pi.
- While you're waiting for it to sort itself out, you can set up a VPN connection on your traveling (client) machine. On the Mac, go to System Preferences | Network, click on the padlock and authenticate as an administrator user, Click the "+" sign and select "VPN" from the pull-down menu. Give this new VPN a name. Voila a new, unconfigured VPN connection will pop into your network-connections options. With this selected, type in your dynamic DNS address for your Raspberry Pi (e.g., YourUserName.DynDNS.org). In the Account Name field, put the username you specified in step 12 ("Ralph"). Click the Authentication Settings and specify the password from step 12 ("SuperSecret123"). Click the Advanced button, and be sure to checkmark the option to route all your Internet traffic through the VPN.
You're done! (Setting it up on an iPhone or iPad is even easier.)
You should be able to connect now, and all your Internet traffic will be encrypted and funneled through your Raspberry Pi from wherever you are... or at least from wherever VPN connections are tolerated. For other places, consider the ssh proxy tunnel I wrote about before.
Hi,
ReplyDeleteThe following steps worked for me and resulted in a robust VPN that has held up to my usage so far-- this blog post was constructed entirely while connected via my Raspberry Pi's new PPTP VPN.Thanks
iptables entry to rc.local?
ReplyDelete"iptables entry to rc.local?"
DeleteIIRC this was not necessary, though it's possible I missed a step in my notes. But http://blog.sumostyle.net/robg/2010/01/01/setting-up-pptpd-on-debian-lenny/ would seem to agree.
You may want to update your original post with this iptables step. I followed your directions exactly and only was able to successfully connect, but no Internet access. After modifying the iptables entry per these directions the PPTP VPN is now fully functional.
DeletePPTPD shouldn't be used, it relies on ms-chapv2 which was recently broke:
ReplyDeletehttps://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/
"PPTPD shouldn't be used, it relies on ms-chapv2 which was recently broke"...
DeleteThanks for the link. I reviewed the article and it seems that cracking ms-chapv2 still requires many hours of compute time using a purpose-built, massively parallel FPGA cracking engine. So yes, ms-chapv2 is crackable, but I'd wager that if you attract the curiosity of someone possessing such a tool, watching Netflix from your Munich hotel room is probably the least of your concerns.
Meanwhile, it seems a good, long password aids security by reducing the likelihood that a dictionary attack can work and by extending the computations required.
Bottom line: It's safest to assume that ANY encryption technique is vulnerable to three-letter agencies and a select handful of enterprises. If you're truly concerned about the security of your communications from within a hostile border, consider Liberte Linux http://dee.su/liberte
"I reviewed the article and it seems that cracking ms-chapv2 still requires many hours of compute time using a purpose-built, massively parallel FPGA cracking engine."
DeleteYes, it does require a lot of computing power. That's why they built it into cloudcracker, which will crack ANY ms-chapv2 has within 24 hours.
"I'd wager that if you attract the curiosity of someone possessing such a tool, watching Netflix from your Munich hotel room is probably the least of your concerns."
They could essentially decrypt your traffic, but more importantly they will be able to log into your VPN as you. From here they may gain access to home networks, etc. Or use the IP address to conduct fraudulent activities.
OpenVPN is the safest it utilizes certs to authenticate. It's easily setup on Mac (which looks like what you are using). Can easily be utilized on mobile phones (android and iPhone -- with jailbreak).
"Within 24 hours" is kinda my point. It's not a trivial thing to crack.
DeleteI considered OpenVPN but as you note it requires client software and jailbreaking, neither of which was desirable. But it certainly is an option for those concerned that some entity will commit to the hours of computation required to crack their PPTP encryption.
ms-chapv1 was regarded as vulnerable, which led to ms-chapv2... perhaps there will be another turn of the crank?
Meanwhile, I'm researching whether PEAP might be an option. TBD.
I'd appreciate your suggestions. Also welcome are your thoughts on the ssh proxy tunnel I originally documented at http://unvexed.blogspot.com/2012/08/how-to-use-raspberry-pi-as-secure-web.html
I wanted an closed VPN for my company. However, I can't build it on my own. Should I hire a company like them http://www.ect-virtualpbx.com/? What do you think?
ReplyDeleteThere are plenty of suppliers who can do the job for you. Also plenty who will point you in the wrong direction.
DeleteGet local recommendations--you need someone nearby for those inevitable support incidents--but first make a concise list of everything you want your VPN to do:
o What hardware will your road warriors be using (laptops, iDevices, work-from-home desktops...). Will you own these or will they, or will there be a mix? There's a host of solutions for the emerging "Bring Your Own Device" approach... just google "BYOD" for a spectrum of solutions, from simple to Orwellian.
o Consider what infrastructure you'll be running in your headquarters (Exchange? CRM? VoIP?) and its throughput. Will users have local copies of things like customer databases to use when they have no connection? ...That raises sync issues if so.
o Consider any special legal framework you need to accommodate: ITAR, HIPAA, etc.-- you'll want to choose a provider who understands that.
o Take a hard look at any proposal in terms of usability, scalability and compatibility. Ask for references-- and check them, talking to users as well as IT folks and executives, both of whom may be motivated by self-justification. Trouble is, I've seen many situations where companies go through several different implementations at huge cost and still aren't satisfied. That's great for the full employment of consultants and IT staffers but not so great for the bottom line.
o Insist on demonstrations of setups similar to each recommendation-- and check the demos include quick sign-on and robust performance from remote locales with iffy WiFi like hotels, coffee-shops and via cell-phone tethering.
o Ask about locales which block certain ports, including those used by VPNs-- what is the provider's strategy for getting around that?
o Ensure your software will continue to work and that tech-unsavvy users can live with the solution. Look for platform-independence so you're not painted into a corner with equipment or OS suppliers... too many IT shops are looking for lock-in.
All you don't need is a huge hit to your users' productivity. Check for annoyances like timeouts and frequent re-authentication. Ensure your remote users can still print to their local network printers when the VPN is on, and so on. From what I've seen in businesses attempting to mount enterprise-class secure architectures, there are lots of blind alleys and gotchas... and many opportunities to pay twice, three times or more, with lots of disruption and distraction from your real business, and lots of frustration for your users. All to the benefit of the consultants, of course.
Proceed carefully, and also consider simplifying matters by using secure, web-based services like Salesforce.com and Zoho.com. Where is it written that a company must run its own servers? Email in particular is something I'd just as soon offload to someone else who's trustworthy and competent. One email service provider I've had great luck with is Luxsci.com (tell 'em I sent you)-- I use them for email service for my novanetrics.com domain, and they're flawless, with superb support, excellent security and good pricing. And don't forget that you can already enjoy very secure encryption of emails as they transit between your users and your server just by checkmarking the TLS, SSL or other option your email provider offers-- no VPN is necessary for that.
And also be sure you're not being steamrollered into a needlessly complex system out of some exaggerated sense of uncertainty and dread. Do you really need NSA-level security in your business?
The solutions I've posted here on my blog are great for individual geeks like me who just want to get at their Netflix or VoIP from their hotel in Frankfurt, but I wouldn't want to run any sort of substantial enterprise's information pipeline through a Raspberry Pi! Good luck, and write back with what you learn.
Good luck!
Being a network security professional I love this article, but if i think about a common VPN user who are not that much technical. The best choice for him is to use a 3rd party VPN software for his security. Here is the list of top 5 vpn providers of 2015. http://www.vpnranks.com/5-best-vpn-software/
DeleteHi,
ReplyDeletefrom my point of view the described PPTP VPN with CHAP is not a robust and state-of-the-art technology approach because the described hacking valiolation. I think a better approach would be to use VPN L2TP/IPSEC. It is available on Debian and also available on modern android devices without jailbreak.
Perhaps you can modify your HowTo to use L2TP/IPSEC.
I'll get to L2TP at some point... tried it and had issues getting it running.
DeleteMeanwhile I really don't think that a vulnerability that takes 24 hours of immense compute effort to crack is much of a vulnerability at all. But that's just me. The mschapv2 vulnerability can be minimized by using a very strong password, which seems a reasonable compromise. IMHO of course.
I got my pi running the vpn per your instructions, but I can only get one user connected. I'm not even talking simultaneously. I've checked the username and password and I'm good with the settings. One entry per line with the astrix on the end, but nothing. I'm wondering if you might have an Idea as to the cause of the issue.
ReplyDeleteThanks in advance.
Hi Shaun,
ReplyDeleteHm, first thought is that both the username and password are password-sensitive. (In fact, I haven't checked with the Raspberry Pi, but some implementations of _nix-like systems require usernames to be all lower-case, so my use of capital-R "Ralph" as an example might be in error.)
I also had one time when I added a user and, in testing, couldn't VPN-in as him. Turned out I'd typed "pptp" rather than "pptpd" in between the username and the password.
Are you able to log on your other users via ssh? ...Write back; I'm currently 15 time zones away, so my responses may be delayed, but I am eager to help you get this working.
Be assured it's probably something annoyingly simple!
--Scott
I'm not able to login any user via ssh other than the pi user. All the user settings entries in the chap-secrets are correct and lower case. I just created the two user accounts via sudo adduser and was able to ssh in, but no vpn for the second user. I'll try setting up the client again. maybe I missed something for the second user.
ReplyDeleteHi again Shaun,
DeleteAha, seems there's something buggered about those user accounts. http://www.debian-administration.org/articles/2 gives the steps. Everything's case-sensitive.
I'm pretty sure that if your user can't ssh in they won't be able to vpn either. The nice thing about this test is that the chap-secrets stuff is not used in the ssh process. So we've isolated the issue to something wrong with the user setup.
Good luck!
According to me it's Hotspot Shield ( www.vpn-mac-security.com ) that offers complete privacy and security for my Mac. Actually it encrypts our web surfing session to protect our Mac machine against online identity theft, web spies, hackers and malware threats.
ReplyDeleteWell, Hotspot Shield does the job of cloaking one's web (and other?) activities. You can pay for the privilege or endure ads and videos inserted in your web browser.
DeleteOr you can utilize your Raspberry Pi as I've described, at no ongoing cost, with no ads and no downloaded client needed.
There is no shortage of paid VPN solutions; Cloak is another really nice one for OS X and iOS (www.getcloak.com) that offers a block of free usage every month with no ads. TorVPN also looks interesting (www.torvpn.com), also offers a block of free usage per month, and offers a pptp channel, so no downloaded client should be necessary for iOS or any other platform.
There are many other options too. Depending on your needs and planned usage, one or another might surface as best for you.
Just keep in mind that instead of blocking the pptp VPN port, some internet providers such as colleges and even countries will block traffic to the IP address of known commercial VPN providers and web proxies. The logic here is that corporate VPN usage would be allowed but personal cloaking would be prohibited. This is another advantage to running your own VPN on your Raspberry Pi or other private machine-- your home or business IP address is unlikely to be blocked. So: try before you buy. Just keep your usage modest in those situations to avoid attracting attention.
Thanks a million for your tutorial. It works great. When accessing Safari on my iPad, I see my home ip-adress. I have entered my local default gateway, but I can't seem to reach other machines/nas devices on my home network. Any suggestions?
ReplyDeleteWhat server services are the other machines on your networks running? By default, most computers have file sharing turned off, and usually there's no web-server running. So when you type the IP address of a device into your iPad's browser, you'll get a timeout for your troubles. ...At least, I'd expect that's the trouble, but write back if there's some service you know is running.
DeleteThis is great. I only have trouble connecting from an outside network now. Port 1723 is open and the vpn works great connected locally. Are there other ports that might need opening? Is there anyway to know for sure that my ISP is not blocking the traffic?
ReplyDeleteProgress!
DeleteHypothesis 1: Something is blocking port 1723 between your router and the Internet. Be sure it isn't the router-- maybe it has separate port filters for LAN and WAN? Is there a firewall active somewhere that needs a hole poked through it? Does your DSL or cable modem have a firewall function?
Hypothesis 2: Your VPN is not set up to accept connections from external IP addresses. There's a "*" specified in my instructions which enables this... is it present in your configuration file?
Strange, I can connect to the VPN, ping google.com, and other local devices but I can't access local or remote HTTP server (connexion timeout on google.com or on my router web interface...)
ReplyDeleteSome other services still works (Eg QQ, SSH, ...)
Any idea of what can be wrong ?
Here's a maybe: this rather sounds like what happens if you omit (or forget to save) the checkbox in the last screen-snap in my post above, the one where you instruct the VPN to send all traffic through the tunnel.
DeleteNope, I checked it a few times, and this checkbox is on.
DeleteEven more strange: this website works http://monip.org and the IP displayed is the correct one (the one of my router).
I tried a few things. A traceroute to google.com shows this:
RBPI IP -> Router IP -> Outside world ....
wget on google.com shows that I can receive HTTP header (301 Moved Permanently).
But I fail to receive content, last step is:
Connecion to www.google.fr (www.google.fr)|74.125.230.223|:80...connected. HTTP request sent, waiting for answer...
Hm... are steps 13 & 14 done correctly? RasPi rebooted?
DeleteBy the way, I'll be traveling in a bit, and it might take me until tomorrow to get back with further thoughts. Good luck...
DeleteI'd wager the latter...
Deletedownsizing the mtu and mru solved the problem !
Deletemtu 1280
mru 1280
Many thanks for the tutorial, there were a couple of important points other tutorials hadn't listed. I now have mine connected from a Linux laptop to my pi. Even using a mobile phone as a tethering device I can get connected.
ReplyDeleteGoing to try it it with openvpn now though, everyone does warn that pptp is not the safest method. This was a great starting point to become comfortable with VPN in general though.
I have already been trying to find something such as this for some time now. Thanks!
ReplyDeleteThese instructions worked great! Had my iPad connected up in no time. Thanks!
ReplyDeleteMy provider will give me 3 IP addresses off the cable modem. I think I might put a 2nd NAT router on there and put a dedicated VPN server Pi behind that one so there is no chance that someone could hack the VPN and use it to get into my internal LAN.
Has anyone got this to work with a 3g USB dongle instead of on a network with a router? I'm trying to set up my pi at the office so that I can VPN in to access a machine connected to eth0 on the pi. I just can't seem to get the pi to pick up the incoming VPN connection. Works fine when I tested it at home on my router so I'm pretty sure it is set up correctly. I have a DDNS set up and the IP updates as it should. Also spoken to my very helpful ISP who have confirmed that no ports are blocked by them. I don't know enough about iptables or routing tables to know if I have missed something there. Any help would be greatly appreciated.
ReplyDeleteI got it working, DNS servers are ok (dnsleak test), ip address from home, can surf without any problems, but can't get streaming TV working (belgacom tv overal).
ReplyDeleteIt starts to download the stream but I only get a black screen.
Any ideas?
Hm... did you set your computer to send ALL data through the VPN?
DeleteYes, I'm using it on my iPad and iPhone.
DeleteWhen i turn off the option 'send all data' I'm getting an error that I'm not on my ISP (that's correct).
I'm thinking about the iptables, but I'm a n00b.
I'll be consumed with work for the next 48 hours but will try to think about what might be going on. I did not have to mess with iptables, nor did most others, but it has come up a few times so perhaps that plays a role. I'll work to figure it out, but it'll take some time. Keep checking back! --Scott
Deletethanks!
DeleteI asked on a Belgian forum (userbase) what could be wrong, and one said that iptables shoudn't be necessary.
With the app, it's possible to see if there's data transmitted, and according to that app I've used it for more than 10 minutes (that's the test period). So there's data transmitting. I've tried it at home and at work... no go :(
Y'know, there could be something "special" about your work LAN. It's not uncommon for some or all VPN activity to be blocked. I've seen this happen in hotels, on campuses, and even entire countries.
DeleteI don't think it's my work LAN that's acting so strangely.
DeleteI just used it at home (3G connection) and the screen stays black.
I tried it today with OpenVPN, the same problem...
Seems the video streaming service may itself be VPN-intolerant in some fashion... am I correct that most everything else works?
DeleteThese are the connections the app is connecting to:
Deletesettings.crashlytics.com port 443
sphinx.skynet.be port 443
google-analytics.com port 80
dtvhlscsm.idtv.belgacom.net port 80
I don't know about port 443 if it should be defined or not in the Raspberry?
443 is just the https port. I can't imagine what could be blocking that-- it's a commonly used port for secured connections.
DeleteTell me about your client. PC, iDevice, Android...? In a bit of googling here I'm finding there are some situations reported where VPN encryption is problematic in ways similar to what you report. In those cases encryption must be turned off; see http://traveldevel.com/vlc-stream-convert/streaming-over-vpn ...seems similar?
It's probably my works security team that's blocking some traffic from this tunnel. When I use cellular data it works, when using wifi it just stays black :(
DeleteI've tried it on IE, Android phone & tablet, iPad, iPhone nothing works.
OK, I figured out when I connect with a lan cable it works, when using wi-fi it doesn't.
DeleteI have 3 NICs in my pc. Is it possible to get the 'normal' data through NIC1 and VPN through NIC2? I'm using W7 Pro @ work.
Top suspect is a router configuration issue. Check port forwardings.
DeleteI don't know enough about iptables or routing tables to know if I have missed something there. Any help would be greatly appreciated.
ReplyDeleteI did not need to deal with iptables in my setup but, per my previous reply, will be digging into it to see if that might be necessary in some circumstances. --Scott
DeleteThank you for this information very useful !
ReplyDeleteOh my goodness! Impressive article dude! Thank you,
ReplyDeleteHowever I am going through troubles with your RSS.
I don't understand why I am unable to subscribe to it. Is there anybody getting similar RSS issues?
Anyone who knows the answer can you kindly respond? Thanx!!
My page :: Solve Captchas
This looks very useful - I am just about to set up a Pi as a proxy server.
ReplyDeleteWorking my way through, I am confused by you IP addresses in steps 7 and 8 as they appear invalid.
Should they not be, for example, 192.168.0.202 and 192.168.0.240-255?
Thank you! Sharp eyes. I will correct that.
DeleteNext point :-)
ReplyDeleteItems 6,7,8.
You say "Scroll down until you find the lines which set localip and remoteip."
Now there is a block of comments and settings which have "#TAG: localip" at the top, then "#localip" at the bottom.
First pass I un-commented the TAG lines; redoing various things as it isn't working yet but I have re-commented them and un-commented the localip line.
Working with Windows 7 and it is not going well so far. This may of course be due to my router. When I make a VPN connection on my local LAN from W7 to the Pi, the router reports that the Pi has changed IP address to 192.168.1.1 although the Pi still reports that Eth0 is 192.168.0.118. Wierd.
Hm.
DeleteThe "block of comments" should remain a block of comments. The actual settings lines follow that block of comments. Here's what mine looks like:
# TAG: remoteip
# Specifies the local and remote IP address ranges.
#
# Any addresses work as long as the local machine takes care of the
# routing. But if you want to use MS-Windows networking, you should
# use IP addresses out of the LAN address space and use the proxyarp
# option in the pppd options file, or run bcrelay.
#
# You can specify single IP addresses seperated by commas or you can
# specify ranges, or both. For example:
#
# 192.168.0.234,192.168.0.245-249,192.168.0.254
#
# IMPORTANT RESTRICTIONS:
#
# 1. No spaces are permitted between commas or within addresses.
#
# 2. If you give more IP addresses than MAX_CONNECTIONS, it will
# start at the beginning of the list and go until it gets
# MAX_CONNECTIONS IPs. Others will be ignored.
#
# 3. No shortcuts in ranges! ie. 234-8 does not mean 234 to 238,
# you must type 234-238 if you mean this.
#
# 4. If you give a single localIP, that's ok - all local IPs will
# be set to the given one. You MUST still give at least one remote
# IP for each simultaneous client.
#
# (Recommended)
localip 192.168.0.202
remoteip 192.168.0.240-255
Great tutorial! worked like a charm! Thanks!
ReplyDeleteGreat analysis on vpn set up. Thank you.
ReplyDeleteAnsel Marvin | Fipe