Nach Update auf FW 7.20 funktioniert Portforwarding nicht!

[gm]

Hallo Jirka,

könnte LCOS eigentlich nicht prüfen, ob die Ports "frei" sind und diese erst dann für NAT verwenden? Netfilter versucht z.B. sogar einfach den Port vom Client für's NAT zu verwenden wenn es möglich ist. Könnte LCOS nicht auch ohne fixen Bereich auskommen (bin eh ganz erstaunt)?

Frei würde bedeuten:
- kein Portforwarding
- keine Services am Router (
- größer 1024 oder besser größer 32767 oder noch besser einstellbar
- noch nicht für andere (NAT-)Verbindung verwendet
- ...

Gruß
gm

[Jirka]

Hallo gm,

ja, könnte sicherlich. Aber das ist ja sicher auch eine Performance-Frage. Und weiterhin stellt sich die Frage, ob das praktisch wirklich gewünscht/erforderlich ist, denn in _den_ Portbereichen sollte man eigentlich flexibel sein, so dass die Kenntnis darüber eigentlich ausreichen sollte.

Im Augenblick ist es auf alle Fälle nicht so. Alles weitere entzieht sich meiner Kenntnis...

Viele Grüße,
Jirka

[bild.jpg]

Hi,

ich hab hier das Problem, dass zwar normale Port-Forwardings funktionieren aber nicht Port-Forwardings an x.y.z.255, also ans ganze netz (für WOL)
hat da wer ne idee warum - in der alten 6.32 ging alles perfekt.

THX, lg JPG

[backslash]

Hi bild.jpg

ich hab hier das Problem, dass zwar normale Port-Forwardings funktionieren aber nicht Port-Forwardings an x.y.z.255, also ans ganze netz (für WOL)
hat da wer ne idee warum

das liegt daran, daß Broadcasts für das lokale Netz von der Firewall gefiltert werden, wenn sie nicht explizit erlaubt sind (Abwehr des SMURF-Angriffs).

in der alten 6.32 ging alles perfekt

das kann nicht sein... Die Firewall ist in dieser Hinsicht seit Jahren unverändert...

Gruß
Backslash

[bild.jpg]

Nun, ich habe natürlich auch in der FW den Port a und das Ziel x.y.z.255 eingetragen und als "Übertragen" markiert.
Um eben Einbrüchen entgegenzuwirken bekomm ich immer eine Mail wenn der Port benutzt wird.
Tja - fakt ist ich bekomme seit 7.2 keine Mail wegen Erfolgreicher übertragung noch eine Meldeung, da FW das Packet ausgemustert hat.
WOL ist meineswissens ein UDP-Packet - habe aber auch ma in der Port-Forwarding Liste TCP+UDP rein mit gleich schlechtem "Erfolg"

na ja - wenn jemand nen funktionierendes WOL over WAN hat - bitte melden!

die Maschienen starten wenn man den WOL aus dem LAN sendet wunderbar auf - und eben mit 6.32 tat alles noch ...
Einzige Änderung ist eben das Firmware update.

Ach ja - die Port-Forwarding Liste hab ich auch schon komplett gelöscht - auf den Lancom geladen und dann wieder alles neu rein - hat keine Änderung erwirkt.

lg JPG

[EDDI]

Da melde ich mich auch mal ...

WOL over WAN: Geht bei LC1722 7.22 -> ISDN -> LC/DSL/I-10 3.58

WOL over WAN: Geht bei mir auch nicht mit LC 1722 7.22 -> LC-VPN -> LC1621B 7.22

Es ist keine DENY-All aktiv auf den Ziel-Routern.
Trotz Regel in der Firewall

NAME: Allow_WOL
Aktion: Sofort Uebertragen
Verb.-Quelle: Netz des 1722
Verb.-Ziel: Netz des 1621
Protokol: UDP
Zielport: 9

ist es nicht möglich, aus dem Netz des 1722 einen PC im Netz des 1621 per WOL zu wecken. Wenn ich die Firewall des 1621 ganz abschalte, geht WOL.

Was stimmt da nicht ?

[backslash]

Hi EDDI

Trotz Regel in der Firewall

NAME: Allow_WOL
Aktion: Sofort Uebertragen
Verb.-Quelle: Netz des 1722
Verb.-Ziel: Netz des 1621
Protokol: UDP
Zielport: 9

ist es nicht möglich, aus dem Netz des 1722 einen PC im Netz des 1621 per WOL zu wecken. Wenn ich die Firewall des 1621 ganz abschalte, geht WOL.

Die Regel ist ja auch falsch...

Das Ziel darf nicht das Netz des 1621 sein, sondern es muß die Broadcast-Adrersse in diesem Netz sein...

Ohne explizite Regel, die den Broadcast zuläßt, greift die DoS-Erkennung (SMURF-Angriff). Die Regel muß wirklich alleine da stehen, eine Zusammenfassung mit anderen Regeln ist wirkungslos!

Gruß
Backslash

[bild.jpg]

Broadcast bedeutet doch x.y.z.255?
Gut - das hab ich als Ziel angegeben ...
tut trotzdem nicht - was ist falsch?
PLEASE HELP!!!

[EDDI]

Hallo Backslash

okay, ich habs wieder einfach nicht präzise genug ausgedrückt.

Netz1
192.168.0.0 / 24
LC1722 LCOS 7.22
DENY-ALL-Strategie aktiv

Folgende Regel erlaubt hier Wake On Lan

Code: Alles auswählen

Name: Allow_WOL
Diese Regel ist für die Firewall aktiv: Ja
Diese Regel wird zur Erzeugung von VPN-Regeln herangezogen: Nein
Weitere Regeln beachten, nachdem diese Regel zurtrifft: Nein
Diese Regel hält die Verbindungszustände nach (empfohlen): Ja

Aktionen: Sofort übertragen

Stationen:
-Verbindungsquelle: Alle Stationen in allen lokalen Netzen
-Verbindungsziel: Verbindungen an alle Stationen

Dienste:
Benutzerdefinierte Protokolle
IP-Protokolle: UDP
Ziel-Port: 9

So, mit dieser Regel ist es nicht möglich, einen PC aufzuwecken, der via Lancom-VPN in

Netz2
192.168.1.0 / 24
LC1621B LCOS 7.22
Keine DENY-ALL-Strategie

Konfigurierte Firewall-Regeln: 2 Stück
- Standard-WINS-Regel
- Allow_WOL:
Aktion: Sofort Uebertragen
Verb.-Quelle: Verbindungen von alle Stationen
Verb.-Ziel: 192.168.1.255
Protokol: UDP
Zielport: 9

steht.

Dagegen ist es möglich, einen PC in

Netz3
192.168.2.0 / 28
LC DSL/I-10 LCOS 3.58
Keine DENY-ALL-Strategie
Konfigurierte Firewall-Regeln: 2
- Standard-WINS-Regel
- Allow_all_from_netz1
Aktion: Sofort Uebertragen
Verb.-Quelle: Verbindungen von 192.168.0.0/255.255.255.0
Verb.-Ziel: Alle Stationen im lokalen Netz
Diese Regel gilt für alle Dienste / Protokolle

zu wecken, dies ist eine ISDN-LAN-LAN-Koplung (ohne VPN).

So, vielleicht kommen wir ja jetzt weiter ...

[backslash]

Hi EDDI

eigentlich müßte es genau umgekehrt sein: Variante 1 müßte funktionieren und Variante 2 nicht (obwohl: bei Variante 2 ist eine Uralt-Firmware drin, die die Broadcasts ggf. noch nicht filtert)!

Mach doch mal auf beiden Seiten einen Router- und einen Firewall-Trace davon (trace # ip-ro fi)

Gruß
Backslash

[EDDI]

Hi backslash,

diese "Uralt-Firmware" ist die aktuellste, die für dieses Gerät verfügbar ist.

Was mich aber mittlerweile richtig stört:

Ich kann via Ping auf die IP (VPN-Verbindung wird vom 1722 problemlos aufgebaut)

• C:\>ipconfig /flushdns
  
  Windows-IP-Konfiguration
  
  Der DNS-Auflösungscache wurde geleert.
  
  C:\>ping 192.168.1.1
  
  Ping wird ausgeführt für 192.168.1.1 mit 32 Bytes Daten:
  
  Zeitüberschreitung der Anforderung.
  Antwort von 192.168.1.1: Bytes=32 Zeit=34ms TTL=59
  Antwort von 192.168.1.1: Bytes=32 Zeit=33ms TTL=59
  Antwort von 192.168.1.1: Bytes=32 Zeit=34ms TTL=59
  
  Ping-Statistik für 192.168.1.1:
  Pakete: Gesendet = 4, Empfangen = 3, Verloren = 1 (25% Verlust),
  Ca. Zeitangaben in Millisek.:
  Minimum = 33ms, Maximum = 34ms, Mittelwert = 33ms
  
  C:\>

via Ping auf den Namen

(VPN Verbindung wird vom 1722 nicht aufgebaut, Fehlermeldung laut Lanmonitor: Zeitueberschreitung während IKE-oder IPSec-Verhandlung (Initiatior) [0x1106])

kommt dagegen folgendes heraus:

• C:\>ping fe1.faet
  Ping-Anforderung konnte Host "fe1.faet" nicht finden. Überprüfen Sie den Namen,
  und versuchen Sie es erneut.
  
  C:\>

Ich erwähne dazu, dass der 1621er (192.168.1.1) hinter einer FBF steht, aber die Ports für LC-VPN

• IKE: UDP 500
  ESP: Protokoll 50
  ggf. UDP 4500 für NAT-T

sind ordnungsgemäß gefordwarded, sonst würde es ja ueber IP auch nicht gehen. Kann es sein, dass es hier ein Problem mit DNS im 1621er gibt ?

Beim zweiten VPN, dessen Endpunkt ein 1724 darstellt geht Pingen sowie Tracerouten ohne Probleme.

Den Trace mache ich auf Wunsch noch.

[thorstense]

@ Jirka,

Danke für den Tip mit den Reservierten Ports!

Ich habe jetzt die eMule Ports außerhalb von Port 57344 - 61439 gelegt und schon Funktioniert die Verbindung

Viele Grüße, Thorsten

PS: Jetzt mit FW 7.22 online!