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

gistfile1.sh

#######################################################################
# Config start
#######################################################################
# Your Mac OS X account's password, needed for sudo
PASS="pass1234"

# en1 = Airport, en0 = Ethernet, would be nicer to detect the active interface automatically
MYIF="en1"


# Your Tunnel settings start here
# 1. get HEUSER hash from the website, "UserID"
# 2. get HEPASS hash: echo -n MyPass|md5
# 3. get HETUNNEL from the website, "Global Tunnel ID"
# 4. get other settings from the website

HEUSER=5d41402abc4b2a76b9719d911017c592
HEPASS=5d41402abc4b2a76b9719d911017c592
HETUNNEL=12123
HETHEIR4END=216.66.80.30
HEYOUR6END=2001:1234:1234:1234::2
HETHEIR6END=2001:1234:1234:1234::1

#######################################################################
# Config end
#######################################################################
NEW_IP=`curl -s "http://www.networksecuritytoolkit.org/nst/cgi-bin/ip.cgi"`

# if you need to use your public ip address, use LOCAL_IP=$NEW_IP instead
LOCAL_IP=`ifconfig $MYIF |grep -E 'inet.[0-9]' | grep -v '127.0.0.1' | awk '{ print $2}'`

#ignore any errors:
echo $PASS |sudo -S ifconfig gif0 deletetunnel
sudo ifconfig gif0 down
sudo ifconfig gif0 inet6 delete $(ifconfig gif0 | sed -nE 's/.*inet6 ([0-9a-f:]+) .*/\1/p')
sudo route delete -inet6 default -interface gif0

# update the tunnel
curl -k -s "https://ipv4.tunnelbroker.net/ipv4_end.php?ipv4b=$NEW_IP&pass=$HEPASS&user_id=$HEUSER&tunnel_id=$HETUNNEL"
echo " "

sleep 1
sudo ifconfig gif0 tunnel $LOCAL_IP $HETHEIR4END
sudo ifconfig gif0 inet6 $HEYOUR6END $HETHEIR6END prefixlen /128
sudo route -n add -inet6 default $HETHEIR6END

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 😼!