AVM Fritz!Box Fon WLAN: Firewall ausschalten

[TWELVE]

Im Falle von ISAKMP ist der Source Port nicht zufällig, sondern es wird Port 500 benutzt (RFC-gemäß). Kannst Du mit Deinem Cisco Client und ethereal testen.

Das is mir schon klar, ich wüßte nur nicht, was man daran ändern könnte, wenn der Router Quellports austauscht.

sondern hat den Nebeneffekt, dass auch bei ausgehenden Verbindungen von diesem Rechner dieser Port nicht angefasst wird. Der Router stellt sich für diesen Rechner und diesen Port quasi auf transparent.

Weißt Du, ob das bei der Fritz so ist..? Wenn ich das richtig gelesen hab, dann hatte diese Maßnahme bislang keinen Erfolg.

Ob die Fritz Ports verändert, kannst Du ganz einfach mit der in der Fritz eingebauten Packet Capture Funktion herausfinden.

http://fritz.box/cgi-bin/../cgi-bin/webcm?getpage=../html/capture.html

Grüße


TWELVE

 

[KuniGunther]

Hallo,

Weißt Du, ob das bei der Fritz so ist..? Wenn ich das richtig gelesen hab, dann hatte diese Maßnahme bislang keinen Erfolg.

Nun, laut Matthias ist bei seinem Client ja standardmäßig NAT-Traversal an.

da die Vorgabe im Laptop mit NAT traversal tunneling ist, nehme ich an, dass dies auch vom Server unterstützt wird.

Und wenn auch das nicht geht, scheint das Problem hier woanders zu liegen.

Einen Unterschied machte die Portfreigabe für 500 aber in diesem Thread. Zitat daraus:

Da es sofort geht, sobald ich eine Portweiterleitung (FBF-Jargon "Portfreigabe") von UDP 500 zu meinem Test-Client im internen Netz setze, zeigt mir auch eindeutig, daß hier eben genau kein Pass-Through möglich ist.

Du hast aber recht, einen direkten Beweis für die Portumsetzung bzw. die Nicht-Portumsetzung habe ich noch nicht.

Ob die Fritz Ports verändert, kannst Du ganz einfach mit der in der Fritz eingebauten Packet Capture Funktion herausfinden.

http://fritz.box/cgi-bin/../cgi-bin/webcm?getpage=../html/capture.html

Danke für den Hinweis, war mir total entfallen. Ich werde das heute Abend mal testen.

Viele Grüße,
Volker

 

[KuniGunther]

@TWELVE: Danke, dass Du so hartnäckig gefragt hast

@semilla: Die Theorie mit dem Portforwarding hat leider einen Haken ...

Ich habe die Pakete der FritzBox mal capturen lassen und ich sehe keinen Unterschied bzgl. PAT ob ich den Port 500 jetzt geforwardet habe oder nicht. Die FritzBox setzt in beiden Fällen für die ausgehende Verbindung von 500 auf 6xxxx um.

Ich nehme also alles zurück und behaupte das Gegenteil :noidea:

EDIT: siehe unten

Viele Grüße,
Volker

 

[matthias03]

Gelöst!



Hallo zäme,
besten Dank für Euren sehr guten Support. Unterdessen habe ich mich erkundigt und musste ca. 10 Port freischalten. Sobald dies erfolgt ist, konnte ich problemlos kommunizieren.

Noch eine kleine Anschlussfrage: Wie kritisch sind geöffnet Ports? Entsteht dabei ein Risiko? Oder soll ich diese nach Gebrauch wieder schliessen?

Besten Dank und Gruss
Matthias

 

[semilla]

@TWELVE: Danke, dass Du so hartnäckig gefragt hast

@semilla: Die Theorie mit dem Portforwarding hat leider einen Haken ...

Ich habe die Pakete der FritzBox mal capturen lassen und ich sehe keinen Unterschied bzgl. PAT ob ich den Port 500 jetzt geforwardet habe oder nicht. Die FritzBox setzt in beiden Fällen für die ausgehende Verbindung von 500 auf 6xxxx um.

Ich nehme also alles zurück und behaupte das Gegenteil :noidea:

in der tat? ich meinte, dass das in einer früheren fritzbox fon wlan ging...
und wenn du auch ESP für die client-IP freigibst?

 

[KuniGunther]

Ich bin jetzt etwas verwirrt.

Nach Auskunft von AVM sollte nämlich die Einstellung Portforwarding UDP 500 <-> 500 genau diesen Effekt haben. Und zwar aus genau dann anzuwenden, wenn ein VPN-Server nur auf Port 500 reagiert.

