IPv6 Tunneling

Can you never generate inbound traffic or does it just fail after a short period of time? I got caught by the latter when setting up some tunnels of my own, where I could communicate for a bit but then it would stop, at least until I generated some further outbound traffic first.

One thing to watch out for when tunneling is that while the IPv6 traffic is subject to your IPv6 packet filter chains, the tunnel itself is IPv4 and thus remains subject to any IPv4 filter chains you may have established. So if your filtering configuration has inbound restrictions based on connection tracking ("related"), for example, then it may start blocking inbound connections after a period without any outbound traffic.

The solution to this is to make sure that your IPv4 filters have a general permission rule for any protocol 41 traffic (or at least a specific rule for your tunnel endpoints), that is not subject to connection tracking. For example, a global accept rule early in the input chain for protocol 41 will do it. Once that's in place, you can use the IPv6 chains for any further control.

– David

I am able to send data from it all the time, but I can not connect to it, even though the single AAAA with no A so it doesn't use IPv4, I have also asked other people who have IPv6, but they can not connect either, or ping it, but they can resolve the IP

@MartyniP:

I am able to send data from it all the time, but I can not connect to it, even though the single AAAA with no A so it doesn't use IPv4 (…)
With a tunnel you're always using IPv4 under the covers. Even if someone is trying to connect to a published AAAA address, to do so goes to your tunnel provider, which wraps it in an IPv4 packet, sends that to your Linode, which unwraps it, then treats it like an IPv6 packet arriving on your virtual tunnel interface. But it shows up at your Linode's public interface as an IPv4 packet.

So all of your IPv6 traffic will hit any IPv4 filtering configuration you have (it'll show up as a protocol 41 packet between your Linode's public address and the tunnel provider's tunnel endpoint IPv4 address). That may still not be your problem, but if you do have filters, a quick test would be to drop them (both iptables and ip6tables), then see if you can make a connection. Then you can figure out what's getting in the way.

If you're not, I'd also use ping6 as a test, as opposed to anything higher level. If you can get an icmpv6 packet through, the issue may be more on the application side for whatever is supposed to receive the inbound traffic.

– David