If the tunnel worked all the way up to the wireless card, in front of this second NAT you configured, you'd need to look at how that NAT got set up. You could packet capture on that system and see if Protocol 41 packets are making their way out of the virtual lab and out that wireless card.

So you have DOUBLE NAT it sounds like. So now you need to make certain that both NATs "between loopback card and wireless card" as well as the device with 197.15.27.141 configured on it aren't filtering Protocol 41. Also the word is "connection".

Lets try this again. Your Cisco emulator has an RFC1918 IP address. What is acting as the NAT gateway for that IP range? What is the 192.168.137.1 device?

I use nat to share connexion to GNS3

I started playing with IPv6 just when I moved my nameserver to he.net and I find this certification quiz. Somehow it's odd to change again the nameservers at Registrar just to complete this process.

This has nothing to do with your domain's registration, but the reverse delegation of the IPv6 address space you are trying to use.

Authoritative name servers for your domain are the next 2 steps after this test, and if you use HE, will pass.

I have dynamic IP from my ISP and I don't believe they 'll delegate

Ask anyways, especially since you delegate to hostnames and not IPs. Use some sort of DynDNS system (in fact dns.he.net offers one).

In fact, create a host record in your domain for something like "ns#.trst.ro" with an IPv6 address (maybe even IPv4 too!), because that is the last step anyways for the IPv6 Glue test.
That IPv6 address could be your IPv6 address!
Then they delegate to that specific hostname!
Then you spin up a DNS server that serves reverse zones, and pass with flying colors!

Why not email the people responsible for delegating rDNS for the IPv6 range instead? Maybe ask them to, oh just a wild idea here, DELEGATE rDNS to ns1-5.he.net so you can use dns.he.net to host your reverse zones. Or in the interest of science, maybe learn how to set up a nameserver and host your own rDNS zone

The IPv6 certification tests DO NOT perform direct lookups against ns1-5.he.net.

Code:

dig -x 2a02:2f0e:3030:c0:: +trace

; <<>> DiG 9.8.1-P1 <<>> -x 2a02:2f0e:3030:c0:: +trace
;; global options: +cmd
.                       83443   IN      NS      h.root-servers.net.
.                       83443   IN      NS      k.root-servers.net.
.                       83443   IN      NS      c.root-servers.net.
.                       83443   IN      NS      g.root-servers.net.
.                       83443   IN      NS      i.root-servers.net.
.                       83443   IN      NS      b.root-servers.net.
.                       83443   IN      NS      d.root-servers.net.
.                       83443   IN      NS      e.root-servers.net.
.                       83443   IN      NS      f.root-servers.net.
.                       83443   IN      NS      l.root-servers.net.
.                       83443   IN      NS      j.root-servers.net.
.                       83443   IN      NS      m.root-servers.net.
.                       83443   IN      NS      a.root-servers.net.
;; Received 449 bytes from 127.0.0.1#53(127.0.0.1) in 474 ms

ip6.arpa.               172800  IN      NS      d.ip6-servers.arpa.
ip6.arpa.               172800  IN      NS      b.ip6-servers.arpa.
ip6.arpa.               172800  IN      NS      a.ip6-servers.arpa.
ip6.arpa.               172800  IN      NS      e.ip6-servers.arpa.
ip6.arpa.               172800  IN      NS      f.ip6-servers.arpa.
ip6.arpa.               172800  IN      NS      c.ip6-servers.arpa.
;; Received 462 bytes from 2001:500:2f::f#53(2001:500:2f::f) in 25 ms

0.a.2.ip6.arpa.         86400   IN      NS      ns3.nic.fr.
0.a.2.ip6.arpa.         86400   IN      NS      pri.authdns.ripe.net.
0.a.2.ip6.arpa.         86400   IN      NS      sec1.apnic.net.
0.a.2.ip6.arpa.         86400   IN      NS      sec3.apnic.net.
0.a.2.ip6.arpa.         86400   IN      NS      sns-pb.isc.org.
0.a.2.ip6.arpa.         86400   IN      NS      tinnie.arin.net.
;; Received 246 bytes from 2001:43f8:110::11#53(2001:43f8:110::11) in 342 ms

