Forum - SixxS and 'Buntu 9.10: Pain-free and Easy-peasy (x64) :: SixXS

SixxS and 'Buntu 9.10: Pain-free and Easy-peasy (x64)

Shadow Hawkins on Monday, 16 November 2009 03:46:58

Fortunately, it's getting easier and easier to go IPv6 with Linux, even with 64-bit distributions; however, Ubuntu and the other Debian varations have made it the easiest so far. Starting with any installation of 'buntu 64-bit (9.04 and 9.10 are preferred), download and install aiccu via PackageKit (Ubuntu), KPackageKit (Kubuntu), or apt-get (terminal window/command line). Next, you need to edit aiccu.conf (the file is located in /etc; vim is the best tool for this, following the instructions in the FAQ) making the needed changes. Once that is done, start AICCU in a terminal/command-line session: sudo /usr/sbin/aiccu start Away you go.

SixxS and 'Buntu 9.10: Pain-free and Easy-peasy (x64)

Shadow Hawkins on Tuesday, 19 January 2010 21:31:47

Thanks for this. Unfortunately I can not seem to get my new tunnel working, even following your instructions. AICCU seems to properly connect and get my information. I can see it in /var/log/syslog. It grabs all the same numbers that I got in my email from SixXS. However, I can't seem to connect to via IPv6 to anywhere. So I ran aiccu test. The first 5 tests completely successfully, so I've clipped them out below. It says it could be a firewall or routing problem. Even with my firewall turned off, it doesn't work. I've posted my routing tables below. Any ideas?

###### [1/8] Ping the IPv4 Local/Your Outer Endpoint (208.47.173.116) # works ###### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (209.197.5.66) # works ###### [3/8] Traceroute to the PoP (209.197.5.66) over IPv4 # works ###### [4/8] Checking if we can ping IPv6 localhost (::1) # works ###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:1938:81:d7::2) # works ###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:1938:81:d7::1) ### This confirms the reachability of the other side of the tunnel ### If it doesn't reply then check your interface and routing tables ### Don't forget to check your firewall of course ### If the previous test was succesful then this could be both ### a firewalling and a routing/interface problem PING 2001:1938:81:d7::1(2001:1938:81:d7::1) 56 data bytes --- 2001:1938:81:d7::1 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2007ms

My routing table from ip -6 route:

2001:1938:81:d7::/64 via :: dev sixxs proto kernel metric 256 mtu 1280 advmss 1220 hoplimit 4294967295 fe80::/64 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 via :: dev sixxs proto kernel metric 256 mtu 1280 advmss 1220 hoplimit 4294967295 default via 2001:1938:81:d7::1 dev sixxs metric 1024 mtu 1280 advmss 1220 hoplimit 4294967295

Thanks for any ideas! I'm stuck.

SixxS and 'Buntu 9.10: Pain-free and Easy-peasy (x64)

Jeroen Massar SixXS Staff

on Wednesday, 20 January 2010 01:52:24

As per that big orange box, please provide a lot more details. The 'aiccu test' with full output would already a lot more, that certain steps work is one thing, but it also gives details, thus please list these. Two big questions of course: are you behind a NAT or firewalled in some way or another?

SixxS and 'Buntu 9.10: Pain-free and Easy-peasy (x64)

Shadow Hawkins on Wednesday, 20 January 2010 05:05:41

