Connecting to an IPv6 Tunnel Broker from behind an ISA 2004 Firewall.

 

By Daniele Muscetta - daniele@muscetta.com

March, 21st  2005

 

 

 

 

 

I am no IPv6 expert, but I’ve been fascinated by the idea of IPv6 for quite an amount of time now. There will still pass a long time before we will use a native IPv6 Internet, but for the time being there is already a lot of experimentation out there, and there’s quite an amount of sites and services on the IPv6 Network already.

 

The IPv6 Internet runs in parallel as the IPv4 one, with different points of contacts, such as gateways and routers.

 

The experimental IPv6 network is called the 6bone (http://www.6bone.net/).

You can even request your IPv6 network and have it assigned.

This will be a valid routable IPv6 addressing, valid as long as the 6bone experimentation will stay up and running.

 

 

 

 

Of course buying *real* (native) connectivity, even if is already possible in some countries, is still expensive. Instead, most of the IPv6 connectivity these days is achieved through tunneling of IPv6 INTO IPv4 packets.

These tunnels interconnect the various IPv6 islands over the public, dear old IPv4 Internet.

This tunnels use different technologies, but one of the most common is the use of IPv4 protocol 41 (also called "Proto-41" in short).
The whole idea behind proto-41 is to encapsulate IPv6 into IPv4 packets.

 

But how do we set up such a tunnel if we want to experiment with IPv6 out of the home-lab and onto the real world ?

To use a tunnel, we need to go to a tunnel broker: a company that has native access to the 6bone, and has set up public gateways that is used as tunnel endpoint. One such service (one of the easiest to use) is www.freenet6.net .

It provides with simple to setup, even anonymous tunnels.

If you register for an account though, you can make use of a more reliable tunnel endpoint than the anonymous one, and even request a /48 or /64 block of addresses.

In our example we will use an already set-up account at freenet6 to get a single IPv6 address.

 

 

In our test case we have a Windows XP SP2 machine BEHIND an ISA Server 2004.

We want to be able to set up an IPv6 tunnel on the Windows XP machine, so let it tunnel through the ISA server and get a public IPv6 address.

We could have other scenarios, including the one of having the ISA server being the endpoint for the tunnel, and acting as a router.
This would be achievable even though ISA is at this time v4 only, because the IPv6 stack, on the other end, has full routing features built in. Thus a Windows machine is capable of being an IPv6 router.
Since the other setups are a bit trickier to get right, we will explore those other possibilities in further articles.For now we will get the basic functionality working.Please write me if you are interested in a follow up with other methods/scenarios, and I'll see what I can do (in my spare time, which is not much) to write those too.

 

 

First of all you need to enable/install IPv6 on the WindowsXP machine.

This is accomplished by typing in a CMD window the command

 

ipv6 install

 

 

 

After this operation the IPv6 stack will be installed on the machine, you will be able to see it on the list of protocols bound to the network interface, and you will automatically get link-local IPv6 addresses (starting with fe80::). These addresses aren’t routable for on the public Internet, but are used for local communications only (on a intranet which is not connected to anything); even if not 100% correct, we can compare them to APIPA addresses (169.254.0.0/16) that Windows automatically sets up when it doesn’t find a DHCP server.

 

This just wants to be a step-by-step minimal guide, so we won’t go into further details.

If you want to understand more of the theory, I suggest you to read the documents linked in the reference/biography section at the end of this article.

 

 

The second things to do is to install the freenet6 client (called the TSP Client).

There are pretty good instructions on how to do this on the producer’s site.

It consists of installing an application, and the TAP Tunnel Driver tunv6.sys.

Once installed, the driver will show up as a new network connection:

 

 

(in this picture we already RENAMED it from “Local Area Connection #2” to a more straightforward name).

 

We find it appropriate to change the bindings on this new interface.

In fact by default everything that’s bound to the NIC gets also bound to the TUN adapter, but this is not what we want.

First of all, we will use this for IPv6, so for INSIDE the tunnel we can disable IPv4; if we don’t, once the tunnel is established, the machine will try to get an IPv4 address from DHCP, which won’t work, and which is not necessary – it just wastes bandwidth.

Second, we don’t want to offer any sharing of resources over this connection.

 

Even if we are behind the ISA, we will open a Tunnel through it, letting our Windows XP client practically exposed to the IPv6 internet.

Then the "endpoint" will see/receive ALL IPv6 traffic inside the tunnel, it won't be able to filter it per destination port, for example.

We will be exposing all IPv6 functionality that can be exposed over protocol-41 as ISA has no understanding of the protocol.

 

 

So for this reason we want to harden the connection.

Also for this reason, we use Windows XP Service Pack 2 as a client. In fact, the built-in Windows Firewall of XP Service Pack 2, for those who did not hear the great new, is IPv6 aware. And NOT ONLY is it aware, it does more: it automatically enforces the same firewall policy both to IPv4 and to IPv6 interface addresses.

Which means this way we will be able to surf out, but we can adjust the firewall to block everything inbound over this tunnel.

 

 

After having set up the tsp client, we should edit its configuration file, tspc.conf (by default is in the directory where the client is installed – c:\program files\tsp-client). It is self-explanatory, well-commented, documented, and there is a sample file.

If you want to use an anonymous tunnel you can leave it with the default values.

But the anonymous tunnels are somehow not reliable, and sometimes it is even difficult to connect since there are too many users.

 

I highly suggest you to create an account on freenet6. You can specify your username and your email, and you will be sent the password to that email (a complex, 10-character password is generated).

 

When you got your username and the password, you can change the following three things in tspc.conf: the username, the password, and the server/tunnel endpoint to connect to:

 

 

userid = anonymous (insert username)

passwd =p@sSw0rd (insert password)

 

comment the line

 

server= anon.freenet6.net

 

And uncomment

 

server= broker.freenet6.net

 

 

Save the file, and at this point we have completed the configuration of the tsp client.

 

 

We can open a CMD, go to the c:\program files\tsp-client directory and type the command

 

tspc vvv

(-vvv uses the maximum possible verbose logging to tell us how the thing is working or not working).

 

 

Since we are behind the ISA, by default this kind of traffic won’t be allowed, s we will get something like this:

 

 

 

C:\Program Files\tsp-client>tspc -vvv

tspc - Tunnel Setup Protocol Client v2.1.1

Initializing (use -h for help)

 

 

Connecting to server with reliable udp

Using TSP protocol version 2.0.0

Establishing connection with tunnel broker...

Getting capabilities from server

No RUDP reply

No RUDP reply

No RUDP reply

tspGetCapabilities error 2: SOCKET_ERROR

if you are using udp, there is probably no udp listener at broker.freenet6.net

Reliable udp connection failed, fallback to tcp and V6V4

 

Connecting to server with tcp

Using TSP protocol version 2.0.0

Establishing connection with tunnel broker...

Unable to establish connection with broker.freenet6.net

 

All transports failed, quitting

 

Error is 2: SOCKET_ERROR

TSP session done

 

 

 

 

Which is quite self-explanatory. Firewall is closed, it can’t work.

 

 

There’s only a couple of things we need to enable in ISA to let this tunnel work:

 

First of all, we need to enable TCP port 3653 (check out http://www.hexago.com/index.php?pgID=41).

Just for clarity, we will say that this port does NOT have anything at all to do with IPv6.

This is just the port where freenet6’s tunnel broker’s webservice listens.

There’s nothing important or IPv6 specific about this, it is just that they chose to run their webservice on that port. But since we use that webservice, we need to reach it.

 

I am using TCP in this example.

If you use UDP (useful for NAT Traversal, see later on) the same port number has to be open for UDP instead.

 

With this one port open we will connect to the Tunnel broker, we will get all the necessary parameters to establish the tunnel, but the tunnel will then try to use a protocol that’s not allowed by default through the firewall, and fail.

 

What we have to enable for this to work, is our tunneling mechanism: as we already said, IPv6-over-IPv4 tunnels use IPv4 protocol number 41.

While on ISA2000 it wouldn’t have been possible to configure this protocol, in ISA2004 this is now possible:

 

 

 

 

 

 

 

Depending on how our access policy is, we might need to explicitly permit this protocol from the internal client.

In case that we allow “All traffic” then it won’t be needed to add this protocol to the Access Rule, as it will be already included.

 

Keep in mind the following when using this newly defined protocol:

 

ISA Server supports RAW IP protocols (so new protocols defined only indicating the protocol number, as in the example above) but with some limitations.

The limitation with RAW IP protocols comes from the fact that ISA has no additional understanding of the protocol end points (like ports in TCP/UDP).

This leads to the fact that, when passing through NAT, only one client that is using a certain RAW IP protocol can get to a specific server.

 

For example:

Client1 à NAT à Server 10.0.0.1 over proto 41 ß Success

Client2 à NAT à Server 10.0.0.1 over proto 41 ß Duplicate connection element error

 

 

So now, keeping this in mind, and using only one client (our XP machine) we can try our tunnel, and it should work:

 

 

 

C:\Program Files\tsp-client>tspc -vvv

tspc - Tunnel Setup Protocol Client v2.1.1

Initializing (use -h for help)

 

 

Connecting to server with reliable udp

Using TSP protocol version 2.0.0

Establishing connection with tunnel broker...

Getting capabilities from server

Connection established

Authenticating username

Using authentification mecanism DIGEST-MD5

Authentication success

Asking for a tunnel

sent : Content-length: 204

<tunnel action="create" type="v6anyv4" proxy="no">

 <client>

  <address type="ipv4">192.168.0.181</address>

<keepalive interval="30"><address type="ipv6">::</address></keepalive> </client>

</tunnel>

 

recv :

200 Success

<tunnel action="info" type="v6udpv4" lifetime="604800">

  <server>

    <address type="ipv4">206.123.31.116</address>

    <address type="ipv6">2001:05c0:8fff:fffe:0000:0000:0000:1dc2</address>

  </server>

  <client>

    <address type="ipv4">63.91.192.213</address>

    <address type="ipv6">2001:05c0:8fff:fffe:0000:0000:0000:1dc3</address>

    <address type="ns">username.broker.freenet6.net</address>

    <keepalive interval="30">

      <address type="ipv6">2001:05c0:8fff:fffe:0000:0000:0000:1dc2</address>

    </keepalive>

  </client>

</tunnel>

 

 

Processing response from server

sent : Content-length: 35

<tunnel action="accept"></tunnel>

 

Got tunnel parameters from server, setting up local tunnel

keepalive interval: 30

 

tspSetupInterface beginning

TSP_TUNNEL_MODE=v6udpv4

TSP_HOST_TYPE=host

TSP_TUNNEL_INTERFACE=FreeNet6 Tunnel

TSP_HOME_INTERFACE=

TSP_CLIENT_ADDRESS_IPV4=63.91.192.213

TSP_CLIENT_ADDRESS_IPV6=2001:05c0:8fff:fffe:0000:0000:0000:1dc3

TSP_SERVER_ADDRESS_IPV4=206.123.31.116

TSP_SERVER_ADDRESS_IPV6=2001:05c0:8fff:fffe:0000:0000:0000:1dc2

TSP_TUNNEL_PREFIXLEN=128

TSP_VERBOSE=3

TSP_HOME_DIR=C:\Program Files\tsp-client

Executing configuration script: "C:\Program Files\tsp-client\template\windows.bat"

04/03/2005

07:03 PM

Testing IPv6 presence

Testing Windows NT version

IPv4 tunnel server address configured : 206.123.31.116

Resetting all the interfaces and routes

Ok.

 

Configuring for V6UDPV4 (NAT traversal)

Ok.

 

Setting MTU to 1280 on tunnel interface "FreeNet6 Tunnel"

Ok.

 

Ok.

 

Ok.

 

Success ! Now, you're ready to use IPv6 connectivity to Internet IPv6

Your host is configured to use this IPv6 address : 2001:05c0:8fff:fffe:0000:0000:0000:1dc3

End of the script

Script completed sucessfully

Your IPv6 address is 2001:05c0:8fff:fffe:0000:0000:0000:1dc3

keepalive initialized with 2001:05c0:8fff:fffe:0000:0000:0000:1dc2 as a peer, max KA value of 30

 

 

 

 

 

You can see some of the checks (authentication, and the passing of parameters from server to client) being basically performed over HTTP (even if on port 3653) with the use of XML tags – this is a web service that is used to configure the freenet6 client.After authentication to this webservice, the tunnel will be up, and the machine will have a globally routable IPv6 address.

 

You can now see the Tunnel interface being up:

 

 

 

You can now test your IPv6 connectivity just using a browser and connecting to some site that you know being reachable on the IPv6 Internet.

This is now very easy, as most pieces of windows are now IPv6 aware.

This wasn’t the case just a couple of years ago, but now it is.

So just open Internet Explorer and surf to those sites.

 

If you don’t know any site, I’ll tell you some of them.  To start off with, head on this other tunnel broker’s test page:

 

IPv6 Calc (IPv6 connection revealer)

http://www.sixxs.net/tools/ipv6calc/

 

it will tell you some details about your connection, address, browser, etc.

 

Another funny place to visit is the home of the BSD IPv6 stack: www.kame.net

This is funny, as there is an image of the KAME turtle.

If you connect in IPv4 the image is static, like this:

 

 

While if you connect over IPv6, you’ll see a “dancing” KAME:

 

 

(Note: it has always looked like being rather more “swimming” than “dancing” to me, but that might be just my perception…. After all I have never seen a dancing turtle anywhere else…:-)).

 

 

 

 

You can also try http://ipv6.research.microsoft.com

 

There are a lot more sites.

One thing to note is that you will now seamlessly navigate on both the IPv4 internet (thorugh your normal NIC) and on the IPv6 one (through the tunnel) from the XP machine.

Enjoy!

 

 

 

When you hit CTRL+C in the DOS box, the batch terminates and the tunnel goes down, as you can see in the following screenshot:

 

 

 

 

NOTE: IPv6 behind a NAT (on FreeBSD)

 

http://ezine.daemonnews.org/200009/ipv6.html

 

I bumped into this article, while researching for writing the one you're reading. This stuff is pretty much not an issue anymore these days – it was some years ago, but now not anymore.

Or better, it can still be, if you use a NAT device which is not quite modern.

Specifically I had a lot of issues with some cheap DSL routers which are doing NAT, but that only support PORT MAPPING, as they could not really understand PROTO-41.

This kind of devices is the same kind of thing that has problems with IPSec, anyway.

 

For this need, pretty much like we have implemented Nat-Traversal for IPSec over UDP in XP, there’s an option in freenet6’s configuration to usev6udpv4”:

 

[…]

On June 16th 2004, Freenet6 started to offer an innovative new feature called NAT traversal, allowing people behind NAT devices to get IPv6 connectivity.

[…]

 

 

 

Biliography / Reference / Further reading material:

 

 

 

Disclaimer

Everything here is "as is", my words only, not the official word of Microsoft, nothing here supported by PSS, etc. I am not affiliated in any way to freenet6 nor to any of the other organizations (6bone, kame, etc) mentioned here. I just tried their service and I found them good, that's why I use them. This is published on my PERSONAL site because this is a *personal* test / procedure - nothing here has been scrutinized, checked, corrected nor approved by anybody at Microsoft, and thus DOES NOT HAVE TO BE CONSIDERED OFFICIAL DOCUMENTATION for the product mentioned. It only represents the description of some of my TESTs and, since they worked for me, I wanted to share them.