Can't get the tunnel working, please help

dkoopman · April 13, 2008, 03:51:26 AM

I hope you'll excuse me, I'm sure I'm just missing something simple. I can't get my tunnel to work. I'm brand new to IPv6, my network admin skills are minimal, linux admin skills are ok. I have a dedicated hosting server (bare metal), and want to run a web site on IPv4 and IPv6, simultaneously. I assume I can do this with a single IPv4 address. I'm a little confused that I have a routed /64, because all I need is a single IP.

These questions are going to seem really dumb, but I hope you'll entertain them. I'm really struggling with this, and having a hard time finding anything dumbed down enough for me to get.

Given my tunnel details:
Server IPv4 address:    72.52.104.74
Server IPv6 address:    2001:470:1f04:3f2::1/64
Client IPv4 address:    [Update] 208.109.223.133
Client IPv6 address:    2001:470:1f04:3f2::2/64
Routed /48:    none
Routed /64:    2001:470:1f05:3f2::/64

Is 2001:470:1f04:3f2::1 the IP that routes to my server?

If I just want a single IPv6 IP to tunnel to my server, what IP do I use? The Server IPv6 address, or make one up from the "Routed /64"?

How do I bind a /128 to my server from my routed /64?

I ran the configuration script on my server, and then tried ping6 on a few ipv6 hostnames, but it's not working. So, I'm not getting out to the IPv6 world. I'm going to dump everything I can, I hope you can help me. I feel like I'm missing something.

IP: 208.109.223.133
OS: CentOS 5
Firewall: none

I setup with this script:

Code Select

ifconfig sit0 up
ifconfig sit0 inet6 tunnel ::72.52.104.74
ifconfig sit1 up
ifconfig sit1 inet6 add 2001:470:1f04:3f2::2/64
route -A inet6 add ::/0 dev sit1

And now my ifconfig shows:

Code Select

# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:30:1B:43:50:2F
          inet addr:208.109.223.133  Bcast:208.109.223.255  Mask:255.255.255.0
          inet6 addr: fe80::230:1bff:fe43:502f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4486 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1574 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:396895 (387.5 KiB)  TX bytes:238388 (232.8 KiB)
          Interrupt:185

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:70 errors:0 dropped:0 overruns:0 frame:0
          TX packets:70 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:9933 (9.7 KiB)  TX bytes:9933 (9.7 KiB)

sit0      Link encap:IPv6-in-IPv4
          inet6 addr: ::208.109.223.133/96 Scope:Compat
          inet6 addr: ::127.0.0.1/96 Scope:Unknown
          UP RUNNING NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

sit1      Link encap:IPv6-in-IPv4
          inet6 addr: 2001:470:1f04:3f2::2/64 Scope:Global
          inet6 addr: fe80::d06d:df85/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:992 (992.0 b)

And I can tell it's not working by:

Code Select

# ping6 ipv6.google.com
PING ipv6.google.com(2001:4860:0:2001::68) 56 data bytes
From dkoopman-pt.tunnel.tserv3.fmt2.ipv6.he.net icmp_seq=2 Destination unreachable: Address unreachable
From dkoopman-pt.tunnel.tserv3.fmt2.ipv6.he.net icmp_seq=3 Destination unreachable: Address unreachable

--- ipv6.google.com ping statistics ---
5 packets transmitted, 0 received, +2 errors, 100% packet loss, time 3999ms

But, I can ping my own inside IPv6 IP:

Code Select

# ping6 2001:470:1f04:3f2::2
PING 2001:470:1f04:3f2::2(2001:470:1f04:3f2::2) 56 data bytes
64 bytes from 2001:470:1f04:3f2::2: icmp_seq=0 ttl=64 time=0.027 ms
64 bytes from 2001:470:1f04:3f2::2: icmp_seq=1 ttl=64 time=0.015 ms
64 bytes from 2001:470:1f04:3f2::2: icmp_seq=2 ttl=64 time=0.022 ms

--- 2001:470:1f04:3f2::2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.015/0.021/0.027/0.006 ms, pipe 2

but not my outside:

Code Select

# ping6 2001:470:1f04:3f2::1
PING 2001:470:1f04:3f2::1(2001:470:1f04:3f2::1) 56 data bytes
From 2001:470:1f04:3f2::2 icmp_seq=1 Destination unreachable: Address unreachable
From 2001:470:1f04:3f2::2 icmp_seq=2 Destination unreachable: Address unreachable

--- 2001:470:1f04:3f2::1 ping statistics ---
3 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1999ms

Here is my IPv6 route:

