Probably those filters mean nothing to you. Most providers with such filters don't inspect what's inside tunnels (and they really have no business inspecting anyway, since those IPs are not theirs in the first place). I tried to traceroute your IP address 2001:470:1f07:4e8::10 with a few different packets, and I got no reply with any of the packets I tried.
My first three guesses at what may be going on are:
1. Your tunnel is going through a NAT and you would need to ping the tunnel server frequently to keep the NAT entry active and ready for incoming packets.
2. You are running an IPv6 firewall on your own tunnel endpoint, and that is blocking the packets.
3. You got your own IPv6 address wrong when setting up the AAAA record.
I also tried a traceroute to 2001:470:1f06:4e8::1, which I assume is the server side of your tunnel, and that worked all the way.
I also tried a traceroute to 2001:470:1f06:4e8::2, which I assume is the client side of your tunnel, and that failed the same as tracing the IPv6 address from your AAAA record.
If you have checked that none of the above three are the reason, then let us know, and we'll investigate a bit further. You can check what your IPv6 address is on my test page http://netiter.dk/test-ipv6
or just go to google and search for "what is my ip".
I am considering putting up a webserver that automatically will perform a traceroute back to the client it was accessed from using SYN ACK packets with varying hop limit. That would allow a webservice to perform such a traceroute in a way that bypass practically every blocking mechanism. If you think that would be useful in debugging your issue, please let me know. But it would be at least a week or two before I find time to actually implement it.