tunnelbroker.net automatic tunnel IP update and tunnel setup (on Mac OS X)

tunnelbroker-net.sh

#!/bin/bash

#### This script is published by Philipp Klaus <[email protected]>
#### on <http://blog.philippklaus.de/2011/05/ipv6-6in4-tunnel-via-hurricane-electric-tunnelbroker-net-automatic-ip-update-on-mac-os-x/>
#### It is originally by freese60 and modified by limemonkey.
#### Found on <http://www.tunnelbroker.net/forums/index.php?topic=287.0>

### Uncomment this line to debug the script:
#set -x

#######################################################################
#### Config start
### 
### This configuration file must set the following variables:
### MYIF, DEVNAME, LOCAL_IPV4, EXTERNAL_IPV4,
### HEUSER, HEKEY, HETUNNEL,
### HESERVER4END, HESERVER6END and HECLIENT6END

#MYIF="en1" # en1 = Airport, en0 = Ethernet
MYIF=`netstat -f inet -r | grep default | tr -s ' ' | cut -d ' ' -f 6 | sed -n 1p` # autodetect

DEVNAME='gif0'

LOCAL_IPV4=`ifconfig $MYIF |grep -E 'inet.[0-9]' | grep -v '127.0.0.1' | awk '{ print $2}'`
EXTERNAL_IPV4=`curl -s "http://ipv4.whatsmyip.reliable-ict.de/"`

HEUSER='your.username'     # The username you use to login at tunnelbroker.net
HEKEY='32f325019357278d'   # This 'Update Key' can be found on the 'Advanced' tab of the tunnel details page.
HETUNNEL='12056'           # The 'Tunnel ID' from the tab IPv6 tunnel on the tunnel details page.

### other settings from the website (the tunnel settings):
HESERVER4END='216.66.80.30'
HESERVER6END=2001:470:1f0a:3333::1
HECLIENT6END=2001:470:1f0a:3333::2

HE64PREFIX=2001:470:1f0b:3333::
MYCUSTOMADDRESS=${HE64PREFIX}1:1

#######################################################################
####  Starting the actual script

echo "Please enter the 'sudo' password. This is password of your user account on this Mac. It is needed to set up the IPv6 tunnel."
sudo echo "Gained superuser permissions"
if [ $? == 1 ]; then echo "Sorry! You need to provide your password in order to set up the tunnel."; exit 1; fi

echo "Remove previous tunnel (ignore any errors)"
sudo ifconfig $DEVNAME down
sudo ifconfig $DEVNAME inet6 $MYCUSTOMADDRESS prefixlen 128 delete
sudo ifconfig $DEVNAME inet6 $HECLIENT6END $HESERVER6END prefixlen 128 delete
sudo route delete -inet6 default -interface $DEVNAME
sudo ifconfig $DEVNAME deletetunnel

echo "Removed the previous tunnel. Will continue to set up the tunnel in 5 seconds..."
for i in {5..1}; do echo "$i"; sleep 1; done

echo "Updating your IPv4 tunnel endpoint setting on the Hurricane Electric Website."
# And instead of determining the external IPv4 address on your own, you can also set the param ip to AUTO.
curl -k -s "https://ipv4.tunnelbroker.net/nic/update?username=$HEUSER&password=$HEKEY&hostname=$HETUNNEL&myip=$EXTERNAL_IPV4"
# One more API of the tunnelbroker.net site is: https://username:[email protected]/tunnelInfo.php[?tid=tunnel_id] which returns an XML output

sleep 1

echo "Setting up the tunnel with the new settings now ."
sudo ifconfig $DEVNAME create
sudo ifconfig $DEVNAME tunnel $LOCAL_IPV4 $HESERVER4END
sudo ifconfig $DEVNAME inet6 $MYCUSTOMADDRESS prefixlen 128
sudo ifconfig $DEVNAME inet6 $HECLIENT6END $HESERVER6END prefixlen 128
sudo route -n add -inet6 default $HECLIENT6END

# We now provide the user with information if the tunnel has ben set up successfully:
sleep 1
echo "The external IPv6 is now set to `curl -s 'http://ipv6.whatsmyip.reliable-ict.de/'`."
echo "The external IP of your default connection is now set to `curl -s 'http://whatsmyip.reliable-ict.de/'`."

Not all systems are using ifconfig anymore, so it should be changed to use general ip commands to do the same thing.

Not all systems are using ifconfig anymore, so it should be changed to use general ip commands to do the same thing.

This is for macOS, macOS is BSD which does not have the ip utilities.

How to check if everything is correct?

Background

In order to check whether everything is correct we need to know what to check. Doing so requires knowing what each of the configuration commands does. Before getting into that, let's review some concepts we'll need...

What are we really doing?

