|
Linux static SIT tunnel losing reachability % (T44081)
![[gb]](/s/countries/gb.gif) Shadow Hawkins on Tuesday, 26 October 2010 12:14:17
I have recently just got my tunnel setup (not subnet). The setup script is based on http://wiki.archlinux.org/index.php/IPv6_-_6in4_Tunnel and it seems to be working fine. I can ping6/traceroute6 and DNS/bind is happily using IPv6 for real work.
I have a tcpdump running to assist looking out for problems.
I can see the PoP periodically pinging and my replies go back out.
However it seems after a period of no activity (i.e. my end does not transmit any packets into the tunnel) that the tcpdump indicates the inbound ICMPv6 Echo Request but there is no Reply generated.
When this condition occurs if I were to ping6 the PoP router (the IPv6 IP inside other end of the tunnel) then I always get 100% replies. The next ping made by the tunnel gets a reply from me.
Having now waited and watched this process occur multiple times, I can clear say there is some kind of problem with the Linux kernel 2.6.24.3. If I were to make a guess it is like some kind of ARP/neigh resolution process drops a stable neighbour entry and from that point on ping replies are not returned. But obviously the tunnel is a NOARP POINTOPOINT link.
The MRTG graphs posted against my Tunnel (T44081) on the SixXS website do indicate packet loss during those times.
If anyone aware of such an issue ? I can create / post a 24 hours tcpdump of all traffic inside the tunnel to/from the Pop router if that would help.
Also when I first had the tunnel working some "fe80::4d4b:687e > ff02::1: HBH icmp6: multicast listener query max resp delay: 2000 addr: :: [hlim 1]" were being sent every 2 minutes or so. When I started up RADVD my end started to reply with "fe80::5d61:a826 > ff02::16: HBH icmp6: type-#143 [hlim 1]". However I understand these to be multicast related and the daemon for that is MRD6 but my PoP has a "Multicast: No" option.
Those packets has stopped being send now shortly since my comment the the IRC channel (maybe coincidence).
Can anyone advise exactly what the packets were and what best practice is relating to them.
I am not actively looking to perform multicast over my WAN&tunnel.
Linux static SIT tunnel losing reachability % (T44081)
However it seems after a period of no activity (i.e. my end does not transmit any packets into the tunnel) that the tcpdump indicates the inbound ICMPv6 Echo Request but there is no Reply generated.
See: FAQ: My tunnel goes down after some idletime. My tunnelendpoint also is a NAT/Connection Tracker
Linux static SIT tunnel losing reachability % (T44081)
Shadow Hawkins on Tuesday, 26 October 2010 14:26:19
Thanks for this, it definitely looks like that is the issue IPv4 layer connection tracking.
I have not used NOTRACK before it I guess it marks the packets individually with a flag that makes the connection tracker skip any connection state updating.
But it doesn't actually permit packets through if you have a stateful inspection firewall rules in place. Which is actually the mechanism which is DROPing the packets.
Using NOTRACK in this way is contrary advice IMHO. If you have a stateful inspection firewall that DROPs packets by default (with there is no state) and then you use NOTRACK in this way, then you will NEVER get the tunnel to work.
So:
iptables -t raw -A PREROUTING -j NOTRACK --proto 41 -s <remote_ipv4_pop_endpoint_addr>
iptables -t raw -A OUTPUT -j NOTRACK --proto 41 -d <remote_ipv4_pop_endpoint_addr>
The above rules will stop making any entry appear in the connection state table for the PoP tunnel. But it does not fix the problem in anyway the FAQ item describes.
I found I only needed to add an entry:
iptables -I INPUT 1 -i <wan_ingress_iface> -j ACCEPT -s <remote_ipv4_pop_endpoint_addr> -p 41 -m state --state NEW
[ Even the "-m state --state NEW" can be considered optional and unnecessary ]
This rule instructs the stateful inspection part of the firewall system that it is allowed to ACCEPT packets of proto-41 from the PoP, which has the effect of creating a new connection tracking entry.
Note the above rule is the only rule needed and no use of the -j NOTRACK is necessary if you want a working stateful inspection firewall on Linux.
I also believe this is the best advise to anyone and the FAQ item should be updated.
It is my understanding that the Linux connection tracker is a passive component by default, it only actually affects firewall decisions when there is one or more rules in place to make use of the information. For example to DROP packets for which there is no valid connection tracking state. Because it is passive merely turning on connection tracking does not change the firewall behavior.
The default lifetime of a proto-41 connection tracking entry was 10 or 15 minutes.
Linux static SIT tunnel losing reachability % (T44081)
Not everything fits in one FAQ item, thus I point you to: I have a firewall, what ports/protocols are used?
Linux static SIT tunnel losing reachability % (T44081)
Shadow Hawkins on Tuesday, 26 October 2010 16:36:04
Thanks, I did prepare a technical reply but damn session cookie timed out on me and browser&websites being well designed things lost my data. Such is life.
I have gotten through the issue with the rule I showed in the previous post. Thanks for your help in this.
My advice to anyone with Linux is to ignore the proposed command lines to run to fix the issue from the article https://www.sixxs.net/faq/connectivity/?faq=conntracking (dated on and pre 26-Oct-2010) neither command line will address the problem explained in the text above it. Maybe those command lines were relevant to old versions of Linux or something.
You either want to:
* Ensure a refresh/create of your connection tracker state entry from all incoming proto-41 packets from the PoP. (my example with "-m state --state NEW")
* Ensure your "stateful inspection firewall" does not get a chance to exercise its DROP packet rule. (my example without "-m state --state NEW", by ensuring is has a high priority/first-to-run "-I INPUT 1")
In essence the solution is the same but can be describe in two ways.
You certainly never want to consider using NOTRACK unless there are other reasons for you need it. It certainly won't help towards a solution to the FAQ item.
The example in the FAQ of using "-j MASQUERADE" is completely irrelevant to the problem. NATing or not-NATing the packets does not affect the visibility of a connection flow to the connection tracker.
Linux static SIT tunnel losing reachability % (T44081)
neither command line will address the problem explained in the text above it
They solve the problem perfectly fine, unless, like in your setup, you are dropping packets.
Per default, that is not the case.
The example in the FAQ of using "-j MASQUERADE" is completely irrelevant to the problem.
It might be irrelevant to your problem, other people have different setups where that does apply. As the FAQ also states, at the time that section it was put in there a lot of distributions did not even have the NOTRACK target yet, which is the better solution to solve the problem.
NATing or not-NATing the packets does not affect the visibility of a connection flow to the connection tracker.
It does when you have an old kernel, as clearly stated there though, the NOTRACK version is preferred when that is available. There are though numerous people still running 2.4.x kernels which do not support that.
Linux static SIT tunnel losing reachability % (T44081)
Shadow Hawkins on Tuesday, 26 October 2010 18:36:10
Fair enough on the older kernel scenarios. But for a recent (~6 years) Linux 2.6.x kernel (I am testing with 2.6.24.3).
My claim (for those who might be looking to take something from the thread in the future) :
The command: iptables -t raw -A PREROUTING --proto 41 -j NOTRACK
This instructs Linux kernel not to "create a state entry" and not to "re-arm the timeout of an existing state entry" for any inbound packets of type proto-41.
This does not stop the Linux kernel from "creating a state entry" and "re-arming the timeout of an existing state entry" for outbound packets of type proto-41. So you will continue to see a connection tacking entry in the connection tracking tables (due to your outbound traffic). To inhibit that you also need to use "iptables -t raw -A OUTPUT --proto 41 -j NOTRACK" as well as. Hence my comment and example further up the thread.
Using the suggested iptables entry means (on Linux 2.6.24+): we get a degraded situation relative to the problem posed (that the timeout of a connection tracking state entry, causes loss of reachability of packet flow from The Internet to your tunnel endpoint). This is because instead of re-arming the timeout for EITHER inbound or outbound activity, the timeout is only re-armed for outbound traffic. This has the effect of making the total amount of time the connection tracking entry stays active marginally less than what it is without the rule in place.
Relative to the problem it still does not cause the kernel to pass any additional packets than it otherwise would have. If anything is makes the problem worse (as the entry is active for less time).
My scenario (again for those who might gleam something in future) :
Static IP endpoint, so I am using SNAT for IPv4 NAT (not MASQUERADE). I have enable Linux in a "stateful inspection firewall" mode. Tunnel is setup using SIT (proto-41).
The cause of "The Internet to my IPv6 endpoint losing reachability" was exactly that the IPv4 connection tracking state entry was timing out after 10 or 15 minutes of no activity. Then the PoP would fire a ping6 packet at me but my end would discard the packet due to the "stateful inspection firewall" drop rule.
I understand and accept things change (kernel behavior over time). But my point here is this is how things work today. So going forward it would seem useful to keep the info that exists but clearly mark it relevant to 2.4.x and/or kernel around the time it was posted.
Anyhow my problem is all sorted thanks again.
|
![[ch]](/s/countries/ch.gif)
on Tuesday, 26 October 2010 12:23:07
Posting is only allowed when you are