OpenWRT & PPTPD: A Love Story
Firesheep got me thinkin' that I should probably do a little more to beef up the security of my Internet connection on public networks. PPTP has always been a favorite of mine, because it hides traffic well enough to deter most people and it's easy to setup on both Linux and Windows. I ran a Windows PPTP server for years, but recently decided to just host the service my WRT54GS v3 router running OpenWRT. Three hours later, I've got it running smoothly. Here's how I did it:
First, I installed and setup OpenWrt Backfire 10.03 and set my internal IP pool to be on the 172.16.x net, with the gateway (OpenWRT router being 172.16.1.1). Then, I headed over to OpenWRT's PPTPD HOW-TO.
opkg update
opkg install pptpd
opkg install kmod-crypto
opkg install kmod-mppe
/etc/init.d/pptpd enable
/etc/init.d/pptpd start
I believe my /etc/ppp/options file doesn't have any modifications, but just in case, this is what it looks like:
#debug
logfile /dev/null
noaccomp
nopcomp
nocrtscts
lock
maxfail 0
lcp-echo-failure 5
lcp-echo-interval 1
Now that I think about it, very few modifications were ultimately made to /etc/ppp/options.pptpd
auth
name "pptp-server"
lcp-echo-failure 3
lcp-echo-interval 60
default-asyncmap
mtu 1482
mru 1482
nobsdcomp
nodeflate
#noproxyarp
#nomppc
chapms-strip-domain
# Otherwise, your chap-secret file will have to include "DOMAIN\\user" instead of user.
mppe required,no40,no56,stateless
require-mschap-v2
refuse-chap
refuse-mschap
refuse-eap
refuse-pap
ms-dns 172.16.1.1
#plugin radius.so
#radius-config-file /etc/radius.conf
If you compare this to the original file, you'll notice I deleted the entry "172.16.1.1:" at the top of the file, and added the entry: ms-dns 172.16.1.1. I don't know why, but DNS didn't work well when the the client's defaults were used so I forced them to use the router's LAN DNS server.
Then I added some users to the /etc/ppp/chap-secrets file. I'll paste the contents, then go over the details. Oh, and don't forget to chmod 600 /etc/chap-secrets because the file's perms are insecure by default:
#USERNAME PROVIDER PASSWORD IPADDRESS
iphone pptp-server suprAdv4ncedPwd! 192.168.80.1
ipad pptp-server rlyAdv4ncedPwd! 192.168.80.11
hackbook pptp-server megaAdv4ncedPwd! 191.68.80.3
windows pptp-server ttllyAdv4ncedPwd! 192.168.80.2
extra pptp-server megaAdv4ncedPwd! 192.68.80.4
The chap-secrets file alone suggests that OpenWRT/PPTP is not an enterprise solution. I wouldn't propose it for any company with a decent budget, but times are tough and ghetto is looking better than ever to many companies.
I would actually have fewer entries in this file if the IPADDRESS field was not such a big issue. Unfortunately, it seems that the DHCP pool has been compiled into the service. It sets up the router's pppN to be 192.168.0.x and assigns the clients a 192.168.1.x address by default. Which is unfortunate, because SO DOES EVER OTHER RESIDENTIAL ROUTER, EVER. So routing issues keep pop up. Because of that, I force PPTPD to assign each user a specific IP, in the 192.168.80.x range because I've never seen any router use that subnet.
The usernames are whatever you'd like them to be (I made them the name of my devices) but if you are dialing-in from a Windows machine, you will have to preface the username with the Windows domain name or the name of your workstation if you are not on a domain UPDATE: adding chapms-strip-domain to options.pptpd fixes this. The "pptp-server" is what the service was named in options.pptd, the password is just that, and the IPADDRESS is the IP that the given client will be assigned.
Initially, my /etc/firewall.user didn't have all the proper entries, so my client was able to authenticate and all that, but no traffic was being routed to the 172.16.x subnet, nor was it being routed to the Internet. Here's what worked:
# This file is interpreted as shell script.
# Put your custom iptables rules here, they will
# be executed with each firewall (re-)start.
iptables -A input_wan -p tcp --dport 1723 -j ACCEPT
iptables -A input_wan -p gre -j ACCEPT
iptables -A input_rule -i ppp+ -j ACCEPT
iptables -A forwarding_rule -i ppp+ -j ACCEPT
iptables -A forwarding_rule -o ppp+ -j ACCEPT
iptables -A output_rule -o ppp+ -j ACCEPT
The first block allows clients to connect to the PPTP service and the second one allows it to communicate with both the Internet and the local network. And voila, you are done. I know it seems straightforward and doesn't deviate much for the default install, but it took over three hours of trial and error to get here. I've logged in successfully with an iPhone (over 3G, EDGE and wifi), an iPad, a Windows 7 machine and Mac OS X. The iPhone is of special importance to me -- after connecting to a local coffee shop's unsecured network on my laptop and my iPhone, I successfully hijacked my iPhone's Facebook app session using FireSheep. So, now I'll be encapsulating all of my traffic by sending it over to the fiber connection at my office, what what.
Next up, I'll probably start playing around with the RADIUS plugin. Stay tuned.
About
-
We are IT consultants
who grew up living and loving life
in Cajun Country.
Authors
Categories
- Oracle
- OS X & iDevices
- PowerShell
- Security
- SharePoint
- SQL Server
- VBScript
- Virtualization
- Windows
- Wordpress
January 8th, 2010 - 13:04
Hey Thanks for that! I've been using a script in Powershell that sets up all my users for me daily in including home folder and permissions. the only stumbling block was I had to keep going in and resetting the subfolder permissions after.
THIS NAILED IT!
Sean
the Energized Tech
August 29th, 2011 - 19:03
Thanks thanks! I didn't get this working using just the OpenWRT Wiki. Now everything is working OK!
October 13th, 2011 - 14:22
Really a good stuff.
Thanks for this small and educative tutorial
I just have a minor note:
if you do really plan a security solution for the small-to-average business, go for OpenVPN.
PopTop protocol with the MPPE algos are already broken, so if someone sniffs enough packets he’ll be able to broke it and decrypt the information.
Otherwise, use RADIUS with CHAP. But…seriously why should we need to make this to our selves when there’re so many free and good working solutions like OpenVPN.
October 23rd, 2011 - 20:11
because iphones, ipod and ipads don't support OpenVPN
October 24th, 2011 - 17:37
Sad but true. I recall OpenWRT's IPSec also not getting along with the iPhone as well. I was sooo close, but there was some issue that stopped me. That was almost a year ago, so hopefully something has updated/changed. We'll see.
I'm working on a somewhat straightfoward tutorial for OpenVPN and Mac OS X right now and hope to have it published sometime this week. I ain't gonna lie, it was workaround-central but the payoff was nice.
March 25th, 2012 - 10:01
Hi,
Thank you for this very useful post. I successfully connected my iphone to my openwrt router but after a day I discovered something strange. In the system log I could see unsuccessful SSH login attempts from a foreign IP address and after a ('Shields Up') port scan from the internet side it turned out that ports 22, 80, 143, etc. become open on the WAN interface.
I'm using backfire 10.03.1. Can you please check my findings?
Thank you!