FAQ : Connectivity (Tunnels and Subnets) : My tunnel goes down after some idletime. My tunnelendpoint also is a NAT/Connection Tracker
My tunnel goes down after some idletime. My tunnelendpoint also is a NAT/Connection Tracker
Packet filters keep state for each connection that it tracks. This is also used for NAT. Normally, hosts track everything that goes out of their egress ('outside') interface. This way, also the proto-41 packets to the tunnelserver end up in a state table. After some time, this state times out, because it is not being used and thus renders the IPv6 tunnelconnection unusable. Packets from PoP thus can't enter your host any more and thus your connection dies off. It becomes alive again when you start generating traffic from your end and thus create state.
Several people have commented on this behavior in our Forum. Please read up on this one for example. The bottom line is that if you make sure the proto-41 traffic to the PoP does not enter a state table, or that your state table can be refreshed by incoming packets (such as our ICMPv6 echo requests), your filter will pass the proto-41 traffic and your connection will remain available.
Find below a list of possible solutions for various platforms.
If your platform is not listed below check the manual of the platform for a similar solution and/or contact the vendor of your platform when in doubt.
When you are using NAT (Masquerading), then you should avoid NATting the proto-41 packets, this keeps them outside of the connection tracking table:
A better solution, when the NOTRACK option for iptables is available:
FreeBSD/OpenBSD (using pf)
Applying the following ruleset to pf.conf and reloading the set, resolves this issue.
Having a rule which explicitely allows traffic on both IPv6 and IPv4 from the PoP is a good idea.