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 4148 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:

(/etc/ppp/options.pptp)
name pptpd
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
#require-mppe-128 -- works with iPhone1-3, fails with iPhone4
ms-dns 192.168.0.1
proxyarp
lock
nobsdcomp
novj
novjccomp
nologfd

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:

(/etc/ppp/chap-secrets)
(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)

(/etc/pptpd.conf)
option /etc/ppp/options.pptpd
localip 192.168.0.1
remoteip 192.168.0.128-191
debug

(/etc/ppp/ip-up.local)
# 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 192.168.0.1 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 24.18.213.241 control connection finished
Aug 31 19:48:30 usloft1645 named[20202]: no longer listening on 192.168.0.1#53

This heavy-handed smack in ip-up.local causes it to listen on the 192.168.0.1 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 192.168.0.1
Aug 31 19:28:50 usloft1645 pppd[9916]: remote IP address 192.168.0.128
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