Thanks for your reply. As requested, the full aiccu test is below. To answer your questions first, no I am not behind a NAT or a firewall (besides the host's own iptables firewall, which I turned off for the test). I picked a 6-in-4-static tunnel since my IPv4 address does not change. Thanks again for any insight.

####### ####### AICCU Quick Connectivity Test ####### ####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (208.47.173.116) ### This should return so called 'echo replies' ### If it doesn't then check your firewall settings ### Your local endpoint should always be pingable ### It could also indicate problems with your IPv4 stack PING 208.47.173.116 (208.47.173.116) 56(84) bytes of data. 64 bytes from 208.47.173.116: icmp_seq=1 ttl=64 time=0.064 ms 64 bytes from 208.47.173.116: icmp_seq=2 ttl=64 time=0.049 ms 64 bytes from 208.47.173.116: icmp_seq=3 ttl=64 time=0.047 ms --- 208.47.173.116 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2011ms rtt min/avg/max/mdev = 0.047/0.053/0.064/0.009 ms ###### Did this work? [Y/n] ####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (209.197.5.66) ### These pings should reach the PoP and come back to you ### In case there are problems along the route between your ### host and the PoP this could not return replies ### Check your firewall settings if problems occur PING 209.197.5.66 (209.197.5.66) 56(84) bytes of data. 64 bytes from 209.197.5.66: icmp_seq=1 ttl=58 time=64.7 ms 64 bytes from 209.197.5.66: icmp_seq=2 ttl=58 time=86.4 ms 64 bytes from 209.197.5.66: icmp_seq=3 ttl=58 time=64.5 ms --- 209.197.5.66 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 64.591/71.936/86.477/10.282 ms ###### Did this work? [Y/n] ####### [3/8] Traceroute to the PoP (209.197.5.66) over IPv4 ### This traceroute should reach the PoP ### In case this traceroute fails then you have no connectivity ### to the PoP and this is most probably the problem traceroute to 209.197.5.66 (209.197.5.66), 30 hops max, 60 byte packets 1 208-47-173-113.dia.static.qwest.net (208.47.173.113) 0.908 ms 4.712 ms 4.804 ms 2 207.224.233.5 (207.224.233.5) 21.177 ms 21.247 ms 21.388 ms 3 slc-core-02.inet.qwest.net (205.171.131.102) 22.070 ms 22.212 ms 22.526 ms 4 sjp-brdr-04.inet.qwest.net (67.14.34.38) 40.018 ms 41.533 ms 41.592 ms 5 63.146.26.42 (63.146.26.42) 41.641 ms 41.700 ms 41.873 ms 6 te7-3-10G.ar1.SNV2.gblx.net (67.17.106.93) 42.445 ms 59.231 ms 62.379 ms 7 HIGHWINDS-NETWORK-GROUP.TenGigabitEthernet9-2.ar1.snv2.gblx.net (67.17.168.10) 38.832 ms 39.028 ms 39.845 ms 8 unknown.hwng.net (209.197.1.146) 52.274 ms 52.344 ms 52.402 ms 9 2-1.r2.ph.hwng.net (69.16.191.38) 93.321 ms 93.372 ms 93.564 ms 10 usphx01.sixxs.net (209.197.5.66) 67.130 ms 67.200 ms 67.844 ms ###### Did this work? [Y/n] ###### [4/8] Checking if we can ping IPv6 localhost (::1) ### This confirms if your IPv6 is working ### If ::1 doesn't reply then something is wrong with your IPv6 stack PING ::1(::1) 56 data bytes 64 bytes from ::1: icmp_seq=1 ttl=64 time=0.054 ms 64 bytes from ::1: icmp_seq=2 ttl=64 time=0.055 ms 64 bytes from ::1: icmp_seq=3 ttl=64 time=0.050 ms --- ::1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.050/0.053/0.055/0.002 ms ###### Did this work? [Y/n] ###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:1938:81:d7::2) ### This confirms that your tunnel is configured ### If it doesn't reply then check your interface and routing tables PING 2001:1938:81:d7::2(2001:1938:81:d7::2) 56 data bytes 64 bytes from 2001:1938:81:d7::2: icmp_seq=1 ttl=64 time=0.056 ms 64 bytes from 2001:1938:81:d7::2: icmp_seq=2 ttl=64 time=0.055 ms 64 bytes from 2001:1938:81:d7::2: icmp_seq=3 ttl=64 time=0.057 ms --- 2001:1938:81:d7::2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.055/0.056/0.057/0.000 ms ###### Did this work? [Y/n] ###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:1938:81:d7::1) ### This confirms the reachability of the other side of the tunnel ### If it doesn't reply then check your interface and routing tables ### Don't forget to check your firewall of course ### If the previous test was succesful then this could be both ### a firewalling and a routing/interface problem PING 2001:1938:81:d7::1(2001:1938:81:d7::1) 56 data bytes --- 2001:1938:81:d7::1 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2017ms ###### Did this work? [Y/n] n

SixxS and 'Buntu 9.10: Pain-free and Easy-peasy (x64)

Shadow Hawkins on Thursday, 21 January 2010 04:06:28

If I am reading the traceroute correctly, you have a Qwest static dsl line with a /32. What do you have for a DSL modem/router? Does it have a firewall and could it be blocking protocol 41? Lyle Giese LCR Computer Services, Inc.

SixxS and 'Buntu 9.10: Pain-free and Easy-peasy (x64)

Shadow Hawkins on Friday, 22 January 2010 19:00:36

Hi Lyle, Thanks for your response. We have two bonded T1s from Qwest that run into an Adtran Total Access 924e router. I don't see anything in the configuration that would block protocol 41 (or any protocol for that matter) but perhaps I am looking in the wrong place. Is there a good way to test this? Willie

SixxS and 'Buntu 9.10: Pain-free and Easy-peasy (x64)

Shadow Hawkins on Saturday, 23 January 2010 01:02:51

I would do some research on that Adtran router. I am not familar with it. I have a Cisco 2620 with 2 T1's here and I had to specificly allow proto 41 in the ACL's on the Cisco. On our DSL line here I have a 2wire router with a Soekris Net4801 running pfSense. It's a long story how I ended up on this setup, but I had to configure the 2wire to put the Soekris in it's DMZ before proto 41 would pass through. Lyle Giese LCR Computer Services, Inc.

SixxS and 'Buntu 9.10: Pain-free and Easy-peasy (x64)

Shadow Hawkins on Monday, 25 January 2010 22:59:35

Lyle, Thanks for the tip. I contacted Adtran and asked them about the proper configuration. They were very quick and supportive about getting back to me. Part of their response:

IP protocol 41 is currently unsupported through the firewall, but is routable without it ("no ip firewall"). I am setting up a feature request to enable 6to4 tunneling using a firewall "allow" policy.

Armed with this information, I should be able to get things to work the way I want them to. Thanks again for your help.

SixxS and 'Buntu 9.10: Pain-free and Easy-peasy (x64)

Shadow Hawkins on Wednesday, 27 January 2010 21:57:48

Just wanted to update this thread with more information. I talked with a Qwest technician and we temporarily turned off the firewall in the Adtran router*. My 6in4 packets still never seemed to make it to the other end -- so there must be something else blocking things further upstream in Qwest (they are not IPv6 ready). I guess I'll have to use AYIYA, but I don't have enough credits to change my tunnel type either. So I may just be stuck. (I've disabled my tunnel to keep from losing credits for the time being.) Any thoughts on how I can change the tunnel type? * The firewall was on to enforce QoS for our voice packets.

SixxS and 'Buntu 9.10: Pain-free and Easy-peasy (x64)

Jeroen Massar SixXS Staff

on Thursday, 28 January 2010 00:41:38

You can *always* move or change the type of a tunnel, you just can't request a new one.

Please note Posting is only allowed when you are logged in.