I am trying to setup a sit ip tunnel to an ipv6 end point.
It appears that my 10.3 install does not recognize it.
I am able to setup a gre tunnel.
When I issue a modprobe ipv6 it returns nothing.
Do I have to install ‘sit’ tunnel type separately?
I currently use a tunnel broker software which does work ok so I know the relavent ipv6 modules must be installed.
I have to “modprobe sit” first on 10.3 to get a sit0 I can work with.
Who are you using for your tunnel broker? I’ve used Hurricane Electric for several years and my tunnel’s been solid. Just curious to know what others are using.
I was using Freenet (Hexago) but am moving to Hurricane Electric.
Freenet has a client which did all the work.
I will try modprobe sit to see what happens.
HE’s made some nice upgrades to their tunnel service the last several months, performance has improved quite a bit.
Keep us posted, glad to help if it’s still not workin’ for ya.
Your recommendation of using modprobe sit worked great, the tunnel is up.
I have been testing the tunnel by pinging to The KAME project
I get error messages saying that the destination is not reachable. In the body of the ping message it shows the following as ‘from’
starcastle.tunnel.tserv4.nyc4.ipv6.he.net
It looks like the routing is correct.
I am using my own copy of bind (on a different machine).
Any ideas?
I’ve posted my v6 address to you in PM. Let me know if you are able to ping me. It seems I can ping you but then you and I appear to be on the same v6 network anyway. I double-checked and I am able to get ipv6 connection to both IPv6: The Next Generation Internet! and The KAME project.
Maybe post the output of “ip -6 route”
Mine looks like this:
::/96 via :: dev sit0 metric 256 mtu 1480 advmss 1420 fragtimeout 64
2001:470:1f06:58::/64 via :: dev sit1 metric 256 mtu 1480 advmss 1420 fragtimeout 64
fe80::/64 dev eth0 metric 256 mtu 1500 advmss 1440 fragtimeout 64
fe80::/64 via :: dev sit1 metric 256 mtu 1480 advmss 1420 fragtimeout 64
ff00::/8 dev eth0 metric 256 mtu 1500 advmss 1440 fragtimeout 1
ff00::/8 dev sit1 metric 256 mtu 1480 advmss 1420 fragtimeout 1
default dev sit1 metric 1 mtu 1480 advmss 1420 fragtimeout 64
I decided to redo the entire setup in case I had made an error somewhere nd I guess I did.
Using the default HE script the tunnel came up right away and I can browse v6 locations.
Thanks for your help!
Radvd is working (at least it broadcasts addresses and other system pick up the correct attributes).
Cant browse the v6 addresses from other systems yet so I guess its more reading.
Glad the tunnel’s basically working, I might be able to help with the client routing too.
First thing that comes to mind is check /etc/sysctl and make sure “net.ipv6.conf.all.forwarding = 1”. Verify setting is in affect with “sysctl net.ipv6.conf.all.forwarding” or set it outright with “sysctl net.ipv6.conf.all.forwarding=1”
Other than that, make sure that both the client and the router are configured with one of the HE issued /64 addresses assigned to you, that the client can ping6 the router’s /64 addr, and that the default route on the client is set to use the router’s /64 addr… e.g.
ip -6 route add default via ipv6-addr-of-your-router
I rattled this off pretty quickly so might’ve missed something. Once it works we’ll port the working info into the saved settings.
radvd is broadcasting everything right as far as I can tell (the syctl… is set to 1 otherwise radvd wont start)
The default route shown in the other machines is that of the inet6 addr of the eth1 of the router box.
On a windows sys I have the default gateway also points to that box.
As a test I brought down the the HE tunnel and ran the Hexago tunnel broker on the same machine and the other machines on my lan were able to browse ipv6 sites ok.
oooo-k,
make sure ip6tables allows forwarded packets when the HE tunnel is active.
then, run tcpdump on your router’s sit device that has the v6 addr for your end of the tunnel…
tcpdump -i sit1 -n
…and ping6 from a client HE’s end of the v6 tunnel…
ping6 starcastle.tunnel.tserv4.nyc4.ipv6.he.net
… to see if the client packets are even traversing to/through your router to the sit device at all. (If you can’t even ping6 from a client to HE’s end of the tunnel then the problem is almost certainly local to the router. OTOH, you may need to “rebuild” your tunnel, which you can do through the HE web interface.)
If you can ping HE’s end of the tunnel, ping6 one step further out to MY v6 address which you should have in PM. If not, let me know and I’ll PM it to you again.
If that works, ping6 out to somebody like ipv6.google.com, The KAME project, or IPv6: The Next Generation Internet!.
At each step, watch tcpdump running on the router and see if it confirms two way traffic, one way, or none at all. When I first setup my v6 tunnel with HE tcpdump was my best friend. Once I got the tunnel working it worked flawlessly.
hth, let me know.
Thought of this later… a better order of events would be to first ping6 from your client to the router’s NEAR-side v6 addr. (whatever addr you assigned to it from your /64 allocation)
the second ping6 should be your router’s FAR-side v6 addr (your end of the actual v6 tunnel, should end with ::2)
If you can ping6 the router’s near-side, but not it’s far-side, then the disconnect is in the router itself.
If these work then proceed as above, keeping an eye on the tcpdump output.
food for thought, hth.
Your last post made me that a closer look at my eth1 setup:
eth1 Link encap:Ethernet HWaddr 00:0C:29:52:EC:20
inet addr:191.54.10.100 Bcast:191.54.10.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe52:ec20/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:82375 errors:0 dropped:0 overruns:0 frame:0
TX packets:84139 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5277509 (5.0 Mb) TX bytes:41732431 (39.7 Mb)
Interrupt:17 Base address:0x1400
I am missing something I think because I never assigned any /64 addr to my router (comes from using a utility to do all the work and not paying attention).
I tried adding several /64 addresses to no effect.
starcastle, sorry so long to get back to you, I’ve been traveling, hope you’re still around. Based on your last comment, I’m not sure if you mean you were unable to add a /64 address to your eth1 or if you did but that it didn’t seem to help. So, I’m going to walk through this step-by-step.
2001:470:1f06:541::2
ip -6 addr add 2001:470:1f07:1f58:191:54:10:100/64 dev eth1
.
3. on your client, use the same command but assign a different addr within your assigned /64.
example:
ip -6 addr add 2001:470:1f07:1f58:191:54:10:101/64 dev eth0
ip -6 route add default via 2001:470:1f07:1f58:191:54:10:100 dev eth0
during steps 7 - 9, use tcpdump as directed in my earlier post to monitor the sit device on your router that handles the v6 traffic
if any of these steps fail, let me know which step failed and the exact error you’re getting. It would help to see the ifconfig output from your router and from your client. It would also help to see the output of “ip -6 route” from both of them as well. If you want to PM that info that’s fine, totally up to you.
hth
After getting to the last step everything started working correctly from the client, didnt even have to assign an ipv6 address to the client (picked it up from the router adv)
Thanks for your help!
Now that outbound is working I am trying to get inbound traffic to work.
I have been working with HE but I think I am not understanding their terminology or vis a versa.
HE has a number of terms they are using:
Server IPv6 address (their end of the v6 tunnel)
Client IPv6 address (my end of the tunnel)
Routed /64 (the range I select for my clients)
They way I ‘think’ it works (I have an apache web server running on the same box as my end of the tunnel) is I should be able to browse to the Server IPv6 addr and the traffic should route through the tunnel.
If, on my lan, I browse to the client ipv6 addr I get my default page.
My end of the tunnel cannot be reached from the internet
He says that traffic to the Server IPv6 addr is routed down the tunnel.
Anyone have any ideas?