[fli4l] ICMP

[Oma Voss]

On 03.05.2012 17:45, Oma Voss wrote:
> On 03.05.2012 16:09, Oma Voss wrote:
>> On 03.05.2012 10:55, Christoph Schulz wrote:
>>> Hallo!
>>
>> Hallo Christoph,
>>
>>> add_chain in-icmp
>>> add_rule filter in-icmp "prot:icmp:8 length:0-100 $limit ACCEPT"
>>> PF_INPUT_ACCEPT_DEF
>>> add_rule filter in-icmp "state:RELATED ACCEPT" PF_INPUT_ACCEPT_DEF
>>>
>>> Ändere in der zweiten Zeile "0-100" z.B. auf "0-1500" und schau mal, ob
>>> der Tunnel dann stabiler läuft.
>>
>> Hab ich gemacht, ohne Erfolg.
>>
>>> Voraussetzung ist also PF_INPUT_ACCEPT_DEF='yes'. Ist das bei dir der
>>> Fall?
>>
>> Ja.
>>
>>> Eine explizite Forward-Regel für Protokoll 41 ist _nicht_ nötig.
>>> Proto-41-Pakete werden im Kernel als IPv6-Pakete erkannt und
>>> entsprechend über die ip6tables weiter verarbeitet. Ein direktes
>>> Proto-41-Forwarding würde nur dafür sorgen, dass der Router überhaupt
>>> nichts mit den Paketen anstellt, sondern direkt irgendwohin weiterleitet
>>> (z.B. an einen anderen Router). Dies wird aber so vom IPv6-Paket nicht
>>> unterstützt, sprich wenn man die Firewall von fli4l so konfigurierte,
>>> dann wäre die IPv6-Konfiguration des fli4l "kaputt".
>>
>> Habe in der base.txt die Einträge für Potokoll 41, 1 und 58 entfernt,
>> der Tunnel steht nach wie vor etwa 20 bis 30 Minuten, danach hilft ihm
>> nur ein reboot des Routers wieder auf die Beine. Scheint so, als ob die
>> Instabilität doch nicht am ICMP liegt. Oder auch nichtmal am Fli4l.
>>
>> Welches log-file muss ich mir ansehen, um evtl. die Ursache für die
>> Abbrüche zu finden?
>>
>> Danke und viele Grüße.
>
>
> Hallo Christoph,
> das Problem lässt mir keine Ruhe. :-)
>
> Ich habe weiter gelesen und folgendes gefunden:
>
> Unter http://ipv6.chappell-family.com/ipv6tcptest/ kann man einen
> IPv6-Portscan machen lassen, dessen Ergebnis bei mir unter anderem wie
> folgt aussieht:
>
> IPv6 TCP Port Scan Results
>
> Results for host : 2001:470:1234:0:1234:1234:1234:1234
>
> Scan beginning at: Thu May 3 16:33:18 2012 , expected to take up to 11
> seconds ...
> ICMPv6 ECHO REQUEST returned : ECHO NO REPLY
>
>
> (die Adresse habe ich anonymisiert)
>
>
> und dann weiter unten die Erläuterung zum ICMPv6:
>
> Reported State:
> ECHO NO REPLY
>
> Meaning:
> No ICMPv6 ECHO_REPLY packet was received in response to the ICMPv6
> ECHO_REQUEST which was sent. This is the ideal response since no-one can
> ascertain your machines' presence at this IPv6 address.
>
> Gut, das ist jetzt ein ICMPv6-Test, und ICMPv6 wird von HE nicht
> gebraucht, wie wir jetzt wissen.
>
> Ich lasse mal noch einen Portscan von außen auf IPv4 machen und melde
> mich nochmal.
>
> Viele Grüße.
>

Nun nach dem durchgeführten IPv4-Ping-Test folgendes Ergebnis:

Zitat:	"Ihr System antwortet auf Ping Requests.

Das ist grundsätzlich nicht schlecht, aber es gab in der Vergangenheit 
auch schon Probleme damit (z.b. Ping Of Death, damit konnte ein System 
mit nur einem Ping Request zum Absturz gebracht werden).

Sie können die Sicherheit Ihres Systems verbessern indem Sie mit einer 
Firewall Ping (ICMP) Requests filtern.

Desweiteren gehen auf dem Weg rund +5 errors, 100% der Pakete verloren. 
Dies kann z.B. durch eine überlastete Internetverbindung verursacht 
werden. Sind Sie sicher dass dies nicht der Fall ist, kontaktieren Sie 
bitte den Support Ihres Internet Providers." Zitat Ende.


Der ISP, der hier gemeint ist, ist doch wohl mein Router (fli4l). Und 
ICMP filtern will ich nicht, im Gegenteil. Und wie kommen die von 
http://www.security-check.ch/index.cfm?lang=d
zu der Ansicht, dass 100% der Pakete verloren sind, und trotzdem das 
System auf Ping-Requests antwortet?

Ich begreife es nicht. Und ich glaube immer mehr, dass HE selbst die 
Instabilität verursacht. Sollte das nach Deiner Meinung, Christoph, 
anders sein, ich teste sehr gern weiter.

Viele Grüße und nochmals Danke.