Sonicwall tz 180 Portweiterleitung
Hallo zusammen,
ich versuche seit zwei Tagen vergebens einen Port an einer Sonicwall tz 180 weiterzuleiten.
Folgendes Problem:
Um auf owa aus dem web zugreifen zu können musste ich port 25 und noch andere weiterleiten.
Um auf iis zugreifen zu können brauchte ich port 80 und noch andere.
ich habs erst versucht irgendwie manuell einzurichten aber alle versuche waren vergebens.
dann habe ich den wizzard benutzt und eine weiterleitung für einen mail und einen webserver eingerichtet.
das klappte auf anhieb.
mit diesem wizzard kann man aber auch noch auf "others" klicken und dort einen port selbst eintragen.
ich möchte zb. noch port 5555 zum server weiterleiten.
der wizzard macht die einträge in der nat und den access rules aber der port ist trotzdem nicht weitergeleitet.
ich versteh es nicht weil wenn ich port 25,80,443 usw mit einem portchecker teste ist alles ok nur wenn ich port 5555 teste gehts nicht.
jetzt hab ich noch versucht manuell das alles nochmal einzurichten aber das klappt genauso wenig.
im netz habe ich paar infos aufsammeln können wie ich vorgehen soll aber das klappt nicht.
in der os firewall habe den port auch freigegeben.
sorry das ich euch mit sowas nerve aber ich komm echt nicht weiter...
das war bei dem speedport w900v und dem linksys wrt54gl irgendwie deutlich einfacher...
ich versuche seit zwei Tagen vergebens einen Port an einer Sonicwall tz 180 weiterzuleiten.
Folgendes Problem:
Um auf owa aus dem web zugreifen zu können musste ich port 25 und noch andere weiterleiten.
Um auf iis zugreifen zu können brauchte ich port 80 und noch andere.
ich habs erst versucht irgendwie manuell einzurichten aber alle versuche waren vergebens.
dann habe ich den wizzard benutzt und eine weiterleitung für einen mail und einen webserver eingerichtet.
das klappte auf anhieb.
mit diesem wizzard kann man aber auch noch auf "others" klicken und dort einen port selbst eintragen.
ich möchte zb. noch port 5555 zum server weiterleiten.
der wizzard macht die einträge in der nat und den access rules aber der port ist trotzdem nicht weitergeleitet.
ich versteh es nicht weil wenn ich port 25,80,443 usw mit einem portchecker teste ist alles ok nur wenn ich port 5555 teste gehts nicht.
jetzt hab ich noch versucht manuell das alles nochmal einzurichten aber das klappt genauso wenig.
im netz habe ich paar infos aufsammeln können wie ich vorgehen soll aber das klappt nicht.
in der os firewall habe den port auch freigegeben.
sorry das ich euch mit sowas nerve aber ich komm echt nicht weiter...
das war bei dem speedport w900v und dem linksys wrt54gl irgendwie deutlich einfacher...
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 152705
Url: https://administrator.de/contentid/152705
Ausgedruckt am: 26.11.2024 um 03:11 Uhr
16 Kommentare
Neuester Kommentar
Moin
Wenn es TCP ist, kannst Du das mit Telnet IP Port ganz einfach testen.
Bedenke auch, dass Du Ports nicht umleiten kannst. 27458 -> 192.168.0.10:3389
Zitat von @kowa1981:
mit diesem wizzard kann man aber auch noch auf "others" klicken und dort einen port selbst eintragen.
ich möchte zb. noch port 5555 zum server weiterleiten.
der wizzard macht die einträge in der nat und den access rules aber der port ist trotzdem nicht weitergeleitet.
Du bist aber sicher, dass dieser Port vom Server auch angenommen wird?mit diesem wizzard kann man aber auch noch auf "others" klicken und dort einen port selbst eintragen.
ich möchte zb. noch port 5555 zum server weiterleiten.
der wizzard macht die einträge in der nat und den access rules aber der port ist trotzdem nicht weitergeleitet.
Wenn es TCP ist, kannst Du das mit Telnet IP Port ganz einfach testen.
Bedenke auch, dass Du Ports nicht umleiten kannst. 27458 -> 192.168.0.10:3389
sorry das ich euch mit sowas nerve aber ich komm echt nicht weiter...
das war bei dem speedport w900v und dem linksys wrt54gl irgendwie deutlich einfacher...
Du beschwerst Dich gerade, dass Deiner Neuer Porsche aufwendiger zu Fahren ist als Dein Golf das war bei dem speedport w900v und dem linksys wrt54gl irgendwie deutlich einfacher...
Vermutlich hast du keinen aktiven Dienst hinter dem Port 5555 (Welchen eigentlich TCP oder UDP ??) an der im PFW angegebenen IP Adresse. Dann kann natürlich auch nix antworten, logisch !
Nebenei ist es nicht ratsam IANA zugewiesen Ports zu nutzen. Besser man nimmt dafür die von der IANA für private Anwendungen vorgesehene Ports im Bereich 49152 bis 65535 um Konflikte zu vermeiden !
http://en.wikipedia.org/wiki/Ephemeral_port
Mit "Telnet" kann man es übrigens nicht testen, denn der Telnet Daemon hört nur auf TCP 23 und mit einem Client dem man zwar mit :5555 den Port mitgeben kann gehts nicht, denn es ist eben nur ein Client der NICHT auf eine Port "hört".
Was man machen kann ist z.B. den Port des Remote Desktop Dienstes von TCP 3389 auf TCP 5555 ändern:
http://support.microsoft.com/kb/306759/de
Damit wäre dann ein Port Scanning auf TCP 5555 machbar da sich dahinter nun ein Dienst befindet.
Ebenso ginge das mit Port Translation auf dem o.a. Router von eingehend TCP 5555 auf lokale TCP 3389.
@Stefan: Mit Port Translation kann man schon Ports umleiten. So gut wie alle Router der etwas besseren Kategorie supporten das problemlos in ihren Port Weiterleitungs Einstellungen !!
In dem von dir dann oben zitierten Beispiel muss man dann nur den RDP Client starten und <ziel_ip_adresse>:27458 eingeben und landet dann auf den RDP Schirm des internen Rechners 192.168.0.10 !
Ein simples Standardszenario für Port Translation ! Macht auch Sinn um nicht gleich jedem Skript Kiddie im Internet zu zeigen das dieser Port erreichbar ist.
Ports über 48152 werden von den gängigen Port Scannern im Internet meist nicht mehr gescannt ! So kann man dann Löcher die man in die NAT Firewall gebohrt hat wenigstens etwas verschleiern !
Sicherer sind aber nur VPNs !
Nebenei ist es nicht ratsam IANA zugewiesen Ports zu nutzen. Besser man nimmt dafür die von der IANA für private Anwendungen vorgesehene Ports im Bereich 49152 bis 65535 um Konflikte zu vermeiden !
http://en.wikipedia.org/wiki/Ephemeral_port
Mit "Telnet" kann man es übrigens nicht testen, denn der Telnet Daemon hört nur auf TCP 23 und mit einem Client dem man zwar mit :5555 den Port mitgeben kann gehts nicht, denn es ist eben nur ein Client der NICHT auf eine Port "hört".
Was man machen kann ist z.B. den Port des Remote Desktop Dienstes von TCP 3389 auf TCP 5555 ändern:
http://support.microsoft.com/kb/306759/de
Damit wäre dann ein Port Scanning auf TCP 5555 machbar da sich dahinter nun ein Dienst befindet.
Ebenso ginge das mit Port Translation auf dem o.a. Router von eingehend TCP 5555 auf lokale TCP 3389.
@Stefan: Mit Port Translation kann man schon Ports umleiten. So gut wie alle Router der etwas besseren Kategorie supporten das problemlos in ihren Port Weiterleitungs Einstellungen !!
In dem von dir dann oben zitierten Beispiel muss man dann nur den RDP Client starten und <ziel_ip_adresse>:27458 eingeben und landet dann auf den RDP Schirm des internen Rechners 192.168.0.10 !
Ein simples Standardszenario für Port Translation ! Macht auch Sinn um nicht gleich jedem Skript Kiddie im Internet zu zeigen das dieser Port erreichbar ist.
Ports über 48152 werden von den gängigen Port Scannern im Internet meist nicht mehr gescannt ! So kann man dann Löcher die man in die NAT Firewall gebohrt hat wenigstens etwas verschleiern !
Sicherer sind aber nur VPNs !
Was meinst du genau mit "...auf die box zu zugreifen" ??? Ist "die Box" ein Gerät hinter der NAT Firewall der Sonicwall oder ist das die Sonicwall selber ??
Bedenke das die Ziel IP Adresse immer die aktuelle DSL IP deiner Sinicwall ist um Geräte im lokalen Netz per PFW zu erreichen !
Diese ändert sich aber dynmaisch durch PPPoE. Du solltest hier also besser immer mit DynDNS arbeiten was du vermutlich auch machst...hoffentlich ?!
Ansonsten kann es normal sein das eine IP nach ein paar Stunden nicht mehr funktioniert !
Nochwas: Außer deinem PFW ist auch deine Shift Taste defekt !!
Bedenke das die Ziel IP Adresse immer die aktuelle DSL IP deiner Sinicwall ist um Geräte im lokalen Netz per PFW zu erreichen !
Diese ändert sich aber dynmaisch durch PPPoE. Du solltest hier also besser immer mit DynDNS arbeiten was du vermutlich auch machst...hoffentlich ?!
Ansonsten kann es normal sein das eine IP nach ein paar Stunden nicht mehr funktioniert !
Nochwas: Außer deinem PFW ist auch deine Shift Taste defekt !!
Port 445 schiesst dir dein MS Netzwerk ab denn das nutzt MS für CIFS Shares !
Vergiss doch bitte ganz schnell alle Port bis 1024 die sind international fest zugewiesen und damit bekommst du erhebliche Probleme !!
Vorher also die Portliste checken und die privaten Ports nutzen !!!
http://www.iana.org/assignments/port-numbers
#
https 443/tcp http protocol over TLS/SSL
https 443/udp http protocol over TLS/SSL
# Kipp E.B. Hickman <kipp&mcom.com>
https 443/sctp HTTPS
# IETF TSVWG
# Randall Stewart <rrs&lakerest.net>
# [RFC4960]
snpp 444/tcp Simple Network Paging Protocol
snpp 444/udp Simple Network Paging Protocol
# [RFC1568]
microsoft-ds 445/tcp Microsoft-DS
microsoft-ds 445/udp Microsoft-DS
# Pradeep Bahl <pradeepbµsoft.com>
Vorher also die Portliste checken und die privaten Ports nutzen !!!
http://www.iana.org/assignments/port-numbers
Hallo kowa1981,
System > Administration : Administrator Name Passwort: ein sehr komplexes Passwort ...
System > Administration : Web Management Settings: HTTPS Port: 444 (z.B., damit 443 für SSL verwendet werden kann)
Network > Interfaces: WAN > Confirure : General : Management [x] HTTPS und [x] Add rule to enable redirect from HTTP to HTTPS
Mit diesen Einstellungen erstellt die Firewall automatisch die NAT-Policies und Access-Rules.
Unter Firewall > Access Rules > (WAN > WAN) sind dann auch die "HTTPS Management" Regeln eingetragen (Coment: auto-added mamagement rule).
vG
LS
System > Administration : Administrator Name Passwort: ein sehr komplexes Passwort ...
System > Administration : Web Management Settings: HTTPS Port: 444 (z.B., damit 443 für SSL verwendet werden kann)
Network > Interfaces: WAN > Confirure : General : Management [x] HTTPS und [x] Add rule to enable redirect from HTTP to HTTPS
Mit diesen Einstellungen erstellt die Firewall automatisch die NAT-Policies und Access-Rules.
Unter Firewall > Access Rules > (WAN > WAN) sind dann auch die "HTTPS Management" Regeln eingetragen (Coment: auto-added mamagement rule).
vG
LS
Hallo kowa1981,
Du liegst nicht falsch, kann Dir aber nicht sagen, wo das Problem liegt.
LS
Du liegst nicht falsch, kann Dir aber nicht sagen, wo das Problem liegt.
LS