Code Select

# route -A inet6
Kernel IPv6 routing table
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
*/96                                        *                                       U     256    0        0 sit0
2001:470:1f04:3f2::/64                      *                                       U     256    4        0 sit1
fe80::/64                                   *                                       U     256    0        0 eth0
fe80::/64                                   *                                       U     256    0        0 sit1
*/0                                         *                                       U     1      0        0 sit1
::1/128                                     *                                       U     0      1        1 lo
localhost/128                               *                                       U     0      0        1 lo
ip-208-109-223-133.ip.secureserver.net/128  *                                       U     0      0        1 lo
dkoopman-pt.tunnel.tserv3.fmt2.ipv6.he.net/128 *                                       U     0      15       1 lo
fe80::d06d:df85/128                         *                                       U     0      0        1 lo
fe80::230:1bff:fe43:502f/128                *                                       U     0      0        1 lo
ff00::/8                                    *                                       U     256    0        0 eth0
ff00::/8                                    *                                       U     256    0        0 sit1

Nothing weird in ip6tables:

Code Select

# ip6tables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source              destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Let me know if you need anything else. I really hope I'm just skipping a step or something. I'd like to be able to get this to work.

Thanks in advance,
Dave.

snarked · April 13, 2008, 04:38:44 PM

I was able to ping your IPv4 address and HE's end of the IPv6 tunnel, but not your IPv6 end.

Quote
1 dkoopman.tunnel.tserv3.fmt2.ipv6.he.net (2001:470:1f04:3f2::1) 9.904 ms 9.851 ms 9.737 ms

There is ONE difference I noted between your sit1 interface and mine: I have my IPv4 address allocated to it but yours is missing. Therefore, add this:

Quoteifconfig sit1 208.109.223.133 up

It seems that you never tell your sit# devices what IPv4 address to use as the source of their encapsulated packets. Therefore, what you should have is:

Quoteifconfig sit0 208.109.223.133 up
ifconfig sit0 inet6 tunnel ::72.52.104.74
ifconfig sit1 208.109.223.133 up
ifconfig sit1 inet6 add 2001:470:1f04:3f2::2/64
route -A inet6 add ::/0 dev sit1

Instead of

Quoteroute -A inet6 add ::/0 dev sit1

try

Quoteroute -A inet6 add 2000::/3 dev sit1

and see if that makes a difference if the above didn't work.

dkoopman · April 14, 2008, 09:39:42 AM

Still not working. Thanks for trying. Here's the relevant data:

Quote[root@ip-208-109-223-133 ~]# ifconfig sit0 208.109.223.133 up
[root@ip-208-109-223-133 ~]# ifconfig sit0 inet6 tunnel ::72.52.104.74
[root@ip-208-109-223-133 ~]# ifconfig sit1 208.109.223.133 up
[root@ip-208-109-223-133 ~]# ifconfig sit1 inet6 add 2001:470:1f04:3f2::2/64
[root@ip-208-109-223-133 ~]# route -A inet6 add 2000::/3 dev sit1
[root@ip-208-109-223-133 ~]# ping6 ipv6.google.com
PING ipv6.google.com(2001:4860:0:2001::68) 56 data bytes
From dkoopman-pt.tunnel.tserv3.fmt2.ipv6.he.net icmp_seq=1 Destination unreachable: Address unreachable
From dkoopman-pt.tunnel.tserv3.fmt2.ipv6.he.net icmp_seq=4 Destination unreachable: Address unreachable
From dkoopman-pt.tunnel.tserv3.fmt2.ipv6.he.net icmp_seq=7 Destination unreachable: Address unreachable

--- ipv6.google.com ping statistics ---
8 packets transmitted, 0 received, +3 errors, 100% packet loss, time 7000ms

[root@ip-208-109-223-133 ~]# route -A inet6 add ::/0 dev sit1
[root@ip-208-109-223-133 ~]# ping6 ipv6.google.com
PING ipv6.google.com(2001:4860:0:2001::68) 56 data bytes
From dkoopman-pt.tunnel.tserv3.fmt2.ipv6.he.net icmp_seq=1 Destination unreachable: Address unreachable

--- ipv6.google.com ping statistics ---
3 packets transmitted, 0 received, +1 errors, 100% packet loss, time 2000ms

