As mentioned in another thread [1], a new firmware update broke my Hurricane Electric IPv6 tunnel back in October. After a couple of unsuccessful calls to ATT support, I finally emailed Customer Care and got a great response from someone. Basically, a tech was dispatched the next day to swap out my 2Wire/Pace gateway with the Motorola NVG 589. After reading the glowing reports on it in the thread mentioned above (and elsewhere), I was very optimistic that my IPv6 tunnel would be working again.
However, I was wrong. I've got it set up in PassThrough mode to my own router/firewall (a halfdepth 1u atom machine) so that my machine gets the public IP. I turned off the NVG589 packet filter completely just in case. Aside from changing the public IP address, the config is unchanged from when it was working fine (before the 2Wire firmware update broke it), yet still I am unable to get traffic over the ipv6 tunnel.
root@ns:/var/log# host google.com | grep IPv6google.com has IPv6 address 2607:f8b0:4002:c06::8broot@ns:/var/log# ping6 -c1 google.comPING google.com(yv-in-x8b.1e100.net) 56 data bytes --- google.com ping statistics ---1 packets transmitted, 0 received, 100% packet loss, time 0ms
My firewall rules are set to allow protocol 41 (ipv6 tunneled through ipv4) going out:
-A OUTPUT -p ipv6 -j NFLOG --nflog-prefix "Outgoing ipv6"-A OUTPUT -p ipv6 -j ACCEPT
The NFLOG line is there so that I could see this (and verify that they were indeed going out):
root@ns:/var/log# tail -n1 firewallJan 4 19:26:17 ns Outgoing ipv6 IN= OUT=eth0 MAC= SRC=108.235.241.192 DST=216.66.22.2 \LEN=124 TOS=00 PREC=0x00 TTL=255 ID=21007 DF PROTO=41 UID=0 GID=0 MARK=0
Here's all the interface information for anyone who wants to verify that it's all correct :)
root@ns:/var/log# ip addr1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 4c:72:b9:4e:b4:57 brd ff:ff:ff:ff:ff:ff inet 108.235.241.192/22 brd 108.235.243.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::4e72:b9ff:fe4e:b457/64 scope link valid_lft forever preferred_lft forever3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:14:d1:1f:81:0e brd ff:ff:ff:ff:ff:ff inet 192.168.13.1/24 brd 192.168.13.255 scope global eth1 valid_lft forever preferred_lft forever inet6 2001:470:8:937::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::214:d1ff:fe1f:810e/64 scope link valid_lft forever preferred_lft forever4: sit0: <NOARP> mtu 1480 qdisc noop state DOWN link/sit 0.0.0.0 brd 0.0.0.06: he-ipv6: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN link/sit 108.235.241.192 peer 216.66.22.2 inet6 2001:470:7:937::2/64 scope global valid_lft forever preferred_lft forever inet6 fe80::6ceb:f1c0/128 scope link valid_lft forever preferred_lft forever
The other end of the tunnel isn't even accessible - something is almost surely dropping protocol 41 between my linux router and the other end:
root@ns:/var/log# ping6 -c1 2001:470:7:937::1PING 2001:470:7:937::1(2001:470:7:937::1) 56 data bytes --- 2001:470:7:937::1 ping statistics ---1 packets transmitted, 0 received, 100% packet loss, time 0mseven though the other end *is* accessible via ipv4:
root@ns:/var/log# traceroute 216.66.22.2traceroute to 216.66.22.2 (216.66.22.2), 30 hops max, 60 byte packets 1 172.16.0.1 (172.16.0.1) 1.531 ms 1.611 ms 1.752 ms 2 108-235-240-2.lightspeed.brhmal.sbcglobal.net (108.235.240.2) 38.731 ms 38.869 ms 40.380 ms 3 * * * 4 12.83.101.137 (12.83.101.137) 33.630 ms 37.886 ms 38.014 ms 5 12.122.117.97 (12.122.117.97) 41.792 ms 41.912 ms 42.236 ms 6 192.205.33.42 (192.205.33.42) 40.817 ms 39.434 ms 39.599 ms 7 hurricane-ic-138358-atl-bb1.c.telia.net (213.248.71.66) 43.438 ms 38.247 ms 34.084 ms 8 10ge16-5.core1.ash1.he.net (184.105.213.109) 49.286 ms 46.937 ms 47.745 ms 9 tserv2.ash1.he.net (216.66.22.2) 49.579 ms 49.727 ms 50.064 ms
[1] http://www.dslreports.com/forum/r28425971-new-firmware-6.9.1.42-enh.tm-he.net-tunnel-no-longer-works.
↧