Routing IPv6 traffic through Debian pptpd into Hurricane Electric's IPv6 tunnel

Question

I have set up a tunnel using Hurricane Electric's services on a Debian machine. It seems to work alright; I can ping6 ipv6.google.com and open it in links.

I've also set up a PPTP daemon on the machine. (Yes, I've read that PPTP is insecure; this is primarily for experimental purposes.) When I connect to this PPTP daemon using Mac OS X, IPv4 works fine.

I seem to be unable to get routing of IPv6 traffic to work, however. OS X doesn't pick up an IPv6 address over PPTP, and it ignores announcements using radvd, which seems to be a daemon for announcing IPv6 router's existence. To clarify: I see the router announcements sent by radvd appear in Wireshark on the OS X machine's ppp0 interface.

Overall, this is not a production nor a long-term setup, just something I'd like to get to work (otherwise I might be posting on ServerFault). So I don't care about the fact that if the machine reboots, half of the setup goes down with it until manually reset. In fact, that's a plus for me, in this case.

/etc/network/interfaces (snippet)

auto he-ipv6
iface he-ipv6 inet6 v4tunnel
        address 2001:dead:beef:f00d::2
        netmask 64
        endpoint  216.66.86.114
        ttl 255
        gateway 2001:dead:beef:f00d::1

/etc/pptpd.conf

option /etc/ppp/pptpd-options
localip 10.0.101.1
remoteip 10.0.101.2-200

/etc/ppp/pptpd-options

name pptpd
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128
proxyarp
nodefaultroute
lock
nobsdcomp
ipv6 ,

/etc/ppp/chap-secrets

ivucica pptpd THEPASSWORDHERE 10.0.101.2 10.0.101.3 10.0.101.4 10.0.101.5

/etc/radvd.conf

interface ppp0
{
        AdvSendAdvert on;
        prefix 2001:dead:beef:f00d::/64
        {
        };
};

I turned on ipv6 forwarding:

echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

And yes, I did restart radvd whenever I reconnected/recreated-the-ppp0-device. :-)

What am I missing?

Solution 1

So it turns out there were several issues with my setup. Let's document everything!

Client OS

Mac OS X does not particularly like IPv6 over PPP. Use the following after the connection has been set up:

sudo ipconfig set ppp0 AUTOMATIC-V6
sudo route add -inet6 default -interface ppp0

