Ticket ID: SIXXS #580717 Ticket Status: User PoP: usbos01 - OCCAID Inc. (Boston, Massachusetts)
Tunnel T12678 non-functional
Shadow Hawkins on Friday, 21 September 2007 04:53:21
I have read and followed the "Reporting Problems" section on the Contact page and am providing the following details for this report based on the list of items stated there:
For the last few days; I have not been able to maintain my T12678 Tunnel reliably; however the same system where AICCU has been reconfigured to my T12680 Tunnel is able to work as expected; I also am not able to connect my T12678 tunnel on the "known-good" system (which has no problems with the T12680 tunnel).
This is on CentOS 5 with current updates; running a rebuilt version of aiccu from the fedora 7 repo's (src rpm rebuilt with 'rpmbuild --rebuild'.
----------------- T12678 autotest -------------------------------------
leetrum@nullptr:~$ cat /tmp/t12678.log
#######
####### AICCU Quick Connectivity Test
#######
####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (206.248.171.173)
### 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 206.248.171.173 (206.248.171.173) 56(84) bytes of data.
64 bytes from 206.248.171.173: icmp_seq=1 ttl=64 time=1.53 ms
64 bytes from 206.248.171.173: icmp_seq=2 ttl=64 time=1.52 ms
64 bytes from 206.248.171.173: icmp_seq=3 ttl=64 time=1.37 ms
--- 206.248.171.173 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 1.378/1.480/1.535/0.072 ms
######
####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (216.93.250.26)
### 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 216.93.250.26 (216.93.250.26) 56(84) bytes of data.
64 bytes from 216.93.250.26: icmp_seq=1 ttl=52 time=26.6 ms
64 bytes from 216.93.250.26: icmp_seq=2 ttl=52 time=26.9 ms
64 bytes from 216.93.250.26: icmp_seq=3 ttl=52 time=25.0 ms
--- 216.93.250.26 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 25.074/26.214/26.949/0.838 ms
######
####### [3/8] Traceroute to the PoP (216.93.250.26) 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
sh: traceroute: command not found
######
###### [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.043 ms
64 bytes from ::1: icmp_seq=2 ttl=64 time=0.046 ms
64 bytes from ::1: icmp_seq=3 ttl=64 time=0.047 ms
--- ::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.043/0.045/0.047/0.005 ms
######
###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:4830:1100:42::2)
### This confirms that your tunnel is configured
### If it doesn't reply then check your interface and routing tables
PING 2001:4830:1100:42::2(2001:4830:1100:42::2) 56 data bytes
64 bytes from 2001:4830:1100:42::2: icmp_seq=1 ttl=64 time=0.038 ms
64 bytes from 2001:4830:1100:42::2: icmp_seq=2 ttl=64 time=0.062 ms
64 bytes from 2001:4830:1100:42::2: icmp_seq=3 ttl=64 time=0.067 ms
--- 2001:4830:1100:42::2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.038/0.055/0.067/0.015 ms
######
###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:4830:1100:42::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:4830:1100:42::1(2001:4830:1100:42::1) 56 data bytes
From 2001:4830:1100:42::2 icmp_seq=1 Destination unreachable: Address unreachable
From 2001:4830:1100:42::2 icmp_seq=2 Destination unreachable: Address unreachable
From 2001:4830:1100:42::2 icmp_seq=3 Destination unreachable: Address unreachable
--- 2001:4830:1100:42::1 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 1999ms
######
###### [7/8] Traceroute6 to the central SixXS machine (noc.sixxs.net)
### This confirms that you can reach the central machine of SixXS
### If that one is reachable you should be able to reach most IPv6 destinations
### Also check http://www.sixxs.net/ipv6calc/ which should show an IPv6 connection
### If your browser supports IPv6 and uses it of course.
traceroute to noc.sixxs.net (2001:838:1:1:210:dcff:fe20:7c7c) from 2001:4830:1100:42::2, 30 hops max, 24 byte packets
1 cl-67.bos-01.us.sixxs.net (2001:4830:1100:42::2) 0.066 ms !H 0.038 ms !H 0.029 ms !H
######
###### [8/8] Traceroute6 to (www.kame.net)
### This confirms that you can reach a Japanese IPv6 destination
### If that one is reachable you should be able to reach most IPv6 destinations
### You should also check http://www.kame.net which should display
### a animated kame (turtle), of course only when your browser supports and uses IPv6
traceroute to www.kame.net (2001:200:0:8002:203:47ff:fea5:3085) from 2001:4830:1100:42::2, 30 hops max, 24 byte packets
1 cl-67.bos-01.us.sixxs.net (2001:4830:1100:42::2) 0.054 ms !H 0.037 ms !H 0.028 ms !H
######
###### ACCU Quick Connectivity Test (done)
### Either the above all works and gives no problems
### or it shows you where what goes wrong
### Check the SixXS FAQ (http://www.sixxs.net/faq/
### for more information and possible solutions or hints
### Don't forget to check the Forums (http://www.sixxs.net/forum/)
### for a helping hand.
### Passing the output of 'aiccu autotest >aiccu.log' is a good idea.
leetrum@nullptr:~$ route -A inet6 -n
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
::1/128 :: U 0 36 1 lo
2001:4830:1100:42::2/128 :: U 0 4 1 lo
2001:4830:1100:42::/64 :: U 256 1 0 sixxs
2001:4830:111a:69::/64 :: UA 256 26 0 eth0
fe80::cef8:abad/128 :: U 0 0 1 lo
fe80::218:8bff:fede:5a2f/128 :: U 0 0 1 lo
fe80::21c:26ff:fe0f:68eb/128 :: U 0 50 1 lo
fe80::84e9:90ff:fe3a:c477/128 :: U 0 0 1 lo
fe80::b8fa:94ff:fe7a:b6b4/128 :: U 0 0 1 lo
fe80::/64 :: U 256 0 0 tap0
fe80::/64 :: U 256 0 0 tap1
fe80::/64 :: U 256 0 0 br0
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 sixxs
ff00::/8 :: U 256 0 0 tap0
ff00::/8 :: U 256 0 0 tap1
ff00::/8 :: U 256 0 0 br0
ff00::/8 :: U 256 0 0 eth0
ff00::/8 :: U 256 0 0 sixxs
::/0 2001:4830:1100:42::1 UG 1024 3 0 sixxs
-------------------------- snip -----------------------------------------
---------------------- T12680 test --------------------------------------
leetrum@nullptr:~$ cat /tmp/t12680.log
#######
####### AICCU Quick Connectivity Test
#######
####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (192.168.69.155)
### 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 192.168.69.155 (192.168.69.155) 56(84) bytes of data.
64 bytes from 192.168.69.155: icmp_seq=1 ttl=64 time=0.035 ms
64 bytes from 192.168.69.155: icmp_seq=2 ttl=64 time=0.033 ms
64 bytes from 192.168.69.155: icmp_seq=3 ttl=64 time=0.040 ms
--- 192.168.69.155 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.033/0.036/0.040/0.003 ms
######
####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (216.93.250.26)
### 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 216.93.250.26 (216.93.250.26) 56(84) bytes of data.
64 bytes from 216.93.250.26: icmp_seq=1 ttl=52 time=26.4 ms
64 bytes from 216.93.250.26: icmp_seq=2 ttl=52 time=28.1 ms
64 bytes from 216.93.250.26: icmp_seq=3 ttl=52 time=24.2 ms
--- 216.93.250.26 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 24.211/26.277/28.139/1.615 ms
######
####### [3/8] Traceroute to the PoP (216.93.250.26) 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
sh: traceroute: command not found
######
###### [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.043 ms
64 bytes from ::1: icmp_seq=2 ttl=64 time=0.048 ms
64 bytes from ::1: icmp_seq=3 ttl=64 time=0.044 ms
--- ::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.043/0.045/0.048/0.002 ms
######
###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:4830:1100:43::2)
### This confirms that your tunnel is configured
### If it doesn't reply then check your interface and routing tables
PING 2001:4830:1100:43::2(2001:4830:1100:43::2) 56 data bytes
64 bytes from 2001:4830:1100:43::2: icmp_seq=1 ttl=64 time=0.034 ms
64 bytes from 2001:4830:1100:43::2: icmp_seq=2 ttl=64 time=0.051 ms
64 bytes from 2001:4830:1100:43::2: icmp_seq=3 ttl=64 time=0.058 ms
--- 2001:4830:1100:43::2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.034/0.047/0.058/0.012 ms
######
###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:4830:1100:43::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:4830:1100:43::1(2001:4830:1100:43::1) 56 data bytes
64 bytes from 2001:4830:1100:43::1: icmp_seq=1 ttl=64 time=28.8 ms
64 bytes from 2001:4830:1100:43::1: icmp_seq=2 ttl=64 time=29.2 ms
64 bytes from 2001:4830:1100:43::1: icmp_seq=3 ttl=64 time=28.3 ms
--- 2001:4830:1100:43::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 28.314/28.820/29.255/0.411 ms
######
###### [7/8] Traceroute6 to the central SixXS machine (noc.sixxs.net)
### This confirms that you can reach the central machine of SixXS
### If that one is reachable you should be able to reach most IPv6 destinations
### Also check http://www.sixxs.net/ipv6calc/ which should show an IPv6 connection
### If your browser supports IPv6 and uses it of course.
traceroute to noc.sixxs.net (2001:838:1:1:210:dcff:fe20:7c7c) from 2001:4830:1100:43::2, 30 hops max, 24 byte packets
1 gw-68.bos-01.us.sixxs.net (2001:4830:1100:43::1) 28.907 ms 29.659 ms 28.459 ms
2 bbr01-ve402.bstn01.occaid.net (2001:4830:e1:b::1) 28.729 ms 29.452 ms 28.126 ms
3 bbr01-p1-0.whkn01.occaid.net (2001:4830:ff:15c4::1) 35.197 ms 35.38 ms 35.379 ms
4 bbr01-p2-0.lndn01.occaid.net (2001:4830:fe:1010::1) 106.633 ms 105.129 ms 106.34 ms
5 2001:7f8:4::2331:1 (2001:7f8:4::2331:1) 106.19 ms 104.981 ms 103.627 ms
6 ge-3-1-44.bb2.bru1.be.gbxs.net (2a01:300:30:7::1) 113.206 ms 110.041 ms 112.094 ms
7 ge-3-5.bb2.bru1.be.gbxs.net (2a01:300:30::2) 115.732 ms 111.544 ms 116.65 ms
8 so-7-0-0.bb1.ams3.nl.gbxs.net (2a01:300:30:6::2) 115.219 ms 116.469 ms 123.459 ms
9 ams-ix2.ipv6.concepts.nl (2001:7f8:1::a501:2871:2) 116.427 ms 122.992 ms 202.411 ms
10 2001:838:0:13::1 (2001:838:0:13::1) 176.017 ms 126.787 ms 117.162 ms
11 2001:838:0:12::2 (2001:838:0:12::2) 125.928 ms 120.873 ms 119.921 ms
12 noc.sixxs.net (2001:838:1:1:210:dcff:fe20:7c7c) 123.497 ms 123.782 ms 119.276 ms
######
###### [8/8] Traceroute6 to (www.kame.net)
### This confirms that you can reach a Japanese IPv6 destination
### If that one is reachable you should be able to reach most IPv6 destinations
### You should also check http://www.kame.net which should display
### a animated kame (turtle), of course only when your browser supports and uses IPv6
traceroute to www.kame.net (2001:200:0:8002:203:47ff:fea5:3085) from 2001:4830:1100:43::2, 30 hops max, 24 byte packets
1 gw-68.bos-01.us.sixxs.net (2001:4830:1100:43::1) 28.16 ms 30.093 ms 28.948 ms
2 bbr01-ve402.bstn01.occaid.net (2001:4830:e1:b::1) 28.763 ms 29.132 ms 28.33 ms
3 bbr01-p1-0.nwrk01.occaid.net (2001:4830:ff:15c4::1) 35.719 ms 32.004 ms 36.504 ms
4 bbr01-g1-0.asbn01.occaid.net (2001:4830:ff:f150::2) 43.115 ms 42.003 ms 41.722 ms
5 xe-0.equinix.asbnva01.us.bb.gin.ntt.net (2001:504:0:2::2914:1) 40.267 ms 39.443 ms 43.444 ms
6 ae-0.r20.asbnva01.us.bb.gin.ntt.net (2001:418:0:2000::8d) 40.507 ms 43.801 ms 40.155 ms
7 as-0.r20.snjsca04.us.bb.gin.ntt.net (2001:418:0:2000::1de) 121.583 ms 118.53 ms 123.798 ms
8 as-2.r20.tokyjp01.jp.bb.gin.ntt.net (2001:218:0:2000::ce) 239.995 ms 239.971 ms 239.954 ms
9 xe-3-2.a15.tokyjp01.jp.ra.gin.ntt.net (2001:218:0:6000::10e) 223.83 ms 222.313 ms 219.921 ms
10 ge-8-2.a15.tokyjp01.jp.ra.gin.ntt.net (2001:218:2000:5000::82) 231.91 ms 229.597 ms 228.122 ms
11 ve-4.nec2.yagami.wide.ad.jp (2001:200:0:1c04:230:13ff:feae:5b) 232.003 ms 231.729 ms *
12 lo0.alaxala1.k2.wide.ad.jp (2001:200:0:4800::7800:1) 226.124 ms 227.778 ms 220.174 ms
13 orange.kame.net (2001:200:0:8002:203:47ff:fea5:3085) 223.783 ms 224.152 ms 224.068 ms
######
###### ACCU Quick Connectivity Test (done)
### Either the above all works and gives no problems
### or it shows you where what goes wrong
### Check the SixXS FAQ (http://www.sixxs.net/faq/
### for more information and possible solutions or hints
### Don't forget to check the Forums (http://www.sixxs.net/forum/)
### for a helping hand.
### Passing the output of 'aiccu autotest >aiccu.log' is a good idea.
leetrum@nullptr:~$
leetrum@nullptr:~$ route -A inet6 -n
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
::1/128 :: U 0 36 1 lo
2001:4830:1100:43::2/128 :: U 0 2 1 lo
2001:4830:1100:43::/64 :: U 256 1 0 sixxs
2001:4830:111a:69::/64 :: UA 256 26 0 eth0
fe80::218:8bff:fede:5a2f/128 :: U 0 0 1 lo
fe80::21c:26ff:fe0f:68eb/128 :: U 0 50 1 lo
fe80::4830:1100:43:2/128 :: U 0 0 1 lo
fe80::84e9:90ff:fe3a:c477/128 :: U 0 0 1 lo
fe80::b8fa:94ff:fe7a:b6b4/128 :: U 0 0 1 lo
fe80::/64 :: U 256 0 0 tap0
fe80::/64 :: U 256 0 0 tap1
fe80::/64 :: U 256 0 0 br0
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 sixxs
ff00::/8 :: U 256 0 0 tap0
ff00::/8 :: U 256 0 0 tap1
ff00::/8 :: U 256 0 0 br0
ff00::/8 :: U 256 0 0 eth0
ff00::/8 :: U 256 0 0 sixxs
::/0 2001:4830:1100:43::1 UG 1024 3 0 sixxs
------------------------------ snip -------------------------------------
----------------------------- aiccu.conf ---------------------------------
# Under control from debconf, please use 'dpkg-reconfigure aiccu' to reconfigure
username <removed>
password <removed>
#protocol tic
#server tic.sixxs.net
tunnel_id T12680
#tunnel_id T12678
# AICCU Configuration
# Login information (defaults: none)
#username <your nichandle/username>
#password <your password>
# Protocol and server to use for setting up the tunnel (defaults: none)
#protocol <tic|tsp|l2tp>
#server <server to use>
# Interface names to use (default: aiccu)
# ipv6_interface is the name of the interface that will be used as a tunnel interface.
# On *BSD the ipv6_interface should be set to gifX (eg gif0) for proto-41 tunnels
# or tunX (eg tun0) for AYIYA tunnels.
ipv6_interface sixxs
# The tunnel_id to use (default: none)
# (only required when there are multiple tunnels in the list)
#tunnel_id Txxxx
# Be verbose? (default: false)
verbose false
# Daemonize? (default: true)
# Set to false if you want to see any output
# When true output goes to syslog
#
# WARNING: never run AICCU from DaemonTools or a similar automated
# 'restart' tool/script. When AICCU does not start, it has a reason
# not to start which it gives on either the stdout or in the (sys)log
# file. The TIC server *will* automatically disable accounts which
# are detected to run in this mode.
#
daemonize true
# Automatic Login and Tunnel activation?
automatic true
# Require TLS?
# When set to true, if TLS is not supported on the server
# the TIC transaction will fail.
# When set to false, it will try a starttls, when that is
# not supported it will continue.
# In any case if AICCU is build with TLS support it will
# try to do a 'starttls' to the TIC server to see if that
# is supported.
requiretls false
# PID File
#pidfile /var/run/aiccu.pid
# Add a default route (default: true)
#defaultroute true
# Script to run after setting up the interfaces (default: none)
#setupscript /usr/local/etc/aiccu-subnets.sh
# Make heartbeats (default true)
# In general you don't want to turn this off
# Of course only applies to AYIYA and heartbeat tunnels not to static ones
makebeats true
# Don't configure anything (default: false)
#noconfigure true
# Behind NAT (default: false)
# Notify the user that a NAT-kind network is detected
behindnat true
# Local IPv4 Override (default: none)
# Overrides the IPv4 parameter received from TIC
# This allows one to configure a NAT into "DMZ" mode and then
# forwarding the proto-41 packets to an internal host.
#
# This is only needed for static proto-41 tunnels!
# AYIYA and heartbeat tunnels don't require this.
#local_ipv4_override
---------------------- snip -----------------------------------
Thank-you in advance for you assistance!
- Shawn
Tunnel T12678 non-functional
Jeroen Massar on Friday, 21 September 2007 11:39:51
The working tunnel is AYIYA based, as such it uses UDP and heartbeats which makes it work through most firewalls and NATs. The non-working tunnel is proto-41 and you might have a firewall on your own machine or between you and the PoP which is blocking packets for you.
Tunnel T12678 non-functional
Shadow Hawkins on Friday, 21 September 2007 16:02:57
Hi Jeroen,
The non-working tunnel was AYIYA based; I changed it to attempt to remedy the problem; if I change it back I am left with 1 credit (and no way to change it again); do you recommend I change it back and re-test?
Thanks!
- Shawn
Tunnel T12678 non-functional
Shadow Hawkins on Friday, 21 September 2007 16:05:20
I should further mention that I have explored the firewall issue around protocol 41 (even going as far as changing my firewall to a linux-based firewall so that I can explicitly forward protocol-41 packets to the host in question); I do have a log target that logs everything just before it hits the policy drop target; and don't see anything around protocol-41 being logged...
Cheers,
Shawn
Tunnel T12678 non-functional
Shadow Hawkins on Saturday, 22 September 2007 02:29:08
Hi Again,
After changing the tunnel type back to ayiya it seems to be working again; after some research it seems that I may have started to muck with this while there was a problem with OCCAID; and compounded things...
Thank you for all of your help,
Cheers,
Shawn
Tunnel T12678 non-functional
Jeroen Massar on Saturday, 22 September 2007 02:58:35
If you explicitly have to forward protocol-41 then you are doing some NAT circumvention and that clearly can be causing issues.
State change: user
Jeroen Massar on Saturday, 22 September 2007 02:57:07
The state of this ticket has been changed to user
Posting is only allowed when you are logged in. |