SixXS::Sunset 2017-06-06

Ticket ID: SIXXS #746293
Ticket Status: User

PoP: uschi02 - Your.Org, Inc. (Chicago, Illinois)

Heartbeat broken on uschi02
[us] Shadow Hawkins on Saturday, 14 June 2008 21:02:45
uschi02 does not seem to be accepting heartbeat messages from my client (tunnel T14140). Connectivity is good to the POP, but it does not have the correct IPv4 endpoint address, and I receive no packets over the link. I can send UDP packets on the correct port to other machines, so there do not appear to be any connectivity or firewalling issues Also, and this may be a security issue, I can send packets over the tunnel and receive them at a remote IPv6 host (verifying that I can send packets to the POP fine), despite it believing the tunnel endpoint to be somewhere else.
State change: user Locked
[ch] Jeroen Massar SixXS Staff on Saturday, 14 June 2008 21:14:05
Message is Locked
The state of this ticket has been changed to user
Heartbeat broken on uschi02
[ch] Jeroen Massar SixXS Staff on Saturday, 14 June 2008 21:16:06
Last Beat : 2008-06-13 02:01:39 (148327 seconds ago) You haven't send a valid heartbeat packet since then. Thus no, the tunnel won't work.
Also, and this may be a security issue, I can send packets over
the tunnel and receive them at a remote IPv6 host
(verifying that I can send packets to the POP fine),
despite it believing the tunnel endpoint to be somewhere else.
You can send which kind of packet over which tunnel, with which source and destination address (both inner-IPv6 and outer-IPv4 of course) ?
Heartbeat broken on uschi02
[us] Shadow Hawkins on Monday, 16 June 2008 00:22:32
Here is the output from ifconfig on the host. The same configuration has worked for the last year and stopped working suddenly several days ago. Nothing has changed on my end. Here's the tunnel configuration (FreeBSD system, the first set of addresses are the local endpoints): gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1450 tunnel inet 70.226.173.212 --> 216.14.98.22 inet6 fe80::202:6fff:fe45:19c9%gif0 prefixlen 64 scopeid 0x6 inet6 2001:4978:f:98::2 --> 2001:4978:f:98::1 prefixlen 128 If I ping6 another machine I control on a different connection (at 2001:4978:11f:d600::1), I can see the packets arriving with tcpdump. The replies don't make it back. If I then set up by hand a tunnel directly between these machines, I can pass packets without problems. I also tested sending UDP packets to port 3740 at the IPv4 address of several other hosts, in case my ISP was doing something dumb, and they arrived correctly. If there are any other tests I can do, please let me know.
Heartbeat broken on uschi02
[us] Shadow Hawkins on Monday, 16 June 2008 00:25:41
I should also note that the AICCU client is running (it configured the gif0 interface) and reports no errors. I've tried restarting it several times. Each time, it correctly contacts the tunnel server, sets the tunnel parameters, and fails with exactly the symptoms it failed with before.
Heartbeat broken on uschi02
[ch] Jeroen Massar SixXS Staff on Monday, 16 June 2008 13:19:24
Last Beat : 2008-06-13 02:01:39 (288133 seconds ago) In other words, you are not sending any proper heartbeats. And without proper heartbeats no tunnel.
Each time, it correctly contacts the tunnel server, sets the tunnel
parameters, and fails with exactly the symptoms it failed with before.
You are most very likely mixing terms up here and mean "TIC Server" instead of "Tunnel Server". A "Tunnel Server", the thing that "serves tunnels", is the PoP. Please read the contact page, it contains a "Reporting Problems Checklist" which asks for a list of things which you should try.
Heartbeat broken on uschi02
[us] Shadow Hawkins on Monday, 16 June 2008 15:24:48
I understand that my heartbeat packets are not being received. What I also know is that they are being sent, since I can watch them leave my machine with tcpdump. Here are the tests from the reporting problems page: aiccu test succeeds on every test until the one where it pings the remote tunnel endpoint. This is, of course, because the remote tunnel endpoint isn't set up correctly. aiccu is installed from FreeBSD ports, and was working correctly until 4 days ago. There are no firewalls or NATs between my router and your servers that I can discover (this was the reason for testing sending the UDP packets, which used the heartbeat protocol -- TIC seems to work perfectly, since AICCU finds and sets up the tunnel). uname -a: FreeBSD cepheid.tachypleus.net 7.0-CURRENT FreeBSD 7.0-CURRENT #4: Sat Sep 8 23:56:34 CDT 2007 root@mail.rh:/usr/obj/arm/usr/home/nathanw/src/sys/LIMULUS arm Relevant bits of ifconfig (ng0 is a PPPoE interface): ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492 inet 70.226.173.212 --> 70.226.175.254 netmask 0xffffffff inet6 fe80::202:6fff:fe45:19c9%ng0 prefixlen 64 scopeid 0x5 gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1450 tunnel inet 70.226.173.212 --> 216.14.98.22 inet6 fe80::202:6fff:fe45:19c9%gif0 prefixlen 64 scopeid 0x6 inet6 2001:4978:f:98::2 --> 2001:4978:f:98::1 prefixlen 128
traceroute uschi02.sixxs.net
traceroute to uschi02.sixxs.net (216.14.98.22), 64 hops max, 44 byte packets 1 ppp-70-226-175-254.dsl.mdsnwi.ameritech.net (70.226.175.254) 8.146 ms 7.613 ms 7.014 ms 2 68.249.70.66 (68.249.70.66) 7.699 ms 7.967 ms 7.418 ms 3 bb2-g8-0.mdsnwi.ameritech.net (65.42.115.116) 7.462 ms 8.260 ms 6.654 ms 4 69.220.8.49 (69.220.8.49) 12.944 ms 20.228 ms 12.921 ms 5 asn3320-t-systems.eqchil.sbcglobal.net (151.164.249.106) 13.139 ms 11.834 ms 22.046 ms 6 64.71.148.238 (64.71.148.238) 11.941 ms 12.710 ms 12.086 ms 7 sixxs.cx01.chi.bb.your.org (216.14.98.22) 12.567 ms 11.953 ms 12.960 ms IPv6 ping and traceroute fail, of course. Clock is synced with NTP (and, as I said, AICCU reports no errors on tunnel establishment). Here are the heartbeat packets going out over the wire, never to be received: cepheid# tcpdump -n -vv -i ng0 dst uschi02.sixxs.net tcpdump: listening on ng0, link-type NULL (BSD loopback), capture size 96 bytes 08:21:41.600498 IP (tos 0x0, ttl 64, id 49443, offset 0, flags [none], proto: UDP (17), length: 113) 70.226.173.212.57802 > 216.14.98.22.3740: UDP, length 85 08:21:41.601649 IP (tos 0x0, ttl 64, id 49444, offset 0, flags [none], proto: UDP (17), length: 113) 70.226.173.212.54818 > 216.14.98.22.3740: UDP, length 85 As I said earlier, I tested sending such UDP packets to other hosts with netcat, which were received perfectly, and implies my ISP isn't secretly filtering them.
Heartbeat broken on uschi02
[us] Shadow Hawkins on Monday, 16 June 2008 15:29:32
Well, somehow since I posted my last message, it has all resumed working again as suddenly as it stopped. If you fixed it, thanks. I remain completely at a loss.

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

Static Sunset Edition of SixXS
©2001-2017 SixXS - IPv6 Deployment & Tunnel Broker