The prior seems to make OS X adhere to router advertisements; the latter adds a default route for IPv6. (Now, if only the certain-fruity-mobile-operating-system version of route provided -inet6, I'd be a happy wooden boy.)

Also take note that OS X will ignore whatever address was supposed to be negotiated over IPv6 and set up only a local address. This may interfere with routing towards OS X.

On the other hand, Windows 8 (of all systems!) has happily picked up the address sent over PPP, took note of the router advertisement, and overall configured itself flawlessly. PPTP really works nice in Windows.

Server

First thing I missed was that Hurricane Electric's tunnel broker actually assigns TWO /64 prefixes; one is supposed to be solely for client use, while the other is intended for routing additional clients (such as the PPTP client). And if you need more addresses (or prefixes!), you can even get a /48 prefix. (With IPv6, this means there's more bits for 'your' use; HE's prefix takes 'only' 48 bits. So that provides you a few more bits to control before the auto-generated suffix, created from a MAC address or even created randomly, kicks in and takes over last 64 bits. You could theoretically wiggle and subnet even with only 64-bits to spare, but I've seen strange behavior on either Windows 8 or OS X, so I wouldn't rely too much on that.)

Instead of configuring radvd directly and running it as a server -- simply don't configure it globally. That is, don't run it as a service on Debian.

Instead, let's follow Konrad Rosenbaum's example, at Silmor.de, and have radvd configured after pppd creates the PPP interface.

1. Set up your IPv6 connectivity. I use Hurricane Electric; I've configured it as follows:

   # hurricane electric tunnel
   # based on: http://www.tunnelbroker.net/forums/index.php?topic=1642.0
   auto he-ipv6
   iface he-ipv6 inet6 v4tunnel
       address 2001:470:UUUU:VVVV::2
       netmask 64
       endpoint  216.66.86.114
       ttl 255
       gateway 2001:470:UUUU:VVVV::1
       ## from http://lightyearsoftware.com/2011/02/configure-debian-as-an-ipv6-router/
       # I did not set up the routing of the /64 nor the /48 prefix here, but
       # this would ordinarily do it.  
       #up ip link set mtu 1280 dev he-ipv6
       #up route -6 add 2001:470:WWWW:VVVV::/64 he-ipv6
   
       # Note that Hurricane Electric provides different /64 IPv6 prefixes
       # for the client (UUUU:VVVV) and routing (WWWW:VVVV). 
       # And the /48 prefix is very different altogether.
   

2. Install pptpd. (Of course, take note of PPTP's insecurity as a protocol, and consider using OpenVPN or some other alternative.)

3. Edit /etc/ppp/pptpd-options

   name pptpd
   refuse-pap
   refuse-chap
   refuse-mschap
   require-mschap-v2
   require-mppe-128
   proxyarp
   nodefaultroute
   lock
   nobsdcomp
   ipv6 ::1,::2
   

   Note the last line is different from the text in my question. You're assigning some static addresses which may be respected by your client OS or not. (OS X seems to ignore them, but Windows uses them.)

4. Create users for PPTP. Second column filters based on name argument in pptpd-options. Edit /etc/ppp/chap-secrets:

   ivucica pptpd AHyperSecretPasswordInPlainText 10.0.101.2 10.0.101.3 10.0.101.4
   

   You're supposed to be able to replace the addresses with * instead of listing them manually. I did not try that out.

5. Assign your PPTP users some IPv6 prefixes. NOTE: this is solely used by the script I'll list below, which is derived from Konrad's script.

   Edit /etc/ppp/ipv6-addr:

   ivucica:1234
   littlejohnny:1235
   

6. Add new file /etc/ppp/ipv6-up.d/setupradvd:

   #!/bin/bash
   ADDR=$(grep ^$PEERNAME: /etc/ppp/ipv6-addr |cut -f 2 -d :)
   if test x$ADDR == x ; then
    echo "No IPv6 address found for user $PEERNAME"
    exit 0
   fi
   
   # We'll assign the user a /64 prefix.
   # I'm using a Hurricane Electric-assigned /48 prefix.
   
   # Operating systems seem to expect to be able to assign the 
   # last 64 bits of the address (based on ethernet MAC address
   # or some other identifier). So try to obtain a /48 prefix.
   
   # If you only have a /64 bit prefix, you can try to assign a
   # /80 prefix to your remote users. It works, but I'm only now
   # trying to enable these users to have routing.
   
   USERPREFIX=2001:470:XXXX:$ADDR
   USERPREFIXSIZE=64
   USERPREFIXOURADDRESS=1
   USERPREFIXUSERADDRESS=2
   
   # Add the address for your side of the tunnel to the PPP device.
   ifconfig $IFNAME add $USERPREFIX::$USERPREFIXOURADDRESS/$USERPREFIXSIZE
   
   # establish new route
   # (when a packet is directed toward user subnet, send it to user ip)
   route -6 add $USERPREFIX::/$USERPREFIXSIZE gw $USERPREFIX::$USERPREFIXUSERADDRESS
   
   #generate radvd config
   RAP=/etc/ppp/ipv6-radvd/$IFNAME
   RA=$RAP.conf
   echo interface $IFNAME >$RA
   echo '{ AdvSendAdvert on; MinRtrAdvInterval 5; MaxRtrAdvInterval 100;' >>$RA
   echo ' prefix' $USERPREFIX::/$USERPREFIXSIZE '{};' >>$RA
   
   # Instead of your DNS...
   #echo ' RDNSS $USERPREFIX::$USERPREFIXOURADDRESS {}; };' >>$RA
   # ...try assigning the Google DNS :)
   echo ' RDNSS 2001:4860:4860::8888 {}; }; ' >> $RA
   
   # The creation of radvd configuration could be more readable, but whatever.
   
   # Start radvd
   /usr/sbin/radvd -C $RA -p $RAP.pid
   
   exit 0
   

   Don't forget to chmod the script to make it executable by pppd:

   chmod 755 /etc/ppp/ipv6-up.d/setupradvd
   

7. The script spews radvd configuration into /etc/ppp/ipv6-radvd/… ensure that the folder exists!

   mkdir /etc/ppp/ipv6-radvd
   

8. Also add /etc/ppp/ipv6-down.d/setupradvd (and make it executable!) -- taken verbatim from Konrad:

   #!/bin/bash
   RAP=/etc/ppp/ipv6-radvd/$IFNAME
   kill `cat $RAP.pid` || true
   rm -f $RAP.*
   

   And

   chmod 755 /etc/ppp/ipv6-down.d/setupradvd
   

I have not tested using DHCPv6 to distribute the routing information, addresses or DNS information, especially since rtadv should be fulfilling these roles. It also would not help me, because as of Mountain Lion, OS X still does not ship with a DHCPv6 client (perhaps intentionally; nine out of ten dentists most of IPv6 experts agree that DHCP is evil).

Once again, please note Michael's comments on PPTP security; consider using OpenVPN in production.

Yes, Konrad Rosenbaum also has a nice tutorial on IPv6 over OpenVPN. :-)

Solution 2

Poptop doesn't seem to have any support for IPv6. And its maintainers recommend you don't use it anyway, for security reasons.

PPTP is known to be a faulty protocol. The designers of the protocol, Microsoft, recommend not to use it due to the inherent risks. Lots of people use PPTP anyway due to ease of use, but that doesn't mean it is any less hazardous. The maintainers of PPTP Client and Poptop recommend using OpenVPN (SSL based) or IPSec instead.

Recent versions of OpenVPN support IPv6, so that's probably your best bet during the transition.

Comments

[Ivan Vučica]

I'm aware of security issues, which is why I mentioned that this is for experimental, non production uses :-) Anyway, while I could install a third party program (OpenVPN) on Mac, iPhone doesn't support OpenVPN, and I'd like to play with that as well. Re ipv6 support, doesn't Poptop primarily "just" wrap PPP? Shouldn't ipv6 support be pppd's duty? old.nabble.com/IPv6-and-poptop-td3805329.html

[Michael Hampton]

Maybe you can use that sort of hackery to get it working, but since this is the last word from the pptpd developers, I wouldn't count on any real support for it, especially if something breaks (and I'd have to worry a lot about that). And besides, the iPhone has an official OpenVPN app...

[Ivan Vučica]

While I'll be trying out OpenVPN at some point, when I need actual VPN access and not just for playing around :-) the actual problem was with OS X all but ignoring router advertisements, and also not routing IPv6 traffic through PPP.

[Shtirlic]

Why are you using gw $USERPREFIX::$USERPREFIXUSERADDRESS :2 address? If it's not assigned to everything?

[Ivan Vučica]

That's the address on the 'other side' of the PPTP connection. If a packet needs to go toward the private subnet, this routes the traffic to be handled by the device handling this address. At least that's my understanding of what I have done; feel free to point out if that's not necessary and explain what's actually happening :-)