|
100% packet loss, until I pinged?
![[si]](/s/countries/si.gif) Shadow Hawkins on Wednesday, 10 June 2009 13:30:21
Hi!
In the statistics for my tunnel (T14647) is shows 100% packet loss for the last 7 days (except a 12 hour period around 6-jun-2009).
A few hours ago I logged into my endpoint (home router running AICCU) over IPv4 and pinged (successfully) a few IPv6 addresses (google, kame,...).
After that my status page shows 0% packet loss.
Is the status check broken ? Or did my endpoint "fall asleep" and needed a "kick" ?
I am not opening a ticket, because now everything works and I do not need the tunnel these days anyway.
Regards,
David
100% packet loss, until I pinged?
100% packet loss, until I pinged?
Shadow Hawkins on Tuesday, 16 June 2009 20:22:30
Thanks.
It seems to work.
My modem dropped the line today.
How do I check that the iptables rule is still active ?
The command I used to set it was:
iptables -t nat -A POSTROUTING --proto ! 41 -o ppp0 -j MASQUERADE
I remember last time I saw the setting in the output of "iptables -L", but today I can not find it. I tried "iptables -t nat -L" too.
Any idea ? I am not good at iptables (managed to avoid it for years...).
Regards,
David
100% packet loss, until I pinged?
Shadow Hawkins on Thursday, 18 June 2009 14:38:11
Ah, it is there in "iptables -t nat -L" , but iptables is "smart" and converts "proto 41" to "ipv6", so "grep 41" did not find it ...
100% packet loss, until I pinged?
Shadow Hawkins on Wednesday, 24 June 2009 15:48:52
I suggest an addition to the FAQ to clarify a few things.
The FAQ recommends (for linux, I don't have BSD):
iptables -t nat -A POSTROUTING --proto ! 41 -o [Your IPv4 Interface] -j MASQUERADE
But it fails to mention that in the common case (NAT setup) there is already a more general rule, like:
iptables -t nat -A POSTROUTING -o [Your IPv4 Interface] -j MASQUERADE
which catches all packets before the proto 41 one, so the new rule makes no difference at all.
Solutions:
- delete the old rule and add the new one (must be done on each boot)
or
- find where the old rule is added and change it with the new one (might need a reboot or reconnect, or the first option, to become effective)
Another option might be a special rule to allow proto 41 traffic from the POP... I did not investigate this possibility.
Regards,
David
100% packet loss, until I pinged?
Shadow Hawkins on Thursday, 09 July 2009 15:12:41
OK, more data.
Even after the measures described above, I got problems (remote host could not send my IPv6 traffic).
It seems the problem is not MASQUERADING, but simply blocked input traffic (I hate firewalls ;-).
So "opened the port" :
iptables -A input_wan --proto 41 -s 212.18.63.73 -j ACCEPT
212.18.63.73 is simbx01.sixxs.net, my POP for the tunnel.
I also removed the proto 41 exception to the MASQUERADE rule, as it does not seem to be necessary.
I'll report in a day, if everything remained in working state ...
Regards,
David
100% packet loss, until I pinged?
Shadow Hawkins on Saturday, 11 July 2009 00:35:15
I am confirming that the ebove setting fixes the problem. My tunnel is pinging fine since then, wihout any activity started from my end of tunnel.
I also discussed this with netfilter people (ntfilter mail list).
So maybe the FAQ entry could be updated/adapted.
Regards,
David
100% packet loss, until I pinged?
Shadow Hawkins on Monday, 13 July 2009 12:54:11
The tunnel continues to work.
What is the procedure to update the FAQ entry, as it is clearly wrong ?
Regards,
David
100% packet loss, until I pinged?
If you have configured your firewall to DROP the tunneled packets, then indeed you also need to specifically ALLOW those packets.
As most people configure their firewalls with an "ALLOW" and not a "DROP", the tracking rule applies.
The FAQ is thus not wrong, it is just not applicable to your problem, as your problem is with a misconfigured firewall.
100% packet loss, until I pinged?
Shadow Hawkins on Monday, 13 July 2009 14:16:21
The majority of firewalls DROP packets by default.
Letting certain packets in requires an explicit manual configuration.
After the protocol 41 packets are allowed on firewall, the MASQUERADE rules are irrelevant as they affects only traffic passing through the router. If the tunnelendpoint is on the router itself, then that is not the case.
So:
- the FAQ suggestion about MASQUERADE is meaningless regarding the question ("My tunnelendpoint also is a NAT/Connection Tracker")
- many people have a firewall and they block by default, so it would help people to mention that "hole" must be configured for the tunnel
Regards,
David
100% packet loss, until I pinged?
The majority of firewalls DROP packets by default.
iptables, ipfw, pf, Windows Firewall all have a default policy of ALLOW.
Thus no, that is definitely not the case.
- the FAQ suggestion about MASQUERADE is meaningless regarding the question ("My tunnelendpoint also is a NAT/Connection Tracker")
It is not meaningless, as THAT is the problem other people run into.
You are having a problem with your firewall settings, and indeed then the above FAQ item does not apply. The Firewall item does apply to your situation.
- many people have a firewall and they block by default, so it would help people to mention that "hole" must be configured for the tunnel
Then those people will read the Firewall FAQ and see what to open.
If you are going to DROP packets, then that is your wish to do so. No FAQ can protect against stupid people.
Do you want use to make a single-page FAQ maybe with all the details on one page? That would solve your problem, but not that of any other people.
|
![[ch]](/s/countries/ch.gif)
on Wednesday, 10 June 2009 14:19:42
Posting is only allowed when you are