IPv6 Router and NAT/connection tracking
Hello all, I have a box that's configured as a firewall and router for IPv6, which is doing it's job fine, well, fine.., IPv6 connections keep timing out, they work for a second or 30 and then it timesout -> connections, ping6, traceroutes, ... from the Internet to the IPv6 address behind the router don't work anymore. Also if I do a ping6 or make a connection to a remote IPv6 host on the Internet it doesn't work, however if I ping6 the router from the network, everything works again...for about 30 seconds again, and then the problem begins again...
I was told that this is caused by NAT/connection tracking. Is there *any* solution to this? This is really annoying as I *need* NAT, but also want to give IPv6 connectivity to other machines on the LAN.
-----------------------------------------------------
Mail.be, WebMail and Virtual Office
http://www.mail.be
Quoted 12 lines · Internet Protocol version Six
Hello all, I have a box that's configured as a firewall and router for IPv6, which is doing it's job fine, well, fine.., IPv6 connections keep timing out, they work for a second or 30 and then it timesout -> connections, ping6, traceroutes, ... from the Internet to the IPv6 address behind the router don't work anymore. Also if I do a ping6 or make a connection to a remote IPv6 host on the Internet it doesn't work, however if I ping6 the router from the network, everything works again...for about 30 seconds again, and then the problem begins again...
Quoted 4 lines
I was told that this is caused by NAT/connection tracking. Is there *any* solution to this? This is really annoying as I *need* NAT, but also want to give IPv6 connectivity to other machines on the LAN.
Are you directly connected to an IPv6 router, or are you connecting via an ipv6_over_ipv4 tunnel of some sort?
If you are direct, then I think all you need to do is work with ip6tables. (not sure, not done this)
If you are using a tunnel, then that tunnel will either be using a specific protocol or port number, which you could explicitly ACCEPT in all directions to avoid conntrack interference. For example, tspc (freenet6.net) uses TCP 4343 to talk to the server to create the tunnel, and the tunnel itself is protocol 41.
j