|
New tunnel Outboud traffic fails
![[us]](/s/countries/us.gif) Shadow Hawkins on Friday, 12 January 2007 21:39:56
I've setup a new heartbeat tunnel.
I have a DSL connection from AT&T (dynamic IP). There is a SpeedStream 5100 (1.0.0.53) connected to the dsl line, pppoe and NAT are running on the modem. The endpoint is a Fedora Core 5 box. I am using Shorewall to configure the Fedora box. This box acts as the primary router for my home network. I am using aiccu for tunnel configuration.
aiccu with verbose turned on prints out that it found the tunnel information like it seems is should. aiccu test passes all tests until it tries to ping the POP end of the tunnel.
tcpdup shows heartbeat packets being sent properly (no response to them, not sure if there should be one). I am also seeing ICMP6 echo request packets inbound from the POP.
14:04:25.297019 IP iad0-sixxs.hotnic.net > 192.168.1.64: IP6 gw-91.qas-01.us.sixxs.net > cl-91.qas-01.us.sixxs.net: ICMP6, echo request, seq 25600, length 64
14:04:28.302354 IP iad0-sixxs.hotnic.net > 192.168.1.64: IP6 gw-91.qas-01.us.sixxs.net > cl-91.qas-01.us.sixxs.net: ICMP6, echo request, seq 25600, length 64
14:04:31.296821 IP iad0-sixxs.hotnic.net > 192.168.1.64: IP6 gw-91.qas-01.us.sixxs.net > cl-91.qas-01.us.sixxs.net: ICMP6, echo request, seq 25600, length 64
14:04:34.313009 IP iad0-sixxs.hotnic.net > 192.168.1.64: IP6 gw-91.qas-01.us.sixxs.net > cl-91.qas-01.us.sixxs.net: ICMP6, echo request, seq 25600, length 64
I am also seeing replies being sent to those packets
14:20:09.755490 IP 192.168.1.64 > iad0-sixxs.hotnic.net: IP6 cl-91.qas-01.us.sixxs.net > igloo.stacken.kth.se: ICMP6, echo request, seq 4, length 64
14:20:10.755563 IP 192.168.1.64 > iad0-sixxs.hotnic.net: IP6 cl-91.qas-01.us.sixxs.net > igloo.stacken.kth.se: ICMP6, echo request, seq 5, length 64
14:20:11.755919 IP 192.168.1.64 > iad0-sixxs.hotnic.net: IP6 cl-91.qas-01.us.sixxs.net > igloo.stacken.kth.se: ICMP6, echo request, seq 6, length 64
14:20:12.755692 IP 192.168.1.64 > iad0-sixxs.hotnic.net: IP6 cl-91.qas-01.us.sixxs.net > igloo.stacken.kth.se: ICMP6, echo request, seq 7, length 64
I am not able to ping the gateway. My routing table appears to be fine.
[root@wurm ~]# route --inet6
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
::1/128 * U 0 12128 1 lo
2001:4830:1600:5a::/128 * U 0 0 2 lo
cl-91.qas-01.us.sixxs.net/128 * U 0 40 1 lo
2001:4830:1600:5a::/64 * U 256 94 0 sixxs
fe80::/128 * U 0 0 2 lo
fe80::ac10:1/128 * U 0 0 1 lo
fe80::c0a8:140/128 * U 0 0 1 lo
fe80::20e:2eff:fe2c:7dd9/128 * U 0 0 1 lo
fe80::220:18ff:fe8b:5487/128 * U 0 0 1 lo
fe80::/64 * U 256 0 0 eth0
fe80::/64 * U 256 0 0 eth1
fe80::/64 * U 256 0 0 sixxs
ff00::/8 * U 256 0 0 eth0
ff00::/8 * U 256 0 0 eth1
ff00::/8 * U 256 0 0 sixxs
*/0 gw-91.qas-01.us.sixxs.net UG 1024 15 0 sixxs
Pinging www.ipv6.org results in outbound request packets but no inbound replies.
Any thoughts/suggestions would be greatly appreciated.
New tunnel Outboud traffic fails
Please see this FAQ about NAT's.
* Protocol 41 / heartbeat does not work over NATs
* AYIYA does work over NAT's.
In other words: change your tunnel to an AYIYA tunnel and you will be fine.
The reason that you are not seeing any response is because the SpeedTouch doesn't forward the proto-41 packets to your host.
New tunnel Outboud traffic fails
![[at]](/s/countries/at.gif) Shadow Hawkins on Saturday, 13 January 2007 11:27:13
You can try to forward 6to4 packets to your host.
On SpeedTouch/Thomson this should be doable like this:
:nat mapadd intf=LocalNetwork type=nat outside_addr=0.0.0.1 inside_addr=192.168.
0.1 protocol=6to4
where LocalNetwork is your LAN group, and 192.168.1.1 is the address you want to forward the 6to4 traffic to.
Hope it works and helps :)
CU, Ricsi
New tunnel Outboud traffic fails
Shadow Hawkins on Saturday, 13 January 2007 02:43:26
Still no luck after switching tunnel types. Not sure what I'm doing wrong here.
New tunnel Outboud traffic fails
Shadow Hawkins on Saturday, 13 January 2007 03:30:24
Looks like I also had a firewall issue, allowing all traffic from the POP host worked.
New tunnel Outboud traffic fails
Shadow Hawkins on Saturday, 13 January 2007 04:40:22
looks like a spoke too soon. Still no luck with the AYIYA tunnel.
like before I'm seeing packets from the POP and appear to be responding. I'm concerned about the DF flag in my outbound packets. Could this be the issue, and if so any idea how to tell Fedora it's OK to fragment udp packets?
21:34:27.966596 IP (tos 0x0, ttl 55, id 62284, offset 0, flags [none], proto: UDP (17), length: 176) iad0-sixxs.hotnic.net.ayiya > 192.168.1.64.36165: [udp sum ok] UDP, length 148
21:34:27.967803 IP (tos 0x0, ttl 64, id 34885, offset 0, flags [DF], proto: UDP (17), length: 180) 192.168.1.64.36165 > iad0-sixxs.hotnic.net.ayiya: [udp sum ok] UDP, length 152
21:34:31.048293 IP (tos 0x0, ttl 55, id 62336, offset 0, flags [none], proto: UDP (17), length: 176) iad0-sixxs.hotnic.net.ayiya > 192.168.1.64.36165: [udp sum ok] UDP, length 148
21:34:31.049820 IP (tos 0x0, ttl 64, id 34886, offset 0, flags [DF], proto: UDP (17), length: 180) 192.168.1.64.36165 > iad0-sixxs.hotnic.net.ayiya: [udp sum ok] UDP, length 152
21:34:34.199218 IP (tos 0x0, ttl 55, id 62387, offset 0, flags [none], proto: UDP (17), length: 176) iad0-sixxs.hotnic.net.ayiya > 192.168.1.64.36165: [udp sum ok] UDP, length 148
New tunnel Outboud traffic fails
Where is for instance the output of "aiccu test" and did you check points in "Reporting Problems"?
Also, which version of aiccu are you using, and more-over where from and how was it compiled? Apparently there are broken versions of the new 20070107 flying around, as such: use the version from the archive.
New tunnel Outboud traffic fails
Shadow Hawkins on Saturday, 13 January 2007 05:07:29
I'll pull a new version of aiccu.
aiccu is from Fedora Extras
[root@wurm ~]# aiccu version
AICCU 2007.01.07-console-linux by Jeroen Massar
[root@wurm ~]# aiccu test
Tunnel Information for T10645:
POP Id : usqas01
IPv6 Local : 2001:4830:1600:5a::2/64
IPv6 Remote : 2001:4830:1600:5a::1/64
Tunnel Type : ayiya
Adminstate : enabled
Userstate : enabled
[root@wurm ~]# aiccu version
AICCU 2007.01.07-console-linux by Jeroen Massar
[root@wurm ~]# aiccu test
Tunnel Information for T10645:
POP Id : usqas01
IPv6 Local : 2001:4830:1600:5a::2/64
IPv6 Remote : 2001:4830:1600:5a::1/64
Tunnel Type : ayiya
Adminstate : enabled
Userstate : enabled
[root@wurm ~]# aiccu stop
[root@wurm ~]# aiccu autotest
Tunnel Information for T10645:
POP Id : usqas01
IPv6 Local : 2001:4830:1600:5a::2/64
IPv6 Remote : 2001:4830:1600:5a::1/64
Tunnel Type : ayiya
Adminstate : enabled
Userstate : enabled
#######
####### AICCU Quick Connectivity Test
#######
####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (192.168.1.64)
### 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.1.64 (192.168.1.64) 56(84) bytes of data.
64 bytes from 192.168.1.64: icmp_seq=1 ttl=64 time=0.157 ms
64 bytes from 192.168.1.64: icmp_seq=2 ttl=64 time=0.197 ms
64 bytes from 192.168.1.64: icmp_seq=3 ttl=64 time=0.193 ms
--- 192.168.1.64 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.157/0.182/0.197/0.021 ms
######
####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (66.117.47.228)
### 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 66.117.47.228 (66.117.47.228) 56(84) bytes of data.
64 bytes from 66.117.47.228: icmp_seq=1 ttl=55 time=42.4 ms
64 bytes from 66.117.47.228: icmp_seq=2 ttl=55 time=42.4 ms
64 bytes from 66.117.47.228: icmp_seq=3 ttl=55 time=42.6 ms
--- 66.117.47.228 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 42.434/42.511/42.648/0.097 ms
######
####### [3/8] Traceroute to the PoP (66.117.47.228) 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 66.117.47.228 (66.117.47.228), 30 hops max, 40 byte packets
1 192.168.0.1 (192.168.0.1) 0.000 ms 0.000 ms 0.000 ms
2 adsl-70-241-79-254.dsl.hstntx.swbell.net (70.241.79.254) 7.911 ms 8.643 ms 7.564 ms
3 dist2-vlan50.hstntx.sbcglobal.net (151.164.11.125) 8.019 ms 8.830 ms 8.602 ms
4 bb2-g14-0.hstntx.sbcglobal.net (151.164.92.206) 134.906 ms 129.608 ms 112.909 ms
5 151.164.92.233 (151.164.92.233) 8.414 ms 8.878 ms 8.791 ms
6 core1-p8-0.crhstx.sbcglobal.net (151.164.188.101) 9.621 ms 9.749 ms 10.008 ms
7 bb2-p5-0.sntc01.sbcglobal.net (151.164.242.126) 16.284 ms 16.402 ms 16.506 ms
8 core2-p1-0.crdltx.sbcglobal.net (151.164.242.101) 21.976 ms 20.536 ms 22.109 ms
9 bb1-p5-0.dllstx.sbcglobal.net (151.164.93.95) 21.775 ms 21.785 ms 19.934 ms
10 bb2-p9-0.dllstx.sbcglobal.net (151.164.40.206) 14.884 ms 15.629 ms 14.227 ms
11 ex2-p2-1.eqdltx.sbcglobal.net (151.164.42.19) 15.143 ms 15.587 ms 15.963 ms
12 151.164.251.142 (151.164.251.142) 15.100 ms 17.626 ms 16.517 ms
13 carpathia.ge12-1.br02.ash01.pccwbtn.net (63.218.94.166) 44.069 ms 42.285 ms 42.184 ms
14 iad0-b0-ge0.hotnic.net (66.117.34.140) 42.033 ms 42.101 ms 42.000 ms
15 iad0-sixxs.hotnic.net (66.117.47.228) 42.200 ms 42.173 ms 41.861 ms
######
###### [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=0 ttl=64 time=0.196 ms
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.116 ms
64 bytes from ::1: icmp_seq=2 ttl=64 time=0.098 ms
--- ::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2010ms
rtt min/avg/max/mdev = 0.098/0.136/0.196/0.044 ms, pipe 2
######
###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:4830:1600:5a::2)
### This confirms that your tunnel is configured
### If it doesn't reply then check your interface and routing tables
PING 2001:4830:1600:5a::2(2001:4830:1600:5a::2) 56 data bytes
64 bytes from 2001:4830:1600:5a::2: icmp_seq=0 ttl=64 time=0.115 ms
64 bytes from 2001:4830:1600:5a::2: icmp_seq=1 ttl=64 time=0.119 ms
64 bytes from 2001:4830:1600:5a::2: icmp_seq=2 ttl=64 time=0.129 ms
--- 2001:4830:1600:5a::2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.115/0.121/0.129/0.005 ms, pipe 2
######
###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:4830:1600:5a::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:1600:5a::1(2001:4830:1600:5a::1) 56 data bytes
--- 2001:4830:1600:5a::1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2000ms
######
###### [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), 30 hops max, 40 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
######
###### [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), 30 hops max, 40 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
######
###### ACCU Quick Connectivity Test (done)
New tunnel Outboud traffic fails
Shadow Hawkins on Saturday, 13 January 2007 05:28:35
Looks like it was a bad aiccu version on fedora's extras repository. 2006.07.25-console-linux from the extras repository works.
|
![[ch]](/s/countries/ch.gif)
on Friday, 12 January 2007 23:25:51
Posting is only allowed when you are