0.f.2.2.0.a.2.ip6.arpa. 172800  IN      NS      ns2.rdsnet.ro.
0.f.2.2.0.a.2.ip6.arpa. 172800  IN      NS      ns.ripe.net.
0.f.2.2.0.a.2.ip6.arpa. 172800  IN      NS      ns1.rdsnet.ro.
;; Received 204 bytes from 2001:dc0:1:0:4777::140#53(2001:dc0:1:0:4777::140) in 606 ms

0.f.2.2.0.a.2.ip6.arpa. 86400   IN      SOA     ns1.rdsnet.ro. dns-adm.rdsnet.ro. 2013020600 10800 3600 1209600 86400
;; Received 147 bytes from 193.231.236.17#53(193.231.236.17) in 194 ms

So what is the NAT/firewall/router appliance upstream of this? Because there is a chance it is filtering Protocol 41 to hosts behind it. Otherwise your config looks correct aside from a missing default IPv6 route. The HE side definitely responds when pinged.

What was the GW's previous distro/kernel rev before the reinstall you are going to perform?

You mean you tried using 2000::/3 right? 2003::/3 isn't a default route, nor is it a /3 allocation

I'd email HE and have them verify the static route for your routed /64 is correctly in place, and no other dupes configured on the tserv. Also maybe ask them to manually tear down the tunnel on their side, and rebuild either using their lovely automated scripts, or by hand. I'd do that before deleting the tunnel and trying to create another one as suggested on ipv6-ops.

Ok so, if you tcpdump on the router's LAN interface are you seeing the traceroute packets from the LAN PCs make it to that interface?
Can the router ping/reach the LAN machines?
I know you already pasted your sysctl setting for forwarding, but can you make certain it has taken effect either by examining sysctl -a output, or checking in /proc?
And the last-ditch idea I can think of is, are any of these boxes running an RHEL variant that might be using kernel 2.6.18? That had a broken default route issue, where you had to specify 2000::/3 instead of "default" or ::/0

Ok well seeing as this is in my ipv6-ops folder as well, after you try Eric's suggestion of pinging multicast, if you renumber back to ULA, does it all work?

Unknown host sounds like perhaps whatever version you are using can't handle IPv6 literals? I just tested that command against my own machines and it worked fine.

Code:

iperf version 2.0.5 (08 Jul 2010) pthreads

A reason not to obfuscate is in case we want to try reachability tests, and making sure there aren't any typos in the addresses. Like making certain we see 2001:470:XXX2:524::5 is reachable, thus confirming your static route upstream is in place.

Regardless, if your machines on the LAN can't ping each other, something is amiss. Did you have any ip6tables rules on your linux machines for allowing the ULA space, or at all?

No compression, no encryption. What are "they" saying the disadvantages are and who are "they". Name and shame. You could use iperf to test throughput.

If you got your HE tunnel to work, that means your Cisco responded to ICMP. The IPv4 endpoint only has to respond to ICMP at the time of creation, not forever. So if you got the tunnel working, swapped out the Cisco for original CPE, and the tunnel stops working, that sounds more like Protocol 41 is getting blocked by that device. If the CPE/modem was actually configuring 6to4 on itself and handing out RAs to the LAN, then that isn't Protocol 41 being passed behind it to hosts. At that point it is treated like native IPv6 on the LAN portion.

So to recap in order of steps tried:

1) existing CPE/modem filters ICMP, can't create tunnel
2) replace CPE/modem with Cisco, ICMP works and tunnel gets created and works
3) put back in old CPE/modem, and tunnel stops working

Unless you deleted your tunnel after getting it working with the Cisco, it should still be configured on HE's side. If this is the case then definitely that CPE/modem does more than filter ICMP, it filters Protocol 41 tunnels to hosts behind it. You'll definitely need to use UDP based tunnels if you have to use that CPE/modem. Options at that point are Teredo, GOGO6, Sixxs.