[root@ip-208-109-223-133 ~]# route -A inet6
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
*/96 * U 256 0 0 sit0
2001:470:1f04:3f2::/64 * U 256 0 0 sit1
2001:4860:0:2001::68/128 2001:4860:0:2001::68 UC 0 13 0 sit1
2000::/3 * U 1 0 0 sit1
fe80::/64 * U 256 0 0 eth0
fe80::/64 * U 256 0 0 sit1
*/0 * U 1 0 0 sit1
::1/128 * U 0 1 1 lo
localhost/128 * U 0 0 1 lo
ip-208-109-223-133.ip.secureserver.net/128 * U 0 0 1 lo
dkoopman-pt.tunnel.tserv3.fmt2.ipv6.he.net/128 * U 0 8 1 lo
fe80::d06d:df85/128 * U 0 0 1 lo
fe80::230:1bff:fe43:502f/128 * U 0 0 1 lo
ff00::/8 * U 256 0 0 eth0
ff00::/8 * U 256 0 0 sit1
[root@ip-208-109-223-133 ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:30:1B:43:50:2F
inet addr:208.109.223.133 Bcast:208.109.223.255 Mask:255.255.255.0
inet6 addr: fe80::230:1bff:fe43:502f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2145 errors:0 dropped:0 overruns:0 frame:0
TX packets:282 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:186303 (181.9 KiB) TX bytes:47393 (46.2 KiB)
Interrupt:185

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:41 errors:0 dropped:0 overruns:0 frame:0
TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:6365 (6.2 KiB) TX bytes:6365 (6.2 KiB)

sit0 Link encap:IPv6-in-IPv4
inet addr:208.109.223.133 Mask:255.255.255.0
inet6 addr: ::208.109.223.133/96 Scope:Compat
inet6 addr: ::127.0.0.1/96 Scope:Unknown
UP RUNNING NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

sit1 Link encap:IPv6-in-IPv4
inet addr:208.109.223.133 P-t-P:208.109.223.133 Mask:255.255.255.255
inet6 addr: 2001:470:1f04:3f2::2/64 Scope:Global
inet6 addr: fe80::d06d:df85/64 Scope:Link
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:1364 (1.3 KiB)

[root@ip-208-109-223-133 ~]#

broquea · April 14, 2008, 11:03:39 AM

1) disable iptables/ip6tables briefly, just to verify that neither are interfering.
2) make sure you have latest kernel installed, as there was an issue with one of the CentOS kernels released in Feb. that broke IPv6 routing for CentOS (or try another kernel installed on your system)

This looks like an issue with the linux system not handling the default route correctly. I experienced similar in Feb. with the borked kernel, however I was able to ping the broker's side of the tunnel (::1). Also check that your provider isn't doing any filtering before they hand off to you, and if they are, ask them to allow protocol41 through. I looked up the IP you've given as the endpoint and come up with GoDaddy having the entire /16. Perhaps they have something in front of your equipment?

dkoopman · April 14, 2008, 03:37:54 PM

Quote[root@ip-208-109-223-133 ~]# ip6tables
ip6tables ip6tables-restore ip6tables-save
[root@ip-208-109-223-133 ~]# ip6tables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@ip-208-109-223-133 ~]# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Looks clear. Kernel:

Quote[root@ip-208-109-223-133 ~]# uname -a
Linux ip-208-109-223-133.ip.secureserver.net 2.6.18-53.el5 #1 SMP Mon Nov 12 02:22:48 EST 2007 i686 i686 i386 GNU/Linux

There is an update to my kernel available, 2.6.18-53.1.14.el5, I just upgraded to that, rebooted. Now my kernel is:

Quote[root@ip-208-109-223-133 ~]# uname -a
Linux ip-208-109-223-133.ip.secureserver.net 2.6.18-53.1.14.el5 #1 SMP Wed Mar 5 11:36:49 EST 2008 i686 i686 i386 GNU/Linux

Replayed the setup script, same problem exists. Checking with Go Daddy on the "protocol41" thing.

dkoopman · April 14, 2008, 09:55:27 PM

Should I be able to "telnet 72.52.104.74 41"? How do I detect if protocol 41 is enabled on Go Daddy dedicated hosting network gear?

[dkoopman@ip-208-109-223-133 ~]$ telnet 72.52.104.74 41
Trying 72.52.104.74...
telnet: connect to address 72.52.104.74: Connection refused
telnet: Unable to connect to remote host: Connection refused

I'm guessing that port!=protocol.

I have an outstanding question with Go Daddy. They're looking into it and will get back to me.

broquea · April 14, 2008, 11:32:30 PM

Quote from: dkoopman on April 14, 2008, 09:55:27 PM
Should I be able to "telnet 72.52.104.74 41"? How do I detect if protocol 41 is enabled on Go Daddy dedicated hosting network gear?