We are creating a 6in4 tunnel that will basically carry IPv6 datagrams as the payloads of regular IPv4 datagrams by means of a procedure called encapsulation. Check this diagram for more info. The previous link points to an RFC which can seen kind of daunting to read, but it's the most accurate information you can possibly get... In any case, we need a way of encapsulating IPv6 datagrams into IPv4 ones. One of the procedures we can use is leverage the interface model provided by tools like ifconfig (itself a part of the net-tools suite). We'll then configure an interface our tunnel will be supported on (namely, a tunnel interface if you want). This is exactly what the script automatizes.

Why all the trouble?

If your ISP doesn't provide direct access to the IPv6 internet we still need to go through a bit of IPv4 infrastructure before reaching the IPv6 internet... When using the tunnel this is what's roughly going on behind the scenes:

1. Our IPv6 capable program (say, ping6) generates an IPv6 datagram.
2. The datagram is routed through the tunnel interface.
3. When traversing the tunnel interface, out IPv6 datagram will be encapsulated into an IPv4 datagram.
4. This IPv4 datagram is sent to Hurricane Electric's tunnel endpoint over the ISPs regular IPv4 infrastructure.
5. Hurricane Electric's endpoint extracts the IPv6 datagram contained within the IPv4 datagram.
6. Hurricane Electric's endpoint routes the extracted IPv6 datagram through the IPv6 internet it has access to.

All this process means that the original program really thinks it's communicating directly with the IPv6 internet: the path over IPv4 is transparent to the application. If the ISP provided direct access to the IPv6 internet we wouldn't need all these extra steps...

Variable expansion

Note that a dollar sign ($) prepended to a name expands that variable name, that is, it'll replace the variable name with its real value. Notice how on line 22 we define DEVNAME='gif0'. This implies that wherever we find $DEVNAME it'll be equivalent to gif0. The same goes for the rest of variables such as LOCAL_IPV4 and HERSERVER4END. Note that "outside the script" these variables might not be defined. You'll then need to manually substitute the variable name with its value yourself, i.e. write gif0 where you find $DEVNAME and so on.

Command breakdown

1. ifconfig $DEVNAME create: This command creates the device we'll implement the 6in4 tunnel on. We can run ifconfig $DEVNAME to make sure a device named $DEVNAME exists. As $DEVNAME is equivalent to gif0 we can also run ifconfig gif0 and we should get the exact same output. If ifconfig complains, then the gif0 device might not be present...

2. ifconfig gif0 tunnel $LOCAL_IPV4 $HESERVER4END: This command sets the IPv4 addresses for each of the tunnel's endpoints. These are needed for the path traversed over IPv4 through our ISP's network. We wouldn't know where to send the IPv4 datagram containing the encapsulated IPv6 datagram otherwise... If you run ifconfig $DEVNAME again you'll see a line resembling tunnel inet $LOCAL_IPV4 --> $HESERVER4END. This shows that the addresses are correctly configured.

3. ifconfig $DEVNAME inet6 $MYCUSTOMADDRESS prefixlen 128: This command adds an IPv6 interface to the device at hand. We can also check whether it was correctly configured by running ifconfig $DEVNAME.

4. ifconfig $DEVNAME inet6 $HECLIENT6END $HESERVER6END prefixlen 128: Just like with IPv4, this configures the IPv6 addresses for both tunnel endpoints. This shows itself as a line like inet6 $HECLIENT6END --> $HESERVER6END prefixlen 128 in the output of ifconfig $DEVNAME.

5. route -n add -inet6 default $HESERVER6END: This adds a default route to the IPv6 routing table (which is, independent of the IPv4 routing table) so that all the IPv6 traffic is forced through the tunnel interface. We can check whether the rule was instantiated with netstat -f inet6 -rn. This will show the routing table for the IPv6 family. We need to look for a line resembling default $HESERVER6END UGSc $DEVNAME (note some whitespace has been trimmed). having this line means that all the traffic is indeed being routed through the tunnel.

Testing it out

You can then use any IPv6 capable tool to check your connectivity. An easy candidate is ping6, which acts like good ol' ping except it uses IPv6 at the network level. Executing ping6 www.google.com should begin showing replies right away.

You can also try to check whether the Kame Project site displays a "dancing kame" (i.e. dancing turtle) when you manually introduce the IPv6 address.. If it does, it means your IPv6 tunnel is up and running! Please note that to manually navigate to an IPv6 site you need to enclose the address in brackets ([]). The link for the IPv6 kame site would then be http://[2001:200:dff:fff1:216:3eff:feb1:44d7]. You can get this link yourself if you make a DNS lookup for a type AAAA record: dig -t AAAA www.kame.net, should you not trust our address 😉.

Another thing to keep into account is that even though your tunnel might be up and running, your OS or browser might still be resolving hostnames to IPv4 addresses (i.e. type A DNS records instead of AAAA). This is something you might need to look into, but if you introduce IPv6 addresses manually you should be able to browse the IPv6 internet unhindered.

Hope the explanation helped 😼!