ICMP filtered hinter FritzBox beheben
- Ersteller Lurtz
- Erstellt am
Raijin
Fleet Admiral
- Registriert
- Nov. 2007
- Beiträge
- 18.285
Hab ich eigentlich etwas verpasst oder geht es dir einzig und allein um den Test bei ipv6-test.com? Ich habe bisher noch nichts davon gelesen, dass du irgendwelche handfesten Probleme hast, irgendetwas nicht geht außer dem besagten Test. Oder geht es dir jetzt generell um die Technik? 
- Registriert
- Sep. 2005
- Beiträge
- 1.228
Wie gesagt, es geht mir um die Aussage, dass man laut mehrerer Quellen und laut Spezifikation einen funktionierenden Ping6 für IPv6 braucht.
Daher die Frage, wieso quasi keine (Endkunden)-Hard- und Software dies gewährleistet und welche Auswirkungen das hat.
Daher die Frage, wieso quasi keine (Endkunden)-Hard- und Software dies gewährleistet und welche Auswirkungen das hat.
Auf welche Spezifikation (welcher Abschnitt im RFC 4890) und/oder Quellen stützt du dich dabei? Wär mir neu das IPv6 um zu funktionieren einen Bidirektionalen funktionierenden IPv6 Ping benötigt.
Davon ab das die Fritzbox z.B. externe IPv6 Pings normal nicht rejected oder dropped sondern selbst entsprechend antwortet.
(Ping von extern auf eine IP von einem Client bei mir daheim hinter einer Fritzbox)
Davon ab das die Fritzbox z.B. externe IPv6 Pings normal nicht rejected oder dropped sondern selbst entsprechend antwortet.
(Ping von extern auf eine IP von einem Client bei mir daheim hinter einer Fritzbox)
Code:
~# ping6 2001:xxx
PING 2001:xxx(2001:xxxe) 56 data bytes
From 2001:xxx: icmp_seq=1 Destination unreachable: Administratively prohibited
Zuletzt bearbeitet:
- Registriert
- Sep. 2005
- Beiträge
- 1.228
Laut Wikipedia:Harrdy schrieb:
https://de.wikipedia.org/wiki/ICMPv6
Oder gilt das nur bis zum Router? Das erklärt aber nicht, wieso der Webbrowser-Test dann bis zum Client testet.
Das ist nicht an. Heute funktioniert es auch wieder nicht mehr, egal was ich unter Freigaben einstelleBob.Dig schrieb:
Lurtz schrieb:
Das generelle Blocken ja, aber ICMPv6 besteht ja aus mehr als nur Echo Request und Echo Reply
| 128 | Echo Request | RFC 4443 |
| 129 | Echo Reply | RFC 4443 |
| 130 | Multicast Listener Query | RFC 2710 und RFC 3810 |
| 131 | Version 1 Multicast Listener Report | RFC 2710 |
| 132 | Multicast Listener Done | RFC 2710 |
| 133 | Router Solicitation | RFC 4861 |
| 134 | Router Advertisement | RFC 4861 |
| 135 | Neighbor Solicitation | RFC 4861 |
| 136 | Neighbor Advertisement | RFC 4861 |
| 137 | Redirect | RFC 4861 |
| 138 | Router Renumbering | |
| 139 | ICMP Node Information Query | RFC 4620 |
| 140 | ICMP Node Information Response | RFC 4620 |
| 141 | Inverse Neighbor Discovery Solicitation Message | RFC 3122 |
| 142 | Inverse Neighbor Discovery Advertisement Message | RFC 3122 |
| 143 | Version 2 Multicast Listener Report | RFC 3810 |
| 144 | Home Agent Address Discovery Request Message | RFC 3775 |
| 145 | Home Agent Address Discovery Reply Message | RFC 3775 |
| 146 | Mobile Prefix Solicitation | RFC 3775 |
| 147 | Mobile Prefix Advertisement | RFC 3775 |
| 148 | Certification Path Solicitation Message | RFC 3971 |
| 149 | Certification Path Advertisement Message | RFC 3971 |
| 150 | ICMP messages utilized by experimental mobility protocols such as Seamoby | RFC 4065 |
| 151 | Multicast Router Advertisement | RFC 4286 |
| 152 | Multicast Router Solicitation | RFC 4286 |
| 153 | Multicast Router Termination | RFC 4286 |
| 155 | RPL Control Message | RFC 6550 |
| 200 | Private experimentation | |
| 201 | Private experimentation | |
| 255 | Reserved for expansion of ICMPv6 informational messages |
Security by Obscurity hat noch nie wirklich funktioniert und darauf sollte man sich auch nicht verlassen.Bob.Dig schrieb:
@Harrdy hat ja netterweise alle möglichen Typen verlinkt, echo request/reply kann man meiner Meinung nach blocken wenn man möchte aber gerade so Dinge wie Router Advertisement und/oder Neighbor Discovery und was halt noch so notwendig ist für einen stabilen Betrieb sollte man weiterhin durch lassen.
