Permalink
Browse files

Updated the tunnel README to include additional details surrounding a…

…ny issues I had + refactored things a bit to fit the changes
  • Loading branch information...
1 parent 1e3d50c commit 1ee752c7ed7f5dbaca55c6e087df59a3457bb3f4 @prurigro prurigro committed Feb 8, 2013
Showing with 54 additions and 33 deletions.
  1. +54 −33 tunnel/README.md
View
@@ -52,7 +52,7 @@ section of the `IpTunnel` block in your cjdroute.conf like this:
"d5d0wu0usrkuThisIsJustAnExampleThisIsFake63uqlnk2kb0.k"
]
-Then restart cjdns and you should see it add IP addresses to your TUN device by running
+Then restart cjdns and after a few moments you should see it add IP addresses to your TUN device by running
`ifconfig` for example:
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
@@ -70,15 +70,15 @@ it works.
-## Running a Gate
+## Running a gateway
-Running your own gateway is not automated so you will want to implement some scripts to
+Running your own gateway is not automated, so you will want to implement some scripts to
set the addresses for you. Lets imagine your ISP has given you the IPv6 prefix
`1111:1111:1111:1111::/64` and your ISP's router is `1111:1111:1111:1111::1`. Your ethernet
card is probably set to `1111:1111:1111:1111::2` so you'll begin allocating above that.
First you will have to reserve one address (eg: `1111:1111:1111:1111::3`) for your `tun0`
-device's address then each client can have an address so the first client will be issued
-`1111:1111:1111:1111::4`.
+device's address, then each client can have an address, so the first client will be issued
+`1111:1111:1111:1111::4`, the second `1111:1111:1111:1111::5` and so on.
First edit your cjdroute.conf and add the clients who will be connecting to your gate.
It's always a good idea to add some identification with the connect block so you know who
@@ -93,17 +93,17 @@ it is for later.
}
]
-Now you start up cjdroute. The IP address for the TUN device will *not* be set automatically
-so you must set that next.
+When you start cjdroute, the IP address for the TUN device will *not* be set automatically,
+so you must set that next with the following command:
ip -6 addr add dev tun0 1111:1111:1111:1111::3
-Now your device has an address, your client can probably ping `1111:1111:1111:1111::3` but
-cannot reach the rest of the world. To make this possible, you will need to add a static
-route to your ISP's address: `1111:1111:1111:1111::1`, making it route over the ethernet
-device, then add a static route making the rest of your /64 route down the TUN device.
-Finally you will need a default route via your ISP's address so outgoing IPv6 packets are
-forwarded correctly.
+Now that your tun device has an address, your client may or may not be able to connect and
+ping `1111:1111:1111:1111::3`, but it definitely won't be able to reach the rest of the
+world until you add a static route to your ISP's router's address: `1111:1111:1111:1111::1`.
+This will make it route over the ethernet device and add a static route to allow the rest of
+your /64 to route down the TUN device. Once you're finished, you'll want to set a default
+route via your ISP's router's address so outgoing IPv6 packets are forwarded correctly.
ip -6 route add dev eth0 1111:1111:1111:1111::1
ip -6 route add dev tun0 1111:1111:1111:1111::0/64
@@ -119,33 +119,54 @@ and to make it permanent, edit your `/etc/sysctl.conf` file and *uncomment* the
-Now you should be ready for action!
+Connect the client to the gateway using cjdns and wait a few moments until you've obtained the ipv6
+address associated with the tunnel. Now, test the connection by attempting to ping the ipv6 address
+associated with the gateway on the tunnel, and if this succeeds you can try to ping an external ipv6
+address like `ipv6.google.com` too if you're expecting internet traffic to be routed through.
+
+Now if all went well your job is done, but if the connection isn't working yet you should continue on to
+the next section and try to figure out why.
## It doesn't work
-Start pinging from a client to something like `ipv6.google.com` and then on the server,
-use tcpdump to look for the packets which should be flowing. First tcpdump the TUN device and
-make sure the packets get that far, then tcpdump the eth0 device, if they're not making it,
-check your routes (`ip -6 route`) and make sure you don't have any iptables rules against
-forwarding.
-
-If you see packets going out the ethernet device and then strange *neighbor solicitation* packets
-returning, your ISP is dropping the replies! On some systems the ISP's equipment won't route
-return traffic back *even though* those addresses are allocated to you. This is because IPv6
-uses something called NDP or Neighbor Discovery Protocol and the ISP is asking for neighbors
-and unless it gets a response from your server, it will not send traffic to it. In order to
-work around this problem, we'll use a little application called `npd6` which gives NDP the
-answer it's looking for. If you have a recent version of debian on your machine, you might
-be able to install the package here: http://code.google.com/p/npd6/downloads/list
-otherwise you'll have to build it which is not difficult.
+First, check to make sure you don't have any iptables rules against forwarding or ones that might be
+blocking your connection in any way. You should also make sure a processes called 'radvd' isn't running
+(at least to rule out as a cause until you have things working) since it seems to be capable of causing
+some routing issues.
+
+Now ensure the client is still connected to the gateway through cjdns, and that it still has an ipv6
+address associated with the tunnel, then try pinging the gateway or an internet ipv6 address again with
+the client. On the gateway, run `tcpdump -n -i tun0` to see if any packets get as far as the tun device, and
+if nothing scrolls with the ipv6 associated with your client's on the tunnel, you should check your routes
+to make sure they're correct by running `ip -6 route`. The output should include four lines that look similar
+to the ones below (take special note of which device is associated with each line).
+
+1111:1111:1111:1111:1111:1111:1111:1 dev eth0 metric 1024
+1111:1111:1111:1111:1111:1111:1111:3 dev tun0 proto kernel metric 256
+1111:1111:1111:1111:1111:1111:1111:0/64 dev tun0 metric 1024
+default via 1111:1111:1111:1111:1111:1111:1111:1 dev eth0 metric 1024
+
+If your routes are correct and things still aren't working, continue to let the ping process run on the client
+and run `tcpdump -n -i eth0 icmp6` on the gateway to check the traffic flowing through its ethernet device.
+Look for any connections to or from the ipv6 address associated with your client on the tunnel, and if you see
+any with strange messages about "neighbor solicitation" or "neighbor advertisement", the problem is that your
+ISP's equipment is dropping replies instead of routing return traffic despite the addresses in use being
+allocated to you. This problem exists because of something called NDP (Neighbor Discovery Protocol), in which a
+request for 'neighbours' is made, and traffic isn't allowed to be sent back unless the ISP receives a response.
+Thankfully, there is a workaround available that involves running a daemon called `npd6`, which provides a
+response that satisfies NDP. Install npd6 through your distro's package management system if it's available,
+(recent debian based distrobutions may be able to install the package located here:
+http://code.google.com/p/npd6/downloads/list) otherwise you'll have to download and build it yourself by doing
+the following:
wget http://npd6.googlecode.com/files/npd6-1.0.0.tar.gz
tar -xf ./npd-1.0.0.tar.gz
cd npd6-1.0.0/
make && sudo make install
-Once this is built, you will have to create a `/etc/ndp6.conf` file which announces your
-prefix, start from the example file provided with the source and change the prefix to
-`1111:1111:1111:1111::2` because you're announcing `1111:1111:1111:1111::2` and above
-but not `1111:1111:1111:1111::1` which is your ISP's address.
+Once this is built, copy `npd6-1.0.0/etc/npd6.conf.sample` to `/etc/ndp6.conf`, and change the prefix to
+`1111:1111:1111:1111:0000:0000:0000:0002/64` (2 because you're announcing `1111:1111:1111:1111::2` and higher,
+but not `1111:1111:1111:1111::1` which belongs to your ISP's router). Note that in this particular instance,
+you can't ignore 0s when writing out your ipv6 or npd6 will complain when you attempt to run it. If npd6 fails
+to start, try running `npd6 -l npd6.log` to write a log in the local directory.

0 comments on commit 1ee752c

Please sign in to comment.