Was ich da getestet habe, ist mir jetzt allerdings schleierhaft . Die Fritzbox zeigte obige an, ich habe die FB-Weboberfläche extra nochmal neu aufgemacht, um das zu überprüfen. Da hilft nur nochmal probieren ...

Sorry für die Verwirrung (natürlich für Eure, nicht für meine ).

Volker

 

[SirHaeck]

@matthias03: welche Ports waren das denn?

Christoph

 

[KuniGunther]

@semilla & TWELVE:

In der Tat, es ist doch so, wie eingangs richtig vermutet. Wenn ich in der FB Portforwarding UDP 500 einstelle, dann wird der ausgehende Port 500 nicht verändert und man kann sich mit Servern verbinden, die nur Verbindungen von Port 500 zulassen.

Damit ist das der einzige Fall, in dem man ein Portforwarding für eine ausgehende Verbindung braucht.

Viele Grüße,
Volker

 

[telchef]

Ich bin jetzt etwas verwirrt.

Nach Auskunft von AVM sollte nämlich die Einstellung Portforwarding UDP 500 <-> 500 genau diesen Effekt haben. Und zwar aus genau dann anzuwenden, wenn ein VPN-Server nur auf Port 500 reagiert.

Was ich da getestet habe, ist mir jetzt allerdings schleierhaft . Die Fritzbox zeigte obige an, ich habe die FB-Weboberfläche extra nochmal neu aufgemacht, um das zu überprüfen. Da hilft nur nochmal probieren ...

Sorry für die Verwirrung (natürlich für Eure, nicht für meine ).
Volker

Wäre es möglich, daß bei Deinen Beobachtungen Du beim Verändern der Portweiterleitungen (FBF "Portfreigaben") die DSL-Verbindung nicht ab- und aufgebaut hast - denn die FBF ändert die Regeln erst offenbar immer nach erneutem Aufbau.

(Also dadurch die Verwirrung? - Hatte mich auch schon mehrmals Fehlbeobachtungen gekostet, bis ich's bemerkt hatte.)

Gruß, Harald

 

[KuniGunther]

Hallo Harald,

Wäre es möglich, daß bei Deinen Beobachtungen Du beim Verändern der Portweiterleitungen (FBF "Portfreigaben") die DSL-Verbindung nicht ab- und aufgebaut hast - denn die FBF ändert die Regeln erst offenbar immer nach erneutem Aufbau.

Sowas habe ich bisher noch nicht beobachtet. Ich setzt hin und wieder mal bei Bedarf Portforwarding-Regeln für EMule und habe dazu noch nie die DSL-Verbindung ab- und aufgebaut. Dass das einschalten funktioniert sehe ich an der High-ID und dass das Ausschalten geht, an dem Abbruch des Anfragetraffics auf meinen Rechner. Ich habe höchstens schon mal eine kleine Verzögerung beobachtet.

Viele Grüße,
Volker

 

[telchef]

Sowas habe ich bisher noch nicht beobachtet. Ich setzt hin und wieder mal bei Bedarf Portforwarding-Regeln für EMule und habe dazu noch nie die DSL-Verbindung ab- und aufgebaut. Dass das einschalten funktioniert sehe ich an der High-ID und dass das Ausschalten geht, an dem Abbruch des Anfragetraffics auf meinen Rechner. Ich habe höchstens schon mal eine kleine Verzögerung beobachtet.

Man, die Effekte nehmen kein Ende... ;-)) Man muß offenbar diese Technik noch präziser beobachten.
Ich muß meinen Stundensatz dringend erhöhen - aber dann kann man sich ja gleich Cisco von teuren Cisco-Vertragspartnern aufstellen lassen... (Naja, wenn man aber immer andere was Leisten läßt, bleibt man dumm und muß bei jeder Gelegenheit nachlöhnen, weil man nicht den kleinsten Effekt verstehen kann.)


Wir haben beide etwas richtiges beobachtet:

Das Zuschalten meiner Portweiterleitung (FBF "Portfreigabe") UDP 500 klappt im mit dem Internet verbundenen Betrieb. D.h. vor dem Zuschalten wird Source-Port != 500 benutzt, nach dem Zuschalten wird 500 benutzt.

Nach dem Wegschalten der Portweiterleitung wird allerdings immer noch Source-Port 500 benutzt, vermutlich solange, bis die FBF den aus ihrer PAT-Tabelle aufgrund von Timeout verwirft.
Daher kann ich auch nach abgeschalteter Portweiterleitung noch eine Weile erfolgreich neue Tunnel aufbauen. (So etwa 5 Minuten, mindestens 2 Minuten.)


Gruß, Harald