Notice: register_sidebar was called incorrectly. No id was set in the arguments array for the "Sidebar 1" sidebar. Defaulting to "sidebar-1". Manually set the id to "sidebar-1" to silence this notice and keep existing sidebar content. Please see Debugging in WordPress for more information. (This message was added in version 4.2.0.) in /usr/share/wordpress/wp-includes/functions.php on line 4146 Tech Notes » Blog Archive » PPTP on iPhone: Changes iPhone3 to iPhone4

PPTP on iPhone: Changes iPhone3 to iPhone4

Uncategorized Add comments

A while ago, I configured PPTP so that my friends in China’s firewalled world could get their Facebook and Twitter fix. … cuz, we all know we need that constant poke-poke-poke.

The config I had was very much like “Tim” wrote on Shared Know How on Sept 28, 2008 — in fact, it’s a very basic, standard config, it’s a bit difficult not to wander onto it by accident (although Tim’s article is quite useful to paint the solution and validate that “yes, it does work” — and validation is not to be understated).

The iPhone4 didn’t connect to that setup anymore, and there was very little indication why:
Aug 31 19:28:20 usloft1645 pppd[9875]: Connect: ppp0 /dev/pts/1
Aug 31 19:28:20 usloft1645 pppd[9875]: Unsupported protocol 'IPv6 Control Protovol' (0x8057) received
Aug 31 19:28:20 usloft1645 pppd[9875]: MPPE required but peer negotiation failed
Aug 31 19:28:20 usloft1645 pppd[9875]: Connection terminated.
Aug 31 19:28:20 usloft1645 pppd[9875]: Connect time 0.0 minutes.

So lacking any real diagnostic methods, I began randomizing on the configs around MPPE. Damned if it wasn’t as easy as just dropping the requirement for MPPE:

name pptpd
#require-mppe-128 -- works with iPhone1-3, fails with iPhone4

I’ll need to clean up this entry a bit, but that’s the change so far, and it’s connecting. I’ll see too if I can find compatibility setting to get MPPE back, since this drops out payload-protection on a VPN which users may assume is usually secure from prying governments eyes.

In Summary, the working config right now is:

(where “username1” is actually a user’s username, and “password1” is his/her plaintext password, but “*” is actually an asterisk)
username1 * password1 * # some comment ...
username2 * password2 *

(/etc/ppp/options.pptp as above)

option /etc/ppp/options.pptpd

# a bit heavy-handed, but gets named listening on the internal interface faster
rndc reload

This last file is a bit unusual; I found that although BIND is configured (named.conf) with the interface to provide recursion and service, it would stop listening on the PPP link when the last connection closed:

Aug 31 19:42:54 usloft1645 pptpd[9915]: CTRL: Client control connection finished
Aug 31 19:48:30 usloft1645 named[20202]: no longer listening on

This heavy-handed smack in ip-up.local causes it to listen on the ppp0 interface again:
Aug 31 19:28:50 usloft1645 pppd[9916]: Connect: ppp0 /dev/pts/1
Aug 31 19:28:50 usloft1645 kernel: PPP Deflate Compression module registered
Aug 31 19:28:50 usloft1645 pppd[9916]: local IP address
Aug 31 19:28:50 usloft1645 pppd[9916]: remote IP address
Aug 31 19:28:50 usloft1645 named[20202]: loading configuration from '/etc/named.conf'

Leave a Reply

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in