[dkoopman@ip-208-109-223-133 ~]$ telnet 72.52.104.74 41
Trying 72.52.104.74...
telnet: connect to address 72.52.104.74: Connection refused
telnet: Unable to connect to remote host: Connection refused

I'm guessing that port!=protocol.

I have an outstanding question with Go Daddy. They're looking into it and will get back to me.

no, protocol 41 doesnt mean port 41: http://www.iana.org/assignments/protocol-numbers

dkoopman · April 15, 2008, 08:33:49 AM

I took a "tcpdump not tcp port 22 -s0 -w /tmp/tunnel.cap" dump, while running, performed "ping ipv6.google.com" followed by a "telnet ipv6.google.com 80" - both failed. I stopped the capture, took tunnel.cap back to my desktop, opened it in Wireshark, and sure enough, after each request, I get a "Destination unreachable (Communication administratively filtered)" from 208.109.219.251 (Go Daddy firewall). If I dig down into the "Internet Control Message Protocol", I find a listing that says "Protocol: IPv6 (0x29)". 29 hex = 41 dec. There is no doubt in my mind they are blocking protocol 41.

I've alerted Go Daddy to this, they're looking into it. This could work out good for all of Go Daddy dedicated hosting, assuming they confirm my finding and decide to open protocol 41 on their firewalls. They say I'm the first to have requested this. Hrm.

dkoopman · April 16, 2008, 02:16:03 PM

Update: Go Daddy has confirmed the problem is firewall. They will be making a change to their firewalls for dedicated hosting networks, but this needs to go through their change management procedures, and won't be deployed until sometime next week. I'll have to stand by in the meantime, but at least it's happening!

snarked · April 16, 2008, 09:17:06 PM

That surprises me. They won't allow IPv6 glue on domain registrations (I asked them this in February) but they will change things to permit IPv6-encapsulated packets to come into their hosting array...? Interesting. Good luck and hope it doesn't take too long for them to change.

eonesixfour · April 17, 2008, 12:44:25 AM

Quote from: snarked on April 16, 2008, 09:17:06 PM
That surprises me. They won't allow IPv6 glue on domain registrations (I asked them this in February)

Was this for all TLDs/ccTLDs?

snarked · April 17, 2008, 11:10:08 AM

Yes, it was a generic question without regard to a specific TLD. Sixxs.org has a page on their site indicating which domain registrars support IPv6 glue - very few do. I have a .org, a .info, and a .name, so it's possible that the answer addressed that, but only if they looked my account up before answering.

Considering that about half of the DNS root servers have IPv6 addresses, I consider this as very poor on the part of ALL registries that don't support it. GoDaddy is one of the largest and in the top 3 of count of domains registered through them.

eonesixfour · April 17, 2008, 07:18:36 PM

Quote from: snarked on April 17, 2008, 11:10:08 AM
Yes, it was a generic question without regard to a specific TLD. Sixxs.org has a page on their site indicating which domain registrars support IPv6 glue - very few do. I have a .org, a .info, and a .name, so it's possible that the answer addressed that, but only if they looked my account up before answering.

I don't have a .org with godaddy, but I initially emailed my registrar who said PIR didn't support it, so I than emailed PIR in the last month or so and they showed a complete lack of interest in allowing IPv6 glue records at all, so godaddy can hardly be blamed for that TLD in particular.

PIR is the registry for .org who boast about having board members involved with IPv6 deployment on their website etc, I half considered emailing those board members directly about the response I received.

As far as I'm aware .com, .net, .biz, .au all allow IPv6 glue records, although the .au registry never bothered to tell anyone not even their registrars when they enabled it which I thought a tad strange but anyways.

snarked · April 19, 2008, 05:54:28 PM

I found my response from GoDaddy regarding IPv6 glue. First, my question:

I am asking about IPv6 addresses for NAME SERVERS listed in domain registrations (i.e "required GLUE records" - that get listed at the TLD parent name servers). When will this be supported? It appears that you currently support only IPv4 glue records.

[They had first given me the generic response that their DNS supports AAAA records.]

Date: Tue, 04 Mar 2008 15:33:26 -0700
Subject: Update [Incident ID: 3489908] - Support Question

In response to your question, while it is likely that we will support this in the future, we cannot confirm an exact date as to when it will be supported. I apologize for any inconvenience.
- Ben A., Online Support Technician

dkoopman · April 29, 2008, 09:46:36 PM

Update: Protocol 41 allowed now on Go Daddy dedicated hosting servers. My tunnel is up! Thanks everyone for your support through this.

News:

Can't get the tunnel working, please help