Tunnel drops packets on floor

[jacinth]

I just got a H.E. IPv6 tunnel and am trying to learn how to make it work, following suggestions from forum posts describing similar but not identical symptoms.  I'm starting with just one machine at my end, which will become the LAN to IPv6 router.  I do "ping6 $addr6" or try an IPv6 website, IPv6 packets go out on the point-to-point interface, but no corresponding IPv4 packets are produced and, of course, there are no replies.
    I have forwarding enabled: cat /proc/sys/net/ipv4/ip_forward /proc/sys/net/ipv6/conf/all/forwarding both show 1.  Modules ipv6.ko, tunnel4.ko and sit.ko are loaded (on my distro with kernel 2.6.22.18, sit.ko had to be loaded by hand, haven't figured out why yet).  I followed instructions to set up the tunnel:

ip tunnel add he-ipv6 mode sit remote 72.52.104.74 local 128.97.4.125 ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f04:844::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6

The resulting addresses and routes look reasonable:

ip -f inet6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 100
    inet6 fe80::221:70ff:fe31:cf5c/64 scope link 
       valid_lft forever preferred_lft forever
4: he-ipv6@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 
    inet6 2001:470:1f04:844::2/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::8061:47d/128 scope link
       valid_lft forever preferred_lft forever

ip -f inet addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100
    inet 128.97.4.125/24 brd 128.97.4.255 scope global eth0

route -A inet6
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
2001:470:1f04:844::/64                      ::                                      U     256    19       0 he-ipv6 
fe80::/64                                   ::                                      U     256    0        0 eth0    
fe80::/64                                   ::                                      U     256    0        0 he-ipv6 
::/0                                        ::                                      U     1024   0        0 he-ipv6 
::1/128                                     ::                                      U     0      78       1 lo      
2001:470:1f04:844::2/128                    ::                                      U     0      0        1 lo      
fe80::8061:47d/128                          ::                                      U     0      0        1 lo      
fe80::221:70ff:fe31:cf5c/128                ::                                      U     0      0        1 lo      
ff00::/8                                    ::                                      U     256    0        0 eth0    
ff00::/8                                    ::                                      U     256    0        0 he-ipv6 

When I ping any IPv6 address (other end of the tunnel is shown), tcpdump shows this:

tcpdump -i he-ipv6 -l
listening on he-ipv6, link-type RAW (Raw IP), capture size 96 bytes
10:47:20.464266 IP6 jacinth-1-pt.tunnel.tserv3.fmt2.ipv6.he.net >   \
    jacinth-1.tunnel.tserv3.fmt2.ipv6.he.net: ICMP6, echo request, seq 1, length 64

But when I look at the outgoing interface I see only irrelevant local chatter, nothing going to H.E.

tcpdump -i eth0 -l not port ssh
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
10:49:51.946241 STP 802.1d, Config, Flags [none], bridge-id 8000.00:0c:cf:99:0c:60.204e, length 51
10:49:51.981571 arp who-has psnet-gw-4.math.ucla.edu tell maunakea.math.ucla.edu
etc. etc.

The result is the same even with iptables (ipv4) cleared; I do not (yet) have any ip6tables rules.  Obviously the SIT tunnel is not turned on at my end.  Does anyone have an idea what I left out?  :'(

[broquea]

Tried pinging 2001:470:1f04:844::2 from the tunnel-server, got no reply, guessing it is down ATM. Everything looks correct for bringing up the tunnel, and the configuration for the tunnel on the tunnel-server is correct as well.

I'd try setting 2000::/3 as the default route instead of ::/0 and see if that makes any difference.

When the tunnel was up, were you able to ping6 2001:470:1f04:844::1, or did that fail as well?

[jacinth]

  >:( Problem number 1: my tcpdump expression "not net 128.97.0.0/16" also suppressed the desired packets.  When I changed to "host 72.52.104.74" I started seeing packets (presumably IP-in-IP, protocol 4) generated by my box going to the tunnel endpoint and containing ICMP6 payload, when I did "ping6 2001:470:1f04:844::1"

[20:36:09.378845 IP simba.math.ucla.edu > tserv3.fmt2.ipv6.he.net: IP6 jacinth-1-pt.tunnel.tserv3.fmt2.ipv6.he.net > jacinth-1.tunnel.tserv3.fmt2.ipv6.he.net: ICMP6, echo request, seq 1, length 64
20:40:52.140548 IP 128.97.4.125 > 72.52.104.74: IP6 2001:470:1f04:844::2 > 2001:470:1f04:844::1: ICMP6, echo request, seq 1, length 64
/pre]

The reason I used the (incorrect) expression was that I saw when setting up the tunnel that a host other than 72.52.104.74 pinged my endpoint, and I wanted to make sure to catch any monitoring host while the tunnel was in use, since my end has its own firewall (IPv4).  (But the replies were not received even with that firewall cleared.)
    Problem number 2: the whole LAN is behind a Cisco router whose ruleset knows nothing of either IPv6 nor IP-in-IP.  If it were a Linux (e.g. Vyatta) box, conntrack would take note of my outgoing packets and accept H.E.'s replies, but I really doubt that the old Cisco klunker is that smart.  Plan A: get my boss to add a rule letting protocol 4 go through (that is the correct protocol, right?)  Plan B: test it on my home server where I control iptables. 
    The problem with plan B is, I have an aleatory IPv4 address (DHCP).  It doesn't change very often, but I didn't pay for a static IP and they aren't giving me one for free.  This is like the "road warrior" scenario in IPSEC: an authorized user might connect from different addresses, not knowable in advance, on different days.  OpenS/WAN and OpenVPN can deal with this, but does the H.E. tunnel machinery have any formal support for aleatory client addresses?
    This would all be a lot simpler if my ISP, Verizon DSL, supported IPv6.

[jacinth]

Continuing...  I see your reply to Randomandy (asking about AYIYA) pointing him to https://ipv4.tunnelbroker.net/ipv4_end.php .  That's exactly what I need.  Thank you.

[broquea]

Plan A: get my boss to add a rule letting protocol 4 go through (that is the correct protocol, right?)